API:fiera kravkatalog för upphandling. Erfarenheter?

Maria_Dalhage

@davidlars @Björn-Hagström, @Nina_Berlin Ska försöka uttrycka mig tydligare. Ser att vi alla lätt pratar förbi varandra. Att ta fram ett API med sammanställda, kurerade krav är en bra idé, frågan är hur detta enklast görs.

Utmaningen är att få in bidrag och det var detta som jag och @jonass svarade på. För att få in bidrag behöver alla veta var man ska vända sig. Därför började jag med att skriva i detta forum, men det har sina begränsningar när det kommer till att ladda upp filer. @jonass föreslog därför nosad.se som redan används idag för att dela filer. I bägge fallen krävs det att någon senare om behovet föreligger bygger ett API av de bidrag; exempel meningar som tas fram.

Här handlar det om angreppssätt. Jag tror störst nytta kommer av att organisationer på enklaste sätt bara börjar dela sina kravexempel. På nosad.se kan man dela filer som excelark. Får vi in flera kan vi se hur vi kurerar och slår ihop. Jag tror att initialt ligger styrkan i att flera delar. Om det finns dem som endast vill dela enstaka meningar så kan vi kurera även sådant.

Den lösning som jag pekar på blir ju initialt inte ett API, men utmaningen är att få igång ”dela”-rörelsen. Flera spännande frågor dyker upp; hur förvaltas detta på sikt? Men som @Nina_Berlin skriver; det är bl.a. denna typ av frågor som vi gemensamt behöver lösa.

Nina_Berlin

@Maria_Dalhage Håller med jag tänker att det är mycket vunnet om @davidlars börjar sammanställa det innehåll som han vill dela, och delar det med hjälp av NOSAD. Så får vi se vart det tar vägen och var och hur vi bäst jobbar med det. Content is king. @jonass

davidlars

Vilken bra diskussion!
API är ju mer någon slags (del)målbild och som det påpekats sekundärt just nu. Från excel -> strukturerad plain text (enl någon smart XML-struktur) i Gitlab av det som vi är bekväma att dela känns som ett bra första steg härifrån. Jag börjar på den interna Gitlab-instansen och återkommer med delbart material och förmodligen följdfrågor innan dess.

davidlars

@Björn-Hagström
Nja, ett API hjälper inte det syftet direkt. Första steget behöver ju vara att dela datan och ta innehållet vidare gemensamt. Sträva åt någon slags gemensam masterdata kanske. Jag är på Örebro kommun.
Ser fram emot att kika på seminariet vid tillfälle! Hoppas att du är nöjd med hur det blev.

davidlars

@Nina_Berlin
Jag har en del jobb innan det kan bli dags för publicering men jag tänkte ändå flagga för att en trasig länk på

Den här länken:
"I Sverige har vi valt att förregistrera alla offentliga aktörer, man kan enkelt kolla om man är
förregistrerad på registrera"

davidlars

Tänkte se om jag kan få lite handledning i att sätta en RDF-struktur enl DCAT-AP-SE för ett exempelkrav från våran kravkatalog.

Ett exempelkrav, enl <Fält>: <Data>
ID: 012
Kravgrupp: Loggning
Rubrik: Loggning av åtkomst
Kravformulering: Loggning ska ske av åtkomst till lösningen
Prioritet: Ska
Bevis: Genom att svara Ja i anbudssvaret

OBS: detta är ett exempel och är inte det kompletta kravet som vi har formulerat det.

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:dcterms="http://purl.org/dc/terms/"
	xmlns:vcard="http://www.w3.org/2006/vcard/ns#"
	xmlns:dcat="http://www.w3.org/ns/dcat#"
	xmlns:foaf="http://xmlns.com/foaf/0.1/">
<dcat:Catalog rdf:about="https://example.com/catalog1">
	<dcterms:title xml:lang="sv">Kravkatalog</dcterms:title>
	<dcterms:description xml:lang="sv">Kravkatalog för IT-upphandlingar</dcterms:description>
	<dcterms:publisher rdf:resource="https://example.com/publisher1"/>
	<dcat:dataset rdf:resource="https://example.com/dataset1"/>
	<dcterms:license rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/"/>
</dcat:Catalog>
<foaf:Agent rdf:about="https://example.com/publisher1">
	<foaf:name>Exempelkatalog</foaf:name>
</foaf:Agent>
<dcat:Dataset rdf:about="https://example.com/dataset1">
	<dcterms:id xml:lang="sv">0012</dcterms:group>
	<dcterms:group xml:lang="sv">Loggning</dcterms:group>
	<dcterms:title xml:lang="sv">Loggning av åtkomst</dcterms:title>
	<dcterms:description xml:lang="sv">Loggning ska ske av åtkomst till lösningen</dcterms:description>
	<dcterms:priority xml:lang="sv">Ska</dcterms:priority>
	<dcterms:proof xml:lang="sv">Genom att svara Ja i anbudssvaret</dcterms:proof>
	<dcterms:publisher rdf:resource="https://example.com/publisher1"/>
	<dcat:distribution rdf:resource="https://example.com/distribution1"/>
	<dcat:contactPoint rdf:resource="https://example.com/contactpoint1"/>
