-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
Je kunt dit inderdaad bij application profile aangeven. Voor REST kun je verwijzen naar https://gitdocumentatie.logius.nl/publicatie/api/adr/ |
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 |
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. |
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 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
|
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-SDSC] [INSPIRE-SDST] Misschien even goed om hier naar te kijken voor acties vanuit Stelselcatalogus DSO of dit past binnen bovenstaande lijnen. |
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?The text was updated successfully, but these errors were encountered: