Fel användninga av dcterms:format och dcat:mediaType i Sverige

[matthiaspalmer]

What happened?

Sedan DCAT-AP1.0 har det funnits en diskussion om lämpligheten att använda en kontrollerad vokabulär för mediatyper. Från Sveriges sida har argumentationen varit att IANA mediatyper, på formen text/xml är välkända och utmärkta att använda med den vanliga dcterms:format propertyn. Detta argument har inte accepterats utan DCAT-AP2 och nu 3 fortsätter att använda vokabulären från publication office med dcterms:format och enbart om en mediatyp inte går att identifiera använder man dcterms:mediatype med en literal med IANA värdet.
När nu verifiering via SHACL shapes börjar fungera får Sverige ett sämre betyg på grund av detta.

Steps To Reproduce

Verifiera uttryck från Sverige via den DCAT-AP2 eller 3 SHACL för att se felrapporterna.

What did you expect?

Detta är förväntat beteende. Men det har funnits en förhoppning om att man inom DCAT-AP skulle ändra sin rekommendation.

Frågan är om det är läge att byta till det förväntade uttrycket?
Om inte, ska vi istället göra en konvertering i samband med export till data.europa.eu?

[carwash]

Instämmer med vår tidigare inställning. I sina interna system (innan mappning mot DCAT-AP) slår jag vad om att alla, utan undantag, använder IANA MIME-types för detta. Resten av världen som inte jobbar med länkade data, i alla andra nätsammanhang, och i synnerhet webbsammanhang, använder också IANA-typerna. Att avvika från detta i just DCAT-AP känns som om vi aktivt försöker sabba interoperabilitet.
Kommer en vanlig webbutvecklare, som inte är LOD-expert och aldrig hört talas om Publication Office, att glädjas när de anropar mot dataportalen och får tillbaka något annat än de förväntade MIME-typerna? Troligtvis inte. Principen om minsta möjliga förvåning säger nej.

[matthiaspalmer]

Som jag ser det har vi tre alternativ:

1. Fortsätta som tidigare och ignorera att vi är inkompatibla med resten av Europa.
2. Konvertera vid export till Europeiska dataportalen
3. Anpassa till DCAT-AP uttrycket
4. Anpassa till DCAT-AP uttrycket, men forsätta att acceptera nuvarande enklare direkta mediatyper (kallades tidigare MIME-typ).

@carwash jag förstår och sympatiserar med ståndpunkten. Men samtidigt känns det som att chansen att DCAT-AP skulle ändra sig och övergå till vårt angreppsätt rätt liten. Så jag föreslår att vi väljer mellan alternativ 2 och 4.

Observera att båda alternativen (2 och 4) innebär att vi kommer behöver göra konverteringen, skillnaden är att vi gör den vid skördningstillfället istället för vid export.

I princip kan vi då också passa på att se till att båda uttrycken finns representerade, både URI till publication office och den enklare mediatypen uttryckt direkt. Fördelen med detta är också att mediatypen faktiskt inte finns uttryckt i den RDF graf man får om man derefererar filtypens URI. (Se t.ex http://publications.europa.eu/resource/authority/file-type/CSV).

Dvs. jag tänker att med alternativ 4 hamnar vi i ett läge där vi är mer i linje med DCAT-AP och samtidigt har vi större flexibilitet för implementatörer.

[bjornhagstrom]

Jag kan inte säga vad som är bäst av 2 och 4 ovan men håller med om att vi bör hålla fast vid att vi minimerar förvåningen hos användare och har kvar det de förstår och förväntar sig och sedan sköter det formella för att uppfylla europeiska kriterier bakom kulisserna så mycket som möjligt.

[matthiaspalmer]

Efter att ha tänkt lite till föreslår jag följande:

• vi behåller vårt nuvarande angrepssätt som grund.
• vi satsar på att inom en snar framtid kommer stödja skördning enligt DCAT-AP sättet, vi berättar om en plan för detta.
• vid export till data.europa.eu ser vi till att konvertera till DCAT-AP uttrycket så snart som möjligt.

I en framtida version när ett sånt stöd är på plats och vi ser att det finns bakåtkompatibilitet kan vi vända på angreppsättet och uppdatera specen till DCAT-AP uttrycket istället som det föredragna sättet.