Verslag werkgroep URI-strategie 15-5-2015

Deze pagina geeft het verslag van de workshopbijeenkomst op de conceptual Friday van 15 mei 2015. De resultaten van de workshop worden per thema benoemd, en daarnaast per onderdeel van de URI-strategie:

http://{domein}/{pad}/{type}/{concept}/{referentie}

Samenvattende conclusie is:

Over bepaalde onderdelen (zie onder) zou het relevant zijn om te kijken of een aanpassing van de URI strategie wenselijk is. Hiervoor is een tweede meeting wenselijk;
Met name de uitleg en toepassingsgebied van de URI strategie kan beter. Nu is het vooral een opsomming van de keuzes en richtlijnen. Gebruikers missen echter een "handleiding": hoe pas ik het nu toe;
Het lijkt zinvol om een aantal patronen/toepassingsgebieden te onderkennen en specifieke best-practices inclusief voorbeelden toe te voegen.

Thema's[bewerken]

Scope van de URI strategie[bewerken]

Uit de feedback die terugkomt over het gebruik van de URI strategie blijkt dat het niet altijd precies duidelijk is waar de URI strategie voor bedoeld is. Zo is er de vraag of de URI strategie een standaard is, of alleen een best practice. En als het alleen een best practice is: hoe erg is het als je er niet aan houdt? Hiervoor zou betere uitleg kunnen komen. Ook wordt wel gedacht dat de URI strategie een keuze voor Linked Data inhoudt. Dat is niet zo. De URI strategie gaat alleen over URI's voor de identificatie van resources die als Linked Data op het web gepubliceerd worden. Voor partijen die data niet als Linked Data publiceren speelt de URI strategie niet, evenals partijen die de data niet publiceren. Wel lijkt het relevant om iets meer te formuleren over de URI's die handig kunnen zijn als wel sprake is van Linked Data, maar geen sprake is van URI's die gepubliceerd worden op het web. In de W3C richtlijnen zie dat bijvoorbeeld voor niet-publieke URI's gedacht wordt aan UUID-URN's. Ook wordt daarbij gesproken over het verbinden van de UUID-URN's met een publieke URI via owl:sameAs als blijkt dat toch een publieke URI nodig is.

Besluit: opnemen van een duidelijke paragraaf over doel en inzet van de URI-strategie, en voorstellen doen voor munten van URI's die buiten de inzetscope van de huidige URI-strategie vallen.

Gebruik van een BSN in de URI strategie[bewerken]

In voorbeelden over de URI-strategie wordt wel eens het BSN gebruikt. Terecht worden hier kantekeningen bij geplaatst. Dit volgt uit Artikel 24 lid 1 WBP: "Een nummer dat ter identificatie van een persoon bij wet is voorgeschreven, wordt bij de verwerking van persoonsgegevens slechts gebruikt ter uitvoering van de betreffende wet dan wel voor doeleinden bij de wet bepaald". Het gebruiken van een BSN of een URI waarin de BSN zit, mag alleen in specifieke gevallen, en zeker niet automatisch als linked data. Overigens geldt dit niet specifiek voor BSN. Ook een BTW nummer van een ondernemer kan het BSN nummer bevatten, als de ondernemer een natuurlijk persoon is. Een dergelijk BTW nummer zou echter ook onder dit artikel vallen. Feitelijk geldt dus dat het niet uitmaakt of we hier spreken van een BSN of een ander nummer: als het een persoon bij wet uniek identificeert, dan is het artikel van toepassing. Het is daarmee eerder een juridisch vraagstuk dan een linked data vraagstuk. Wel is van belang om in voorbeelden voorzichtig te zijn met het gebruik van persoonsidentificerende nummers, en daarbij ook altijd de WBP bepaling in gedachte te houden.

Besluit: persoonsidentificerende URI's in algemene voorbeelden niet gebruiken. Daarnaast een workshop beleggen specifiek rondom dit onderwerp.

Organisatienaam in de URI strategie[bewerken]

Voor persistente URI's is een richtlijn om geen zaken op te nemen in de URI die over de tijd heen kunnen veranderen. Vandaar dat het opnemen van de organisatienaam wordt afgeraden. Toch blijkt in de praktijk dat veel organisaties vanuit herkenbaarheid of vanuit zelfbeschikking graag de organisatienaam op willen nemen. Bovendien geldt dat deze domeinnaam altijd beschikbaar is, wat niet altijd wil gelden voor domeinnamen die dichter bij de naam van de registratie liggen (zo zijn bag.nl, brk.nl en nhr.nl allemaal al in bezit bij andere organisaties). Daarnaast geldt dat ook bij het niet opnemen van de organisatienaam veranderingen mogelijk zijn. Zo zijn bepaalde basisregistraties in het verleden van naam veranderd. Hoewel de richtlijn op zichzelf goed is, is het verstandig om meer aandacht te schenken aan het doel: persistente URI's, maar ook om richtlijnen op te nemen hoe je omgaat met situaties waarbij de domeinnaam toch wijzigt. Het internet biedt hiervoor voldoende en goede middelen. Zo is de website van www.vrom.nl nog steeds bereikbaar, en wordt verkeer doorgestuurd naar de huidige website van het ministerie.

Besluit: handhaven van de richtlijnen, meer nadruk op het doel leggen en de richtlijn opnemen hoe om te gaan bij een naamswijziging.

Betekenis in de URI[bewerken]

Het gebruik van een URI-strategie lijkt betekenis in de URI te veronderstellen, in het bijzonder in het onderdeel {concept}. De W3C linked data richtlijnen geven echter aan dat van een URI nooit een betekenis mag uitgaan (zie http://www.w3.org/TR/webarch/#uri-opacity), en dat alle betekenis zit in de triples die opgevraagd kunnen worden over de betreffende resource. Overigens geldt wel dat bepaalde linked data tools gebruik maken van de opbouw van een URI om specifieke functionaliteit toe te passen, bijvoorbeeld een andere schermopbouw afhankelijk van de URI. Het gevoel bij de werkgroep is dat dit vooral komt door de achtergrond van dergelijke tools, en dat op termijn dit anders opgelost zal gaan worden. Het mag in ieder geval niet leiden tot een situatie waarbij geweld wordt gedaan aan de W3C uitgangspunten.

Besluit: verwijzen en toelichting opnemen bij de URI strategie over het betekenisloos zijn van de URI.

Betekenis, identiteit en persistentie[bewerken]

Een belangrijk aspect aan het toekennen van URI's is het verbinden van een "ding in de werkelijkheid" met een identificatie. Persistentie gaat dan over het toegankelijk blijven van de URI, en dat de URI blijft verwijzen naar het oorspronkelijk "ding in de werkelijkheid". Echter dit is eenvoudiger gezegd dan gedaan: een "ding in de werkelijkheid" kent immers ook een verandering. Met het toekennen van de URI zal dus ook nagedacht moeten worden over de identiteit waarnaar de URI verwijst: wanneer is het iets anders, en wanneer blijft het ding hetzelfde.

Een voorbeeld dat hier ook mee te maken heeft is de term "Obama". Op de engelse wikipedia geldt dat http://en.wikipedia/wiki/Obama nu verwijst naar de 44e president van de USA. Beter gezegd: de pagina redirects naar http://en.wikipedia/wiki/Barack_Obama. Maar jaren terug was Obama nog niet in beeld, en verwees deze pagina naar een andere onderwerp. De beheerders van wikipedia hebben een mechanisme uitgewerkt om met dit soort situaties om te gaan.

Besluit: meer uitleg over de relatie tussen identiteit, persistentie en betekenis van hetgeen de URI naar verwijst, en het beschrijven van mechanismen hoe omgegaan kan worden met veranderingen.

Qualified names[bewerken]

Een relevant aspect dat in het gebruik van de URI-strategie naar voren komt, maar oorspronkelijk minder aandacht heeft gekregen is het gebruiken van qualified names. De qualified name bestaat uit een prefix en een local name. Aangezien de local name geen hash of (back)slash kan bevatten, geeft dit aan tot waar de prefix gaat. In bepaalde gevallen kan dit betekenen dat er heel veel verschillende prefixen zijn. Daarnaast geldt dat het gebruik van een local name die begint met een cijfer vaak tot problemen leidt. Aangezien de huidige URI-strategie na de laatste slash bestaat uit {reference} en dit vaak een getal is, zal een dergelijke toepassing van de URI-strategie gevolgen hebben voor het gebruik van qualified names

Besluit: de consequenties hiervan zullen verder moeten worden onderzocht en meegenomen worden bij versie 2.0 van de URI-strategie

Converteren van bestaande data versus originele linked data[bewerken]

De URI strategie is ontstaan vanuit de behoefte om vanuit een bestaande (relationele) dataset te komen tot een linked data dataset. Het patroon is hiervoor relatief eenvoudig waarbij als {reference> de primaire sleutel wordt, en {concept} de naam van de tabel. Dit maakt conversie eenvoudig omdat foreign keys dan bijna altijd ook goed zullen worden overgenomen, zonder dat gezocht moet worden naar de juiste waarde. Dit kan echter op gespannen voet staan met de betekenis en identiteit van een object. Bijvoorbeeld als er overlap zit tussen de tabellen "student" en "medewerker", terwijl de bedoeling was om URI's te vormen voor relaties van een school. Het gebruik van een UUID maakt het feitelijk overbodig om het onderdeel {concept} op te nemen in de URI strategie ten behoeve van uniciteit. Dit heeft echter direct consequenties voor de toepassing van qualified names en de leesbaarheid van de URI.

Waardelijsten, begrippen, klassen, SKOS en OWL[bewerken]

De discussie over waardelijsten, begrippen, klassen en het gebruik van SKOS vs OWL raakt ook de URI strategie, immers: als je verschillende "dingen" onderkent, heeft elk van deze "dingen" een eigen URI nodig. Dit element wordt ook geraakt in de werkgroep rondom SKOS-AX, zie hiervoor: Ontwerp SKOS-AX.

Besluit: aansluiting zoeken op dit onderwerp met de SKOS-AX werkgroep.

Context in de URI[bewerken]

Als het gaat om identiteit en betekenis is ook relevant om na te gaan hoeveel context in de URI opgenomen moet worden (denk bijvoorbeeld aan tijdstip, versies, locatie, etc. De vraag speelt hierbij echter of het nog wel gaat over URI's voor identificatie, of dat het hier gaat om URI die feitelijk een query vormen ("geef me de informatie over "ding", voor zover deze bekend waren op "tijdstip", vanuit de invalshoek "x"). Hoewel dit dus feitelijk geen onderdeel meer is van de URI-strategie, lijkt het wel goed om expliciet aan te geven dat dit GEEN onderdeel van de URI-strategie is. Wel is dit een onderwerp om verder op door te gaan en te kijken of hiervoor ook richtlijnen te geven zijn. Overigens is ook dit geen zwart-wit verhaal. In bepaalde gevallen wil je namelijk expliciet informatie over een bepaalde versie van een ding opnemen, en dan zal je dit ook echt moeten versleutelen in de URI (denk bijvoorbeeld aan het FRBR model).

Besluit: in de scopebeschrijving van de URI-strategie dit expliciet beschrijven. Aanvullende workshop organiseren rondom dit thema.

Besluiten per onderdeel[bewerken]

Domein en pad[bewerken]

Over het gebruik van organisatienamen in het domein is hierboven al ingegaan. Daarnaast lijkt het gebruik van {pad} in bepaalde gevallen handig, maar is het vaak handiger om dit in de domein op te nemen. Reden is vooral van technische aard. Het domein geeft aan welke webserver de request zal afhandelen. Zo kan http://data.overheid.nl een afzonderlijke webserver zijn, en zal http://www.overheid.nl/data ook "normaal" webverkeer gaan verwerken. Dit kan technisch wel opgelost worden met redirects en proxies, maar dit kan in bepaalde gevallen ook weer tot problemen leiden.

Besluit: handhaven van de richtlijn, verder uitwerken wat de technische consequenties zijn.

Type[bewerken]

In de huidige URI-strategie kan het "type" deel drie waarden hebben: "doc", "id" en "def". Voor het toepassen van een 303-strategie (onderscheid tussen de resource en informatie over de resource) is het onderscheid van "doc" en "id" relevant en goed bruikwaar. Wel geldt dat in de praktijk niet altijd sprake is van "id" en "doc" (bijvoorbeeld DBPedia, waar "resource" en "page" wordt gebruikt). Het is wenselijk om vooral het belang van het onderscheid aan te geven, waarbij "id" en "doc" dan de voorkeur hebben.

Het gebruik van "def" blijkt in de praktijk minder helder. In de praktijk wordt "def" niet gebruikt voor vocabulaires. Het gebruik van een hash-URI zoals nu gebruikelijk in de URI-strategie voor "def" URI's wordt wel gebruikt (bijvoorbeeld in de meeste W3C vocabulaires). De keuze voor "def" was oorspronkelijk ingegeven door het overnemen van de werkwijze zoals in de UK. Inmiddels zijn we een aantal jaren verder en zou gekeken kunnen worden naar hun huidige ervaringen op dit vlak. Discussie is nog wanneer precies gebruik gemaakt wordt van de "def" URI's. Denk aan het verschil tussen datamodellen, begrippen en vocabulaires.

Besluit: het "def" type staat ter discussie. Definitief besluit en inzet hiervan zal in een volgende werkgroepbijeenkomst aan bod komen.

Concept[bewerken]

Hoewel concept bruikbaar kan zijn voor menselijke leesbaarheid en voor applicaties die de URI gebruiken om specifieke functionaliteit te activeren, lijkt de consensus dat het benadrukken van "concept" de betekenisloosheid van een URI in gevaar brengt. Het lijkt handig om {concept} optioneel te maken, en alleen te gebruiken om de {reference} uniek te maken (zoals in het patroon om van relationele data te komen tot linked data).

Besluit: in een volgende workshop de definitieve beslissing te nemen over de betekenis en inzet van {concept}