</dcat:Dataset>
<dcat:Distribution rdf:about="https://example.com/distribution1">
	<dcat:accessURL rdf:resource="http://example.com/api"/>
	<dcat:accessService rdf:resource="https://example.com/dataservice1"/>
</dcat:Distribution>
<vcard:Organization rdf:about="https://example.com/contactpoint1">
	<vcard:fn>Exempelorganisation</vcard:fn>
	<vcard:hasEmail rdf:resource="mailto:oppnadata@example.com"/>
</vcard:Organization>
<dcat:DataService rdf:about="https://example.com/dataservice1">
        <dcterms:title xml:lang="sv">Exempel API</dcterms:title>
        <dcat:endpointURL rdf:resource="http://example.com/api"/>
</dcat:DataService>
</rdf:RDF>

Hur ser det ut för nästa krav? Hur nestar jag in kravlistan?

Jag vet ju hur jag skulle gjort med JSON eller YAML. Kan se hur det kontinuerliga arbetet med katalogen kan hämmas av det "omständiga"/pratiga formatet, även om jag förstår syftet.

davidlars

<kravkatalog.yaml>
...

catalog: "https://example.com/catalog1"
  - title: "kravkatalog"
    description: "Kravkatalog för IT-upphandlingar"
    publisher: "https://example.com/publisher1"
osv...
dataset:
  - id: "0012"
    group: "Loggning"
    title: "Loggning av åtkomst"
    description: "Loggning ska ske av åtkomst till lösningen"
    priority: "Ska"
    osv: ...
  - id: "0013"
    group: "..."
    title: "..."
    description: "..."
    priority: "..."
    osv: ...
  - id: "0014"
    group: "..."
    title: "..."
    description: "..."
    priority: "..."
    osv: ...

davidlars

...Om det inte var tydligt redan så gillar jag att ställa korkade frågor på internet. Nu läste jag vägledningen igen och jag missförstod uppenbarligen första genomläsningen.
Metadata: RDF-format
Data: JSON eller liknande

Korrekt?

Och eftersom att YAML är ett subset av JSON så skulle vi kunna köra något i stil med mitt YAML-exempel.
Hm.. eller JSON-LD, JSON för länkad data.

Maria Söderlind

@davidlars ser att du säger att du sett Umeås dataportal, men har du sett vår datamängd med upphandlingskrav? Tänker att det kanske är den infon du efterfrågar från oss. Här får du i vilket fall länk till där du kan ladda ner dem: [https://opendata.umea.se/explore/dataset/icke-funktionella-exempelkrav0/export/?sort=krav_id](link url)
Och här finns ett API om du föredrar det: [https://opendata.umea.se/explore/dataset/icke-funktionella-exempelkrav0/api/?sort=krav_id](link url)
Diskussionen om Wikidata hade inget att göra med den datamängden så du har helt rätt i att den inte bidrar ngt kring just detta

davidlars

@Maria-Söderlind
Tack, precis vad jag borde ha letat efter men av någon anledning inte letade efter!

davidlars

@Maria-Söderlind
Var bor er masterdata någonstans? Hur ser gränsnittet ut för de som matar in nya krav eller ändrar i kraven? Excel?

Maria Söderlind

@davidlars jag är ju inte informationsägaren så jag är inte helt säker. Tror excel, men rekommenderar att du skickar frågan till den kontakt som anges i datamängden IFkrav@umea.se

tove

@Maria-Söderlind sa i API:fiera kravkatalog för upphandling. Erfarenheter?:

datamängd med upphandlingskrav?

@davidlars det var EXAKT denna kravlista jag satt och tittade på när vi diskuterade idag (men hade inte sett denna tråd). Men med tillägget hur man kan göra en sådan kravlista open source och community baserad. Där man beaktar icke-funktionella krav som kanske har annan review-gång än funktionella krav. Icke-funktionella krav från såväl lag som standarder och möjligt att filtrera utifrån bransch och målgrupp på systemet. Och där man kan koppla olika standarder till samma krav ex om ISO och NIST och eller GDPR i slutändan innebär samma krav.

De som är icke-kod kunniga ska kunna lägga till/föreslå ändringar i content & kommentera i ett web-interface, men som har versionshantering genom git (finns kommenteringssystem som hanterar kommentarer på det sättet).

Vi kan gå igenom det initiala diagrammet och flödena jag skissat på vid tillfälle.

tove

@davidlars sa i API:fiera kravkatalog för upphandling. Erfarenheter?:

@Maria-Söderlind
Var bor er masterdata någonstans? Hur ser gränsnittet ut för de som matar in nya krav eller ändrar i kraven? Excel?

Uppdaterar du oss om du får något svar om inmatning? Och hemvist för metadatan?

davidlars

@tove

"det var EXAKT denna kravlista jag satt och tittade på när vi diskuterade idag (men hade inte sett denna tråd)."

Jag misstänkte det Inget svar ännu ang hemvist för metadata och hur Umeå matar in detta. Men blir inte förvånad om det är Excel och att man extraherar datan i säg nattliga jobb inför publicering via API, CSV och JSON.

Jag gillar ju mitt YAML-exempel här i tråden men jag är inte de flesta.

Björn Hagström

@davidlars Hallå, kan du maila mig på bjorn@hagstrom.nu? Skulle vilja ta en lunch:)