dataoverheid / dcat-ap-donl Goto Github PK

Openstaande vraag: hoe ziet de vulling van checksum er precies uit? Ik zou verwachten dat behalve de waarde van de checksum ook het gebruikte hash-alogoritme om de waarde mee te berekenen wordt meegestuurd.

DCAT kan ook binnen een organisatie worden gebruikt, zonder of met slechts gedeeltelijke uitwisseling met DONL. Dat moet behalve in scenario's ook in de tekst benoemd worden.

Waar plaatsen we deze informatie?

ik zie op de volgende waardelijst niet: donl:authority (wordt aan gerelateerd in dataset -> authority en dataset -> publisher.
Ik mis ook: overheid:grondslag
Waar vind ik deze waardelijst?
Groeten,
Harm Olthof

Voorstel maken voor hoe de AgentRole taxonomie vorm zou kunnen krijgen.

Zie

• https://www.w3.org/TR/vocab-dcat-2/#Property:distribution_compression_format
• https://www.w3.org/TR/vocab-dcat-2/#Property:distribution_packaging_format

Ik heb de letterlijke tekst uit §1.2 van "DCAT Application Profile for data portals in Europe Version 2.1.0" PDF gebruikt als definitie van Application Profile. Deze tekst moet nog even vertaald worden.

We willen datasets en dataservices graag verrijken met begrippen die afkomstig zijn uit bestaande begrippenkaders. Zie bijvoorbeeld https://begrippenxl.nl/nl/. Om wildgroei te voorkomen, willen we vooraf vaststellen welke begrippenkaders we op data.overheid.nl willen gebruiken. Op deze manier kunnen we ook nagaan of een toegekend begrip "geldig" is. Hierbij controleren we of het toegekende begrip voorkomt in een van de toegestane begrippenkaders.

Deze toegekende begrippen willen we ook graag kunnen uitwisselen. Dit betekent dat ze onderdeel moeten worden van het toepassingsprofiel voor DCART2.

De vragen:

1. Hoe gaan we in het DCAT-model aangeven welke begrippenkaders zijn toegestaan?
2. Is het noodzakelijk om een nieuwe property aan te maken voor begrippen? Standaard biedt DCAT property dcat:theme. Deze gebruikt data.overheid.nl nu om een thema uit de taxonomie beleidsagenda toe te kennen aan een dataset. Deze is verplicht. Het lijkt praktisch om een optionele property "donl:begrip" toe te voegen waarin optionele begrippen kunnen worden vastgelegd.

Er is (of er moet komen) een mappinglijst vanuit overheid:TaxonomieBeleidsagenda naar de Europese MDR theme taxonomie.

DCAT-AP verplicht dat een thema uit de MDR theme taxonomie opgenomen is per dcat:Resource. DONL verplicht de aanwezigheid van een overheid:TaxonomieBeleidsagenda thema. Deze moet, ook vanuit de machine-leesbare versies, de mapping naar het Europese overkoepelende thema aanbieden.

We moeten contact opnemen met de beheerders van OWMS met de vraag om deze mapping op te nemen in de themadefinities.

Welke organisatie past in welk veld?

Ik denk dat deze link http://publications.europa.eu/resource/authority/planned-availability moet zijn ipv het huidige http://data.europa.eu/r5r/availability/1.0

Equivalent aan #17: Een Dataset kan voorkomen zonder `distributie of Data service. Waarvoor zou zijn "lege" Dataset gebruikt kunnen worden?

De W3C maakt het mogelijk om de metadata zoals titel en beschrijving vast te leggen in verschillende talen. Op data.overheid.nl is nu maximaal een taal mogelijk.

Daarnaast is het mogelijk om de taal aan te geven van de dataset zelf.

De EU biedt ook de mogelijkheid om daarnaast ook apart de taal van de distributie aan te geven.

Wat is hier precies gewenst?

De huidige waardelijsten zijn te vinden op https://waardelijsten.dcat-ap-donl.nl/, maar is dat de gewenste situatie voor 2.0?

Deze lijkt achterhaald. Klopt dat?

Volgens het DCAT 2 model is het mogelijk om catalogs te creeëren waarin geen Datasets zijn opgenomen. In welke gevallen zouden we dergelijke gegevens willen uitwisselen?

Legal Foundation
Er is een wens vanuit verschillende organisaties om de grondslag van een dataset vast te leggen in de bijbehorende DCAT. De W3C en het DCAT-AP (Europese toepassingsprofiel) bieden op het moment geen duidelijke plek voor deze toevoeging.
In DCAT-AP-DONL 1 is er als oplossing gekozen om het veld donl:LegalFoundation te creëren. Op die manier kon deze data onder een duidelijke op vastgelegd worden. Helaas word dit veld niet door andere catalogi ondersteund.
Voor het toepassingsprofiel DCAT-AP-DONL 2.0 is er gekeken of er ondertussen aanpassingen zijn in W3C of DCAT-AP waarmee de grondslag beter beschreven kan worden. Dat is helaas niet het geval. Wel wordt er vanuit OWMS overheid:grondslag geboden. Dit veld wordt breder gedragen en bied verder de gezochte functionaliteit (juriconnect, linktekst, foaf:page).
In de toekomst zal van OWMS worden overgegaan naar TOOI, het veld grondslag zal daar aanwezig zijn, maar specificaties zijn nog niet bekend. Aangezien dit binnen KOOP wordt ontwikkeld is er contact over de mogelijke invullingen, deze lijken naast de huidige functionaliteit alleen maar extra mogelijkheden te krijgen. Daarnaast wordt er ook aan gebruikers (zoals DONL) om input gevraagd.

Zusterissue van #33

Deze kan een string literal zijn, zoals Gemeente Haarlem, maar ook een geografisch object.

Distributie heeft eigenschappen dct:format en dcat:mediaType. Voor dcat:mediaType wordt verwezen naar de waardelijst van IANA, zie https://www.iana.org/

Is het nodig om beide eigenschappen op te nemen?

Op verzoek van Andre van Brussel dit issue aangemaakt:
De huidige DCAT 2.0 DONL versie hanteert overheden als aanbieder van databronnen en dataservices.

Dat is niet in lijn met de interbestuurlijke datastrategie. Ook data van niet-overheden die nodig is voor de overheid behoort tot de scope denk aan mobiliteit, zorg, energie. . Graag hier kijken welke actie hier op korte termijn opgenomen kan worden, hetzij in lopend traject hetzij in traject naar NL profiel. De bijbehorende omschrijving waar dit uit volgt:
https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/nieuwe-technologieen-data-en-ethiek/interbestuurlijke-datastrategie/

Huidige data.overheid.nl ondersteunt wel een handmatig toegevoegde groep niet-overheden, maar bredere ondersteuning lijkt gewenst.

Ten eerste moeten we besluiten in hoeverre we externe organisaties toestaan op DONL.
Daarna moet worden ingevuld hoe we deze informatie verwachten en opslaan.

Waarom zou je deze gegevens op twee plaatsen willen vastleggen? Alleen bij distributie lijkt voldoende.

Het "update/modification date" veld is belangrijk om de kwaliteit van de aangeboden distributie te kunnen inschatten: Een oude dataset heeft minder waarde dan een nieuwere. Ook kan deze eigenschap niet worden afgeleid.
Dus het lijkt passend om op zijn minst deze property "aanbevolen" te maken.
Maar zijn er bezwaren om de property verplicht te maken? Zou dat leiden tot uitvak van datasets? Uitval lijkt op te lossen met een beschrijving hoe het veld in te vullen als de distributie er geen waarde voor heeft.

Distribution Property: has policy maakt het mogelijk om met Open Digital Rights Language (ODRL) in detail toegangsrechten tot een dataset te beschrijven. Dit overlapt met "license", "access rights" en "rights. Om ODRL te gebruiken is veel expertise nodig. Op dit moment lijkt ODRL niet gebruikt te worden.
Moet deze property in de NL extensie opgenomen worden of hebben we op dit moment genoeg aan de voornoemde drie properties.

Het kenmerk contactpunt (vCard, minimaal e-mail adres) is via Resource gekoppeld aan Catalog, Dataset en Dataservice.
Mogelijk is het voor de ketens zinvol om ook een contactpunt op te geven bij de Distributies. Maar ook zouden de bestaande contactpunt al voldoende zijn.

Met het Catalogrecord worden wijzigingen bijgehouden van Catalog, Dataset en Dataservice. Dit kan zowel een wijziging in de gegevens van een Dataservice betreffen, asl een wijzigingen in de DCAT gegevens zelf, zoals de wijzigingen van een titel.
Omdat iedere Catalogrecord een datum van wijziging heeft, kan hierbij een complete administratie van alle wijzigingen op een DCAT resource worden bijgehouden.

De laatste wijziging wordt bij alle classes, zowel in Catalog, Dataset en Dataservice als in Distribution met dct:modified bijgehouden.

In welke gevallen is het nuttig om om een Catalog record aan te maken van iedere wijziging?

Om afnemers van data.overheid.nl - op het portaal - inzicht te verschaffen in de structuur van een distributie van een dataset, bijvoorbeeld in de betekenis van de kolommen in een spreadsheet, willen we graag een data schema opnemen bij de distributie.

De vragen zijn:

1. Welke kenmerken willen we hierin beschrijven en
2. Hoe gaan we die kenmerken structureren.

Een mooi voorbeeld hiervan is opgenomen in Data on the Web Best Practices, Best Practice 3: Provide structural metadata, zie https://www.w3.org/TR/dwbp/#StructuralMetadata

Een mogelijk oplossing hiervoor is ISO19110 FeatureCatalog, Geographic information – Methodology for feature cataloguing (iso19110) — GeoNetwork opensource v3.10 GeoNetwork Documentation (geonetwork-opensource.org), zie https://www.geonetwork-opensource.org/manuals/3.10.x/en/annexes/standards/iso19110.html

Hoe gaat het veld contactpoint in resource gevuld worden?

Het is mogelijk om voor dcat:contactPoint een waardelijst te creëeren waarin leveranciers staan tezamen met het mailadres (Vcard), maar het invullen kan ook door de gebruiker worden gedaan.

De waardelijst voor ruimtelijke dimensies van een dataset https://waardelijsten.dcat-ap-donl.nl/overheid_spatial_scheme.json zou wat mij betreft uitgebreid moeten worden met: regio (allerlei soorten regio's) en wijken en buurten. Het CBS heeft hier sterk behoefte aan. Ik stel niet voor om al die regio's of wijken en buurten dan in te vullen, maar wel om de mogelijkheid te hebben om aan te geven dat de dataset geografische informatie op dit niveau bevat.

W3C specificeert de eigenschappen dct:accessRights zowel voor Distribution als voor Datasets en Dataservices (in superklasse Cataloged Resource). Zie https://www.w3.org/TR/vocab-dcat-2/#Property:distribution_access_rights

DCAT-AP-EU neemt dct:accessRights in Distribution niet over.

Is het zinvol om eigenschap access rights zowel in de Dataset als in de Distribution te beschrijven?

Binnen de Nederlandse overheid zullen ook "gesloten" gegevensverzamelingen met DCAT worden beschreven. (Onder gesloten gegevens verstaan we hier wij gegevens die om diverse redenen alleen onder voorwaarden kunnen worden afgenomen omdat ze bijvoorbeeld vertrouwelijk of privacy-gevoelig zijn of alleen na betaling beschikbaar)

In sommige gevallen zou er de behoefte kunnen zijn om het adres waarop dit soort gegevens beschikbaar is, niet openbaar aan te bieden. Om deze reden zijn bijvoorbeeld in het profiel van Vlaanderen een aantal velden optioneel gemaakt die in W3C verplicht zijn gesteld.

In DCAT wordt de toegangsinformatie opgenomen bij iedere Distributie en Data service.

Distributie

Een distributie beschrijft de eigenschappen van een beschikbare download, in dit geval met gesloten gegevens. De Dataset van deze gegevens beschrijft de inhoud van de gegevens zodat geïnteresseerde partijen op de hoogte zijn van het bestaan van deze informatie.

Als de aanbiedende partij geen toegansinformatie over de distributie wil geven, dan zijn er twee oplossingen.

Neem geen Distributie op in DCAT

Het is mogelijk om wel de beschrijvende Dataset te nemen, maar de bijbehorende Distributie(s) weg te laten. Dan zijn ook de Download url en de Access url niet beschikbaar.

Neem de Distributie op zonder Download url en de Access url

In iedere Distributie mogen Download url en de Access url weggelaten worden aangezien deze velden optioneel zijn. Hoewel ze wel worden aanbevolen, levert weglaten geen technische problemen op.

Data Services

Bij Data Services is het endpoint URL veld wel verplicht. Als dit optioneel wordt gemaakt, is het profiel niet langer compatible met de W3C standaard of DCAT-AP. Het DCAT-AP Vlaanderen heeft dit veld dan ook verplicht gehouden.

Het lijkt daarmee noodzakelijk dit veld ook in DCAT-AP-DONL en DCAT-AP-NL verplicht te houden.

Zowel in de values als in de beschrijvende informatie van DCAT kunnen meerdere talen voorkomen. Om dat aan te geven worden zowel dct:language als het language-tag achter een literal gebruikt.
Maar in de praktijk kennen veel datasets slechts 1 taal. Die taal wordt dan met dct:language aangegeven.
Vraag: Moet in het geva; er slechts 1 taal voorkomt, de language-tag nog worden toegevoegd aan de literals? Merk op dat een literal met of zonder language-tag een ander type heeft in Linked Data, wat bijvoorbeeld gevolgen heeft voor SPARQL queries. Streven we naar uniformiteit of eenvoud?

Het is niet helemaal duidelijk wat hier moet worden ingevuld in een specifieke resource zijnde een dcat:Dataset, dcat:DataService of dcat:Catalog.

Volgens W3C is het bereik dct:Standard.

Dit is een issue m.b.t. het schrijven van de documentatie. Het blijkt dat er RESPECC een tag voor definitie kent, waar dan direct naar verwezen kan worden met bij de definitie een popup met links naar de plekken die naar deze definitie verwijzen: https://respec.org/docs/#definitions-and-linking

Is het een idee om dit tag te gebruiken voor definities in de Termenlijst?
Ik heb een testje opgezet met de term "Open Data" om te kijken hoe goed dit in de praktijk werkt.

dct:license en dct:rights zijn te vinden in resource én in dataservice. Wanneer moet je nu welke eigenschap invullen?

Data.overheid.nl wil haar eindgebruikers inzicht bieden in de kwaliteit van datasets, zodat zij beter in staat zijn om de voor hen gewenste dataset te selecteren. Hierbij kan worden gedacht aan een filter-optie op de website, waarmee eindgebruikers datasets kunnen filteren op bepaalde kwaliteitskenmerken.

Het Europese toepassingsprofiel van DCAT-2 heeft geen uitwerking voor dit punt. De DCAT-2 standaard beschrijft het volgende:

The Data Quality Vocabulary (DQV) offers common modelling patterns for different aspects of Data Quality. It can relate DCAT datasets and distributions with different types of quality information including:

• dqv:QualityAnnotation, which represents feedback and quality certificates given about the dataset or its distribution.
• dqv:QualityPolicy, which represents a policy or agreement that is chiefly governed by data quality concerns.
• dqv:QualityMeasurement, which represents a metric value providing quantitative or qualitative information about the dataset or distribution.

Each type of quality information can pertain to one or more quality dimensions, namely, quality characteristics relevant to the consumer. The practice to see the quality as a multi-dimensional space is consolidated in the field of quality management to split the quality management into addressable chunks. DQV does not define a normative list of quality dimensions. It offers the quality dimensions proposed in ISO/IEC 25012 and [ZaveriEtAl] as two possible starting points. It also provides an RDF representation for the quality dimensions and categories defined in the latter. Ultimately, implementers will need to choose themselves the collection of quality dimensions that best fits their needs.

W3C heeft in 2016 een notitie gepubliceerd waarin ze een framework beschrijft om de kwaliteit van datasets te beschrijven [VOCAB-DQV]. Zie ook https://www.w3.org/TR/dwbp/#quality.

Tijdens de kick-off van de DCAT-A-DONL werkgroep op 7 oktober 2021 hebben we dit onderwerp kort besproken. Al snel werd duidelijk dat dit onderwerp complex is, omdat kwaliteit geen eenduidig begrip is. Als mogelijk oplossing werd geopperd om eindgebruikers op data.overheid.nl de mogelijkheid te bieden om feedback over de kwaliteit van gegevens te geven. Deze feedback bevat mogelijk interessante informatie voor toekomstige afnemers. Dit is overigens een oplossing die zou kunnen werken voor data.overheid.nl, maar die niet geschikt is voor uitwisseling met andere data-platforms.

Vragen:

1. Is het gewenst om informatie over de kwaliteit van gegevens op te nemen in toepassingsprofiel van DCAT?
2. Welke informatie zou dat moeten zijn?
3. Hoe moet deze informatie worden gestructureerd?

Dit wordt nog besproken binnen Europa

Zusterissue van #34

Er lijkt onduidelijkheid te zijn rondom de definitie van dcat:Catalog. Wat is het precies en wanneer wordt het gebruikt?

• Wanneer is een catalogus een dcat:Catalog?
• Wanneer is een catalogus een dcat:Dataset?

Volgens de specificatie wordt deze eigenschap als volgt gedefinieerd:
Deze eigenschap verwijst naar een persoon of organisatie, anders dan contact point, resource creator of publisher die ook een verantwoordelijkheid draagt voor de resource.
Maar wat zijn voorbeelden hiervan, deze toevoegen aan de specificatie.