voorstel
De cardinaliteit voor dataset titel naar [1..1]

motivatie
alignatie met DCAT-AP

voorstel
.De cardinaliteit van toegankelijkheid op dataset en data service worden [1..1]

motivatie
De eigenschap toegangsrechten (dct:accessRights) geeft in beknopte zin weer of een dataset/data service publiek toegankelijk is.
Dit is basisinformatie waarmee portalen op een eenvoudige wijze een indicatie kunnen geven over de toegankelijkheid.

Om het aggregreren van informatie komende van verschillende bronnen eenduidig te maken is er nood aan goed identificator beheer.

De aanpassingen aan de kandidaat standaard omvatten 2 elementen:

• het aligneren met DCAT en DCAT-AP met betrekking tot the URI mapping. In DCAT(-AP) is dct:identifier gemapt op een eigenschap met als range Literal. Echter voor een harmonisatie binnen OSLO is er gekozen om voor identificatoren de klasse https://data.vlaanderen.be/doc/applicatieprofiel/generiek-basis/#Identificator te gebruiken. Hoewel beiden hetzelfde doel nastreven is er hier een 'typologisch' conflict. Het aangepaste voorstel is om de DCAT-AP identificator aanpak te gebruiken:
  - identificator (dct:identifier) -> rdf:Literal
  - alternatieve identificator (adms:identifier) -> https://data.vlaanderen.be/doc/applicatieprofiel/generiek-basis/#Identificator
  Dit is DCAT conform, maar laat ook toe om naar OSLO harmonisatie te streven.

• een cardinaliteits aanpassing. De primaire identificator is identificator (dct:identifier). Deze moest reeds een waarde hebben, maar het voorstel is om deze te verstrengen tot minimaal 1 en maximaal 1.
  Andere identificatoren (eventueel voor lokaal beheer in van de catalogus door een editoriaal systeem) worden opgenomen als een alternatieve identificator.

De primaire idenfiticator is degene die gegeven wordt door organisatie die de beschreven entiteit beheert. Enkele voorbeelden: indien een gemeente een webservice beschrijft dan is de gemeente ook verantwoordelijke voor de keuze van de identicator. Als die gemeente de webservice beschrijft via een centrale systeem en daarnaast deze webservice ook op zijn eigen platform deelt, dan wordt er verwacht dat beiden dezelfde identificator hebben.
Goed identificator management door alle partijen is een onderliggende basisprincipe van het applicatieprofiel voor metadata-DCAT.

The OGC ServiceType registry needs to be updated - it represented a snapshot in time and requires a formal governance process in place to update it. Early OGC specifications did not define explicit conformance classes.

Recognising the validity of the process of profiling DCAT to reference OGC services in a standardised way, it is preferable to liaise with the community to identify a set of requirements and implement a common solution by publishing such a profile directly by the OGC, and updating the necessary register of conformance class targets.

Conformance classes will provide a viewpoint via Linked Data and content-negotiation to allow discovery of resources that can be used to implement or validate conformance, using the Profiles vocabulary which is designed for this purpose. Please register the set of conformance classes required at https://github.com/opengeospatial/NamingAuthority/issues and we will publish canonical URIs for these.

The proposal is thus to define conformance targets for OGC services using either a general type from the ServiceTypes registry, or a more specific conformance class defined as a narrower term of these if required, for individual methods. These specific conformances classes could be owl:sameAs or skos:exactMatch, but skos:broadMatch should be used to reference general specifications or versions.

Hi @bertvannuffelen
There seems to be some rules in the mdcat shape that should be there:

• https://data.vlaanderen.be/shacl/metadata_dcat#CatalogusRecordShape/0311d40d6c8081dc49766336ad753baee5d276f2
• https://data.vlaanderen.be/shacl/metadata_dcat#CatalogusRecordShape/48c46070935428444a8dfe37e3b3172aa804f5e0
• https://data.vlaanderen.be/shacl/metadata_dcat#VoorbeeldWeergaveShape/ad42d11500885f18c10b5ee1a87b5ceca761f903

I've also noticed that the URI "http://data.vlaanderen.be/ns/metadata-dcat#bron metadata record landingspagina" is used in some places but doesn't seems correct.
Shouldn't it be http://data.vlaanderen.be/ns/metadata-dcat#landingpageVoorBronMetadata instead ?

voorstel
De cardinaliteit van catalogus titel is [1..1]

motivatie
alignatie met DCAT-AP

voorstel
De cardinaliteit van catalogus beschrijving is [1..1]

motivatie
alignatie met DCAT-AP

voorstel
de cardinaliteit van dataset beschrijving naar [1..1]

motivatie
alignatie met DCAT-AP

Hi @bertvannuffelen

