Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hoe/waar wordt beschreven of een (van de) dataservice(s) een REST API, GraphQL API, WFS, etc. is? #119

Open
dvh opened this issue May 8, 2024 · 5 comments
Labels
question Further information is requested

Comments

@dvh
Copy link

dvh commented May 8, 2024

Wellicht heb ik het niet goed begrepen en kan dit issue zo gesloten worden, maar het is mij niet helemaal duidelijk hoe dit beschreven wordt.

Concrete usecase als afnemer: ik haal de dcat informatie van een dataset op en wil weten of er ook een REST API voor deze dataset beschikbaar is.

Als dit zo is zou het volgens mij een dataservice moeten zijn waarbij application profile dit aangeeft. De waarde hiervan lijkt echter een URI te zijn; wat zijn dan de correcte waarden voor "REST" of "GraphQL" bijvoorbeeld? Of is er een andere property waarmee dit beschreven wordt?

@idevisser
Copy link
Collaborator

Je kunt dit inderdaad bij application profile aangeven. Voor REST kun je verwijzen naar https://gitdocumentatie.logius.nl/publicatie/api/adr/

@idevisser idevisser added the question Further information is requested label May 15, 2024
@dvh
Copy link
Author

dvh commented May 22, 2024

Hmmm... Dat is een URI, en bovendien naar de REST API Design Rules (die niet voor elke REST API gelden). Als het per se een URI moet zijn dan zou het m.i. een keuze moeten zijn uit een set voorgedefinieerde URI's die verwijzen naar het type API.

Update: Ik heb me er meer in verdiept en begrijp nu dat DCAT niks zegt over de inhoud van de URI's. Wellicht moeten we vanuit Kennisplatform API's, URI's munten die hier gebruikt kunnen worden en als bijsluiter leveren aan aanbieders van datasets. De enige vraag die ik dan nog wel heb is dat conformsTo lijkt te gaan om welke standaarden geïmplementeerd zijn. In die context snap ik de link naar de REST API Design Rules wel. Maar "REST" of "GraphQL" zijn geen standaarden; mogen die hier dan wel in?

@idevisser
Copy link
Collaborator

Als een API ergens gespecificeerd is, kun je naar die specificatie verwijzen, met de eigenschap conformsTo. Maar dat gaat niet werken voor GraphQL, dat is ook geen API. Dit profiel is alleen voor het beschrijven van datasets en dataservices.

@Bakkej
Copy link

Bakkej commented May 28, 2024

Als we kijken naar de voorbeelden zien we dat dct:conformsTo bij dataservices inderdaad gebruikt wordt om aan te geven wat voor 'soort' dataservice het is. Precies waar @dvh naar zoekt. Specifiek wordt in dit geval aangegeven welk protocol gehanteerd wordt. Dit kan bijvoorbeeld WFS, SOAP, REST of SPARQL zijn maar zeker ook Graphql.
Application profile vind ik wel een verwarrende term hiervoor; de term application profile wordt namelijk vaak gebruikt voor een data specificatie of schema, zo ook bij catalog record. In DCAT-AP-VL heet application profile bij een data service dan ook conform aan protocol een hanteren daarbij een codelijst

Er lijkt niet altijd een defacto manier te zijn om protocollen aan te duiden; op data.europa.eu staan al 15 URI's voor WMS en 13 voor WFS. Voor graphql weet ik niet of daar een de facto URI voor is. Ik denk dat het goed is voor de interoperabiliteit als we hier een lijn in trekken.

Voor het Stelselcatalogus DSO is er gekeken om met dct:type dataservices te typeren als 'REST API` of andere 'soorten dataservices'.
voorbeelden uit DCAT voor conformsTo:

@idevisser
Copy link
Collaborator

Er lopen wat verschillende dingen door elkaar.

De eerder in DCAT-AP gehanteerde property naam "application profile" is nu in de laatste versie van DCAT-AP aangepast naar ConformsTo, dat gaan we het NL profiel ook nog aanpassen.

In de werkgroep hebben we afgesproken dat we in deze eigenschap een verwijzing naar een (technische) vastgestelde standaard of specificatie in opnemen. (overeenkomstige de definitie en usage notes van DCAT-AP). Omdat we niet alle standaarden en specificaties kunnen kennen van alle domeinen is hier geen waardelijst voor.

Daarnaast hebben we de protocollen, in geoDCAT is de eigenschap protocol opgenomen, met de URI dct:conformsTo. Hier zijn URI's voor (vanuit INSPIRE en het NL profiel op ISO 19115). Lijkt me een goed idee dat daar vanuit kennisplatform API's ook URI's voor gemunt kunnen worden die hier gebruikt kunnen worden.

Onder dct:conformsTo worden dus ook protocollen en specificaties opgenomen.

Voor dct;type wordt vanuit de geoDCAT codelijsten voorgeschreven voor servicetype, categorytype en resourcetype;

[INSPIRE-RT]
INSPIRE Registry: Resource types. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/ResourceType

[INSPIRE-SDSC]
INSPIRE Registry: Classification of spatial data services. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory

[INSPIRE-SDST]
INSPIRE Registry: Spatial data service types. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType

Misschien even goed om hier naar te kijken voor acties vanuit Stelselcatalogus DSO of dit past binnen bovenstaande lijnen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants