Verschil tussen dct:format en dcat:mediaType about dcat-ap-donl

[keestrautwein]

Het korte antwoord op bovenstaande vraag van Importalis is: Ja, het is nodig beide eigenschappen op te nemen.

Er is veel te zeggen over dct:format, dcat:mediaType, dcat:compressFormat en dcat:packageFormat.
De functie van deze vier eigenschappen is aan te geven wat het technische formaat is van de bestanden in de distributie.

dcat:mediaType vs dct:format

Als eerste is het belangrijk te begrijpen dat dcat:mediaType een subproperty is van dct:format.

Functie

Met deze eigenschappen kan een ontvanger vooraf controleren of hij/zij het technisch formaat waarin de gegevens worden aangeboden kan of wil verwerken. twee voorbeeld om te verduidelijken:

1. Veel ontvangers kennen restricties op de bestandsformaten die zij kunnen verwerken op hun systemen uit veiligheidsoverwegingen of om technische of financiële redenen.

2. Ook kan een bestand in een formaat zijn waarvoor de ontvanger geen applicatie heeft. In dat geval kan de ontvanger de gegevens niet uitlezen en is deze distributie dus niet geschikt

Er is een belangrijk verschil tussen W3C en de EU DCAT-AP standaard.
De W3C standaard definieert mediatype als de "voorkeursproperty" met als bereik alle media types van IANA Alleen als een bestand wordt aangeboden in een formaat dat niet in de waardelijst van IANA staat, dan kan met dct:format een ander formaat worden beschreven. W3C definieert verder niets over de toegestane waardes. Die worden overgenomen van dct:format.

De DCAT-AP standaard draait de voorkeur om van deze beide eigenschappen: dct:format is recommended voor een Distribution, en dcat:mediatype optional. Voor dct:format definieert de EU Vocabularies File Type Named Authority List als waardelijst bij dit veld. Deze lijst, hoewel lang, heeft een andere inhoud dan IANA en lijkt bovendien kleiner. Hiermee zijn er in DCAT-AP slechts waardes uit twee waardelijsten toegestaan:

1. Bij voorkeur een waarde uit Vocabularies File Type Named Authority List met dct:format

2. Of een waarde uit IANA weergegeven met dcat:mediaType.

Belangrijk bij de EU is bovendien dat de cardinaliteit in DCAT-AP: beide properties zijn optioneel maar kunnen maximaal 1 keer voorkomen.

In de DCAT-AP specificatie worden verder geen voorbeelden of use-cases gedeeld, maar blijkbaar wordt daar de voorkeur aan dct:format gegeven. In de W3C spec staan wel relevante voorbeelden. In voorbeelden 50, 51, en 52 in bijlage §C.5 worden telkens beide properties ingevuld met waardes die in beide lijsten hetzelfde betekenen.

Voorlopige conclusie

Uit het bovenstaande kunnen we concluderen dat het noodzakelijk is zowel dcat:mediaType als dct:format op te nemen in DCAT-AP-DONL en DCAT-AP-NL om compatibel te blijven met zowel DCATv2 als DCAT-APv2.

Voorstel voor "goede gewoonte"

In de DCAT-AP-DONL en de toekomstige DCAT-AP-NL geven wij de voorkeur aan mediatype omdat dit type uitgebreider lijkt dan de waardelijst van de EU. Het lijkt een goede gewoonte beide velden in te vullen, maar het ontbreken van één van deze velden breekt de compatibiliteit met DCATv2 en DCAT-APv2 niet.

dcat:compressFormat en dcat:packageFormat

Functie

Deze in DCATv2 toegevoegde velden moeten afnemers helpen te besluiten of de bestanden aangeboden in de distributie technisch verwerkt kunnen worden. Dit is vergelijkbaar met de functie van de velden dcat:mediaType en dct:format. Toch lijken compressFormat en packageFormat niet helemaal compatibel met de cardinaliteit die DCAT-AP oplegt. Bovendien is er grote overlap in de toepassing van deze twee eigenschappen. Dit wordt hieronder toegelicht.

Het is gebruikelijk om een verzameling bestanden bij elkaar te voegen in zogenaamde packages. Een package voegt alle benodigde bestanden bij elkaar zodat ze gezamenlijk uitgewisseld kunnen worden, vaak ook in een bepaalde bestandsstructuur. Dat is zeer gebruikelijk bij het verspreiden van programmeer-bibliotheken waarbij technisch gebruikelijk formaten als rpm of npm worden uitgewisseld. Maar ook voor gegevensbestanden is dit gebruikelijk. Met name het TAR formaat wordt hiervoor traditioneel veel gebruikt. Met behulp van de IANA lijst kan het juiste package formaat worden aangegeven in property dcat:packageFormat.

dcat:compressFormat wordt gebruikt om met behulp van de IANA waardelijst aan te geven welke compressie formaat is gebruikt als één of meer bestanden in de distributie gecomprimeerd zijn. Merk op dat met name bestandsformaten gebruikt voor het opslaan van statische of dynamisch afbeeldingen en van geluid vrijwel altijd comprimeren. Deze compressie maakt echter deel uit van dat specifieke bestandsformaat en wordt speciaal ontwikkeld voor dat specifieke bestandsformaat en bijbehorende software om het bestand te verwerken. Deze compressie wordt niet weergegeven met dcat:compressFormat. Die eigenschap is bedoeld om compressie op filesysteem niveau weer te geven, waarbij de inhoud van de bestanden niet ter zaken doet: het compressie formaat probeert ieder bestand te comprimeren zonder kennis van de inhoud.

Overlap en gebruik

Nu wordt de overlap tussen compressFormat en packageFormat duidelijk: vrijwel alle gebruikelijk bestandscompressie formaten kunnen ook meerdere bestanden in één gecomprimeerd bestand samen brengen. Bovendien is het zeer gebruikelijk om in een package de bestanden ook te comprimeren.

Hieruit volgt dat de betekenis van dcat:compressFormat en dcat:packageFormat moet worden opgevat als een beschrijving van de benodigde technieken nodig om de bestanden uit het package te halen en te decomprimeren voordat de gegevens gebruikt kunnen worden. Met deze eigenschappen kan de ontvanger controleren of hij/zij deze technieken kan gebruiken en dus of deze dataset voor hem/haar te gebruiken is.

Samenhang tussen dcat:packageFormat , dcat:compressFormat , dcat:mediaType en dct:format

Het is niet helemaal duidelijk hoe deze velden gebruikt moeten worden. Stel we hebben een aantal bestanden die samen in een package zijn opgenomen en bovendien gecomprimeerd. Dit package bestand is te downloaden en wordt dus beschreven door een Distribution element. Dat verwachten we in deze Distributie een dcat:compressFormat met het gebruikte compressiealgoritme en een dcat:packageFormat waarde met het gebruikte package format.

Wat doen we nu met dcat:mediaType en dct:format?

We hoeven niet meer aan te geven wat het formaat is waarin de distributie ter download wordt aangeboden, want dat is al aangegeven met dcat:packageFormat. We hebben zelfs aangegeven welk compressie formaat in het package wordt gebruikt.

Als we kijken naar de functies van dcat:mediaType en dct:format zouden we ze inzetten om aan te geven in welke formaat de gegevens zijn opgeslagen als het pakkage is uitgepakt en gedecomprimeerd. Maar in een package en zelfs in een gecomprimeerd bestand zonder package kunnen bestanden zitten van uiteenlopende formaten, bijvoorbeeld een PDF, een CSV en een grafisch PNG bestand. Omdat dat aan te geven zou je drie waarden van dcat:mediaType en/of dct:format nodig hebben. Maar de cardinaliteit van DCAT-AP verbiedt het gebruik van meerdere instanties van deze properties: we mogen van iedere type er maximaal één opgeven.

Hoe gaan we hier mee om?

Er zijn drie scenario's voor distributies in een package:

Scenario 1: Gebruik dcat:mediaType en/of dct:format als het kan en anders niet

We gebruiken dcat:mediaType en/of dct:format als dat volstaat. Dat kan als in het package en/of de compressie slechts 1 bestand is opgenomen of als alle bestanden hetzelfde formaat hebben. Als dat niet het geval is: dan laten we dcat:mediaType en/of dct:format weg.

Helaas is de verwachting dat met name packages vaak meerdere en verschillende bestandsformaten zullen bevatten.

Dit scenario heeft als nadeel dat afnemers soms wel en soms geen informatie krijgen over het bestandsformaat. Er moet dus toch nog een handmatig proces worden ingericht om in distributies zonder dcat:mediaType en/of dct:format te controleren op verwerkbaarheid.

Scenario 2: Gebruik dcat:mediaType en/of dct:format nooit als dcat:compressFormat en/of dcat:packageFormat is gegeven

Dit scenario zorgt voor standaardisatie van het afhandelen van DCAT queries: Er moet altijd gekeken worden of de bestandsformaten in de Distributie verwerkt kunnen worden .

Dit scenario heeft als nadeel dat de winst die geboekt kan worden door te filteren op dcat:mediaType en/of dct:format als die wel aanwezig zijn, verloren gaat.

Scenario 3: Consequent: Gebruik dcat:compressFormatof dcat:packageFormat niet.

Gebruik dcat:mediaType en/of dct:format om het type van het bestand aan te geven, ook als het gecomprimeerd is of als het een package is. Daarmee is het formaat van het aangeboden bestand in de distributie altijd duidelijk. Helaas kunnen we niet aangeven welk formaat het bestand of de bestanden hebben binnen een gecomprimeerd of "gepackaged" bestand.

Openstaande vraag: Vullen we dcat:mediaType en/of dct:format in als dcat:compressFormat en/of dcat:packageFormat zijn opgegeven?

Edit: scenario 3 toegevoegd

[keestrautwein]

We hebben gekozen voor de eenvoudigste en meest consequente oplossing en dus voor scenario 3 te kiezen:
In het DONL profiel worden de velden dcat:packageFormat en dcat:compressFormat niet gebruikt. Onafhankelijk van compressie of "packaging" wordt met dcat:mediaType en dct:format aangegeven wat het formaat is van het aangeboden bestand in de distributie.

Hiermee verliezen we de mogelijkheid aan te geven welk formaat de bestanden hebben binnen een pakket of een gecomprimeerd bestand. Dat is gerechtvaardigd omdat het niet mogelijk is hierin consequent te zijn. Ontvangers moeten bij iedere keuze in veel voorkomende gevallen extra stappen nemen om te onderzoeken wat het formaat is van bestanden in een gecomprimeerd of ingepakt bestand. Omdat het EU DCAT-AP profiel maximaal 1 dcat:mediaType of dct:format toestaat, kan met DCAT niet correct beschreven worden welke bestandformaten er in een package zitten als dat er meerdere zijn in verschillende formaten.

dcat:mediaType en dct:format

Omdat dit profiel bouwt op het DCAT-AP profiel van de EU. sluiten we daar bij aan. Hiermee zijn we ook compatibel met de W3C DCAT standaard:

1. Voor compatibiliteit met zowel de W3C standaard als het Europese DCAT-AP profiel vult u beide properties in;
2. Bij het invullen van dct:format gebruikt U een waarde uit de waardelijst Vocabularies File Type Named Authority List;
3. dcat:mediaType wordt gevuld met een waarde uit de waardelijst IANA

[CasperKoop]

In het huidige donl is format verplicht en mediatype aanbevolen. Wat worden de kardinaliteiten van beide eigenschappen?
Mijn voorkeur gaat ernaar uit de EU te volgen door format leidend te maken. Met verplichten hebben we tot dusver geen problemen ondervonden, dus wat mij betreft laten we dat zo.

@WterBerg , de waardelijst van de EU lijkt uitgebreider dan de huidige DONL waardelijst. Moeten we deze nog een keertje doorlopen? In ieder geval lijkt het mij slim om binary toe te voegen voor get geval een bestandsformaat niet in de waardelijst voorkomt.

[WterBerg]

Cardinaliteit van DCAT-AP-DONL 1.1 wat betreft format is 1..1
Cardinaliteit van DCAT-AP-DONL 1.1 wat betreft mediaType is 0..1

Verder geen bezwaren om de DONL taxonomie uit te breiden!

[CasperKoop]

Uitleg is opgenomen in Respec