As discussed during the webinar, can you delete the max cardinality check on the statuut for dcat-ap-vl ?

Rule: https://data.vlaanderen.be/shacl/DCAT-AP-VL#CatalogusResourceShape/689a62fc19cecbb3a76f9ab47547113775587884 (dcatapvl.jsonld#L3446)

motivatie
Veel dataservices hebben een pagina waar men de (operationele) status kan aflezen.

voorstel
Het toevoegen van een landingspagina voor statusinformatie.

voorstel
De cardinaliteit van toegangsURL voor distributie naar [1..1]

motivatie
Een distributie is de dataset waartoe het behoort in een concrete vorm. Het beschrijven van de distributie is dus een bewijs dat er op een of andere wijze toegang is tot deze vorm. Dus zonder een verwijzing naar hoe men toegang kan krijgen tot de data is het bestaan van een distributie vrij zinloos.

Bijkomend is dit een alignatie met DCAT-AP.

Motivatie
Het is voor het gebruiken van de API endpoints nood aan om de conformiteit t.o.v. een (technisch) protocol weer te geven.
B.v. om aan te geven of het een WFS, REST, SPARQL, ... is.

Gerelateerd hieraan willen we ook kunnen aangeven aan welke informatiestandaarden de inhoud van de API ontsluiten. Hiervoor zou de eigenschap dct:conformsTo van de gerelateerde dataset aan de dataservice (via biedtInformatieAanop).

voorstel
Omdat een API aan verschillende aspecten conform kan zijn stellen we voor om een subproperty dct:conformsTo te maken conform aan protocol.

De lijst van relevante vragen en issues in het algemene discussieforum is https://github.com/Informatievlaanderen/OSLO-Discussion/issues?q=is%3Aissue+is%3Aopen+label%3A%22Thema%2FMetadata+voor+services%22

context
Er zijn een aantal mogelijkheden om een juridische en wettelijke context te beschrijven waarin de entiteit zich bevindt.
In DCAT wordt het advies en gebruik van de eigenschappen die hierop betrekking hebben gegeven in https://www.w3.org/TR/2020/REC-vocab-dcat-2-20200204/#license-rights

Echter deze eigenschappen kunnen toch nog op verschillende wijzen ingevuld worden. Daarom het volgende voorstel.

voorstel
Het (voorlopig) niet gebruiken van ODRL (hasPolicy) wegens de complexiteit die dit met zich meebrengt.

licentie in een stricte zin te gebruiken: namelijk door te verwijzen naar een publieke URL die de licentie aanduidt. Bijvoorkeur ook geannoteerd zoals DCAT-AP voorschrijft. Om complexe interpretaties te voorkomen beperken we ons tot 1 licentie, waarbij indien een keuze moet gemaakt worden de hergebruiklicentie wordt meegegeven.

toegangsrechten (toegankelijkheid in DCAT-AP-VL, dct:accessRights) worden gebruikt om op een binaire wijze aan te geven wat de hoofddoelstelling voor toegang is van deze service of dataset. Ofwel publiek (eventuele technische hindernissen zoals authenticatie om misbruik te voorkomen zijn toegelaten) ofwel niet-publiek (er moet een complexe procedure gevolgd worden om toegang te krijgen tot de service of data, waarbij men ook kan afgewezen worden).

rechten vormt een verzameling van uitdrukkingen van juridische aard. Gaande van specifieke gebruiksafspraken, de te-gebruiken bronvermelding, ... tot documenten die een SLO of SLA beschrijven. Het voorstel is om voorlopig (nog) geen onderscheid te maken op basis van de juridische aard van de informatie, en deze informatie allemaal te verzamelen onder 1 noemer rechten.

De landingspagina voor wettelijke rechten (een subproperty van landingspagina) wordt dus met dit voorstel ook verwijderd. En met dit voorstel sluit het delen van juridische informatie nauw aan de gebruiksbepalingen in DCAT. (Zie https://www.w3.org/TR/vocab-dcat-2/#license-rights)

voorstel
De cardinaliteit van catalogus uitgever is [1..1]

motivatie
Hiermee zorgt men ervoor dat men het contact met de verantwoordelijke organisatie van de catalogus niet verliest.

Bijkomend een alignatie met DCAT-AP.

In https://test.data.vlaanderen.be/doc/applicatieprofiel/DCAT-AP-VL/erkendestandaard/2022-04-21#Dataset%3Avoorbeeldweergave staat een vraagteken in de definitie. Die moet verwijderd worden.

voorstel
de cardinaliteit van uitgever is [1..n] voor catalogus als voor de resources die de catalogus beschrijft.

motivatie
De verplichting om een uitgever op te geven zorgt ervoor dat elk beschreven entity een aanspreekpunt zal hebben. Hetzij in een beperkte verantwoordelijkheid als toegansverstrekker, hetzij als de uitgebreidere verwoordelijkheid als toegangsverstrekker en beheerder.

Echter het komt voor dat er meerdere uitgevers zijn, en dat om dit toe te laten wordt er dus voorgesteld om de maximale cardinaliteit niet te beperken.

voorstel
Het wijzigen van de cardinaliteit naar [1..1]

motivatie
De hiermee kan het aggregatieproces vereenvoudigd worden doordat de publisher aangeeft of er een wijziging is gebeurt aan de de beschrijving van de CatalogusResource.

Bijkomend is dit dan ook gealigneerd met DCAT-AP

@bertvannuffelen

It seems there is an issue in rule https://data.vlaanderen.be/shacl/DCAT-AP-VL#DataServiceShape/c5f6c428a4ae32239d9662d58fa65ae4f0cf49e6 => dcatapvl.jsonld#L2190

Compared with the rule https://data.vlaanderen.be/shacl/metadata_dcat#DatasetShape/c5f6c428a4ae32239d9662d58fa65ae4f0cf49e6 => metadata_dcat.jsonld#L2830, the value expected for the skos:inScheme is "http://publications.europa.eu/resource/authority/access-right/PUBLIC".
I suppose the expected value of the skos:inScheme should be "http://publications.europa.eu/resource/authority/access-right" and have a second rule checking the value of the skos:Concept itself to have the value "http://publications.europa.eu/resource/authority/access-right/PUBLIC".

In DCAT-AP there are recommended attributes.
These must be implemented with a template having severity sh:Warning. => additionrules.

motivatie Er was gesuggereerd tijdens de werkgroep dat informatie over het doelpubliek van een service waardevolle informatie om te delen zou zijn.

Echter uit de praktijk testen en evaluatie van de definitie is de zinvolheid om het aan te bieden als een extra bijkomende landingspagina niet gevonden.
Indien men dit toch wil beschrijven, voegt men dit toe als onderdeel op de landingspagina.

voorstel
Het verwijderen van de bijkomende term doelpopulatie als landingspagina.

Hello @bertvannuffelen
It seems there are missing recommended rules for the dcat:Distribution/dct:description element in dcatapvl.json shape.
This property is recommended and is of type literal.
Could you add two rules with the sh:Warning value to the dcatapvl.json shape ?

1. One rule to check on min cardinality of 1 of the dcat:Distribution/dct:description
2. One rule must ensure the dcat:Distribution/dct:description to be a literal (which result in a no empty string check in GeoNetwork schematron)

motivatie Om vragen of opmerkingen ivm een dataset of dataservice te kunnen capteren, is er nood aan contact informatie. Uit ervaring met Open Data is een e-mailadres een verwachting die gemakkelijk kan ingevuld worden. Echter voor dataservices die beheerd worden door een uitgebreide organisatie zoals MAGDA, is een e-mailadres niet de voorkeur. In deze gevallen is een specieke contactpagina (een servicedesk) beschikbaar.

voorstel Het toevoegen van een contactpagina naast een e-mail adres voor contactinfo. De doelstelling is dat 1 van de 2 is opgegeven.

De codelijsten voor de eigenschappen:

• https://data.vlaanderen.be/doc/applicatieprofiel/metadata-dcat#Data%20Service%3Aontwikkelingsstatus
• https://data.vlaanderen.be/doc/applicatieprofiel/metadata-dcat#Data%20Service%3Agebruiksstatus

zijn hier te vinden:

https://github.com/Informatievlaanderen/OSLOthema-metadataVoorServices/tree/master/codelijsten

In https://data.vlaanderen.be/doc/applicatieprofiel/metadata-dcat/kandidaatstandaard/2020-12-14 heeft relatie hoofdonderwerp de cardinaliteit [0..1].

voorstel
veranderen naar cardinaliteit [1..1]

motivatie
Het bestaan van een CatalogusRecord zonder een referentie naar entiteit die gecatalogeerd wordt is zinloos. Bijkomend is dit een alignatie met DCAT-AP.

voorstel

Het toevoegen van de eigenschap wijzigingsdatum (dct:modified) voor Catalogus Record.
Met als basiscardinaliteit [0..1]. (Dus geen 2 wijzigingsdatums).

motivatie
Hiermee wordt aangegeven of wanneer de laatste wijziging aan de beschrijving van het gecatalogeerde resource is gebeurd.

voorstel
De cardinaliteit van een trefwoord is [0..n]

motivatie
Opheffen van foutieve restrictie tot slechts max 1.

voorstel
Het toevoegen van de eigenschap toegankelijkheid (dct:accessRights) aan de klasse Data Service met cardinaliteit [0..1]

motivatie
Het kunnen aangeven van het publieke of niet-publieke character van een data service.