Best practices voor URI's van begrippen, begrippenkaders, etc

[architolk]

De opzet van een URI (namespace, local-name) is van belang in het kader van vindbaarheid en ook duurzaamheid van de URI's. Daarnaast kan de opzet van een URI van belang zijn als het gaat om het importeren van bestaande begripsbeschrijvingen.

De volgende drie documenten zijn relevant:

1. Aanzet tot een nationale URI-strategie voor Linked Data van de Nederlandse overheid;
2. European Legislation Identifier - Technical implementation guide;
3. Cool URI's for the web.

[Bakkej]

Deze past ook nog in het lijstje: https://joinup.ec.europa.eu/sites/default/files/document/2013-02/D7.1.3%20-%20Study%20on%20persistent%20URIs.pdf

Dit is een onderzoek naar best-practices voor URI's, in termen van ontwerp en management. Het is gebasseerd op een aantal case-studies.

[RiX012]

Overweging: de URI-strategie uit de NEN2660-2

[architolk]

Afgesproken: we formeren een werkgroep (zie assignees) die de volgende drie dingen voorbereid en teruggeeft aan de grote groep:

1. Verzamelen van de relevante documentatie voor mogelijk oplossingen en standaarden (waarbij bovenstaand al een eerste start is);
2. Verzamelen van huidig gebruik (hoe doen organisaties het nu);
3. Verzamelen van use-cases: wat hebben we nodig (requirements) m.b.t. URI's van begrippen en begrippenkaders.

Merk op: we beperken ons hier tot een URI-strategie voor de dingen die nu in het profiel zitten: begrippen, begrippenkaders en collecties.

[architolk]

Hans Overbeek / Casper le Gras zit ook in de werkgroep, maar kan beiden niet assignen...

[CasperKoop]

@hoverbee en ikzelf. En ik kan mijzelf ook niet assignen.

[KoosBoersma]

Overweggingen die je moet meenemen:

• Tijdreizen als een betekenis van een begrip gaat veranderen, of wel versie
• Termen met een verschillend betekenis. In een woordenboek heb je meerdere definities vanuit een verschillend perspectief.
• Taal. voor iemand vanuit buitenland is een mens leesbare Uri ook niets zeggend.
• Overweging. Dynamisch verbinden van mens leesbaar in tijd aan de UUID's
• Huidig beeld bij gebruik: Binnen de API's vanuit een meta datering (dynamisch resolvable)

[architolk]

We beperken ons voor nu tot de URI's die we hebben gemaakt in concepts/thesaurus.ttl (ons eigen begrippenkader).

• We moeten een beslissing nemen over betekenisvol OF betekenisloos
• Kiezen we voor URN of voor URL
• Als URL: wat wordt de namespace
• Wat kiezen we voor de lokale naam (voorkeursterm, betekenisloos of iets anders - engels?)

Welke argumentatie hebben we hierbij gebruikt? En is dit dan een voorbeeld zoals we dit altijd zouden willen hebben, of alleen slechts een voorbeeld voor dit ene bestand.

[RiX012]

Toch moeilijker dan ik dacht. Maar na een dagje research zou mijn voorstel met beargumentering zijn:

URI/Namespace

Ik zou het graag zo simpel en duurzaam mogelijk willen houden. Daarom zou ik me willen conformeren op de resultaten uit de '10 rules for persistent URIs'. http://assets.aims.fao.org.s3-eu-west-1.amazonaws.com/public/images/URI_Visualisation_v0_03.jpg

Daarmee bedoel ik dus o.a.:

• http://{domain}/{type}/{concept}/{reference} waarbij ik {type} zou hanteren zoals vermeld (id, doc, def, set) en {concept} dan wellicht overbodig vindt.
• En met {type} dan ook het onderscheidt te maken tussen schema (als 'set') en de concepten (als 'def' (hoewel ik ook 'id' zou kunnen begrijpen))
• En dan dus ook gaan voor de URL (i.t.t. URN)
• Geen PLDN o.i.d. ergens in string. Maar gebruik maken van W3id.org (om niet in de val van overdracht in beheerorganisaties te vallen).
• De naamgeving toch te concentreren op zoiets als NL Profiel Begrippencatalogi zodat in het {domain} dit afgekort kan worden naar nl-pb o.i.d.
• Geen versies, behalve op graaf niveau (doormiddel van DCAT/PAV i.c.m. geversioneerde endpoints)
• Er sprake moet zijn van resolvability door http://{domain}/{type}/{concept}/{reference}.ttl en http://{domain}/{type}/{concept}/{reference}.html

Waar ik echter af wil wijken is:

• Gebruik maken van de 'Hash URI' i.t.t. de '303 redirect' (omdat de ontologie toch waarschijnlijk meestal als geheel toegepast wordt en de '303 redirect' gewoon meer beheerslast geeft aan de servers)
• Het expliciet linken van meerdere representaties (voegt te weinig toe denk ik. Beetje kosten baten analyse blijft het wel...)

Concept/representatie/naam

Ik kwam in mijn onderzoek dit (hele oude) document tegen: https://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm en dit klaarde voor mij wel een hoop op. We hebben namelijk altijd gewerkt met de Triangle of Meaning (sectie 2.2) maar dit vond ik altijd wat missen in de SemanticWeb context. Vandaar deze vierdeling die hier genoemd wordt.

Kleine sidenote: In het document '10 rules for persistent URIs' staat ook deze quote:

Other URI schemes may not be dereferenceable in the same way which is the key difference between RDF (which supports the use of any URI scheme) and Linked Data, which depends on HTTP.

Dit lijkt hoe LD zich dan ook ontwikkeld heeft (?): Naamgevend en Document-instantie (1 en 4): "http://blabla.org/love"^^xsd:anyURI , Weblocatie en Concept (2/3): <http://x.org/love>. Waarbij de RDF termtype contextgevended (approach B) is en Weblocatie niet noodzakelijk resolvend is om een Concept te identificeren.

Dat gezegd hebbende zou ik dus pleiten voor:

• Het gebruik van betekenisloze {reference}. Dit hoeven wat mij betreft geen ellelange UUID's te zijn (mag wel), maar het maakt me dus weinig uit. (omdat daarmee enerzijds het persistent houden makkelijk is en anderzijds ook meteen de discussie rondom de 'lokale naam' vermeden wordt. We hoeven dan alleen nog over de labels na te denken)

In voorbeeld:

• Onze definitie van AltLabel zou mijnsinziens te vinden moeten zijn als: https://w3id.org/nl-pb/def#7fh4398
• En het Begrippenkader als: https://w3id.org/nl-pb/set#c88h2h39

Best practice

In alle eerlijkheid denk ik dat dit ook best als Best Practice gehanteerd zou kunnen worden. Dit omdat het niet heel erg invasief is. Waar we dan nog over na zouden moeten denken is:

• Waar zit bewegingsruimte (bijvoorbeeld op het gebruik van ID vs. Name
• Zouden we niet expliciet aan willen geven dat het {type} het er een extra optie term zou kunnen zijn
• Hoe we de invulling van {concept} zien.

[architolk]

De scope is voorlopig alleen de dingen in concepts/thesaurus.ttl, zoals afgesproken. Reden: het andere bestand (het profiel) is voorlopig alleen bedoeld om de Respec te genereren, en bovendien hebben we daar niet echt last van practice-what-you-preach (omdat we geen beschrijving van profielen doen op dit moment...). Het gaat dus concreet om: a) Een URI-template voor begrippen (resources van het type skos:Concept); b) Een URI-template voor begrippenkaders (resources van het type skos:ConceptScheme).

(1) Als we kiezen voor een URN, dan lijkt voor de hand te liggen om het niet ingewikkelder te maken, en te kiezen voor . We weten dan zeker dat de URI niet gaat wijzigen, en we hebben daar dan ook geen reden voor. Wel zitten we altijd vast aan een UUID waarvoor we niet echt een specifieke reden hebben.

(2) Als we kiezen voor een URL, dan zou het wel logisch zijn als de URL ook resolvable is, dwz: je kunt em vinden op het web. De referenties die hierboven al zijn genoemd, geven genoeg voorbeelden en tips hoe je dat dan zou moeten doen. Hier komen we denk ik wel uit (iets als http:///id/concept/) ofzo - eigenlijk dus zoals het nu als is, maar wellicht ff nadenken over de persistente-namespace, dus w3id.org of purl.org ofzo?).

Lijkt me logisch dat we voor zowel (a) als (b) dezelfde keuze maken. Ik ben geneigd om voor (2) te kiezen, omdat een betekenisloze URN eigenlijk alleen maar werkt als je er een goed mechanisme omheen hebt gemaakt. Dit is een standaard, dus je wilt dat mensen je standaard gaan vinden. Het enige waar je afhankelijk van bent, is de term. En die mag wat mij betreft niet veranderen, anders hebben we het over een ander begrip.

Er zijn redenen om voor (1) te kiezen, maar voor mijn gevoel heb je het dan altijd over hele grote thesauri binnen een organisatie die nog veel meer thesauri beheerd potentieel. Een goede keuze voor de Aquo standaard dus bv. Wellicht dat we wat best practices kunnen geven wanneer je (1) en wanneer (2), en dan voor beiden een nette beschrijving hoe je dat dan doet.

Met betrekking tot (1) nog een opmerking: het formaat is altijd , maar de daadwerkelijke code kan verschillen. Zo heb je UUID versie 1 t/m 5. Ik vind versie 5 wel aardig, want die biedt de mogelijkheid om een unieke UUID te maken op basis van aantal elementen. Zo kun je bv een unieke UUID genereren, maar wel gebruik makend van de voorkeursterm van een begrip. Dit garandeert bv. dat je altijd tot dezelfde unieke UUID komt, bij gelijkblijvende begrippen. Kan soms handig zijn!

[architolk]

-- Resultaten uit het overleg ter bespreking --

Belangrijkste criteria die we willen hanteren:

• Zo eenvoudig mogelijk voor de gebruiker;
• Persistent

We onderkennen dat er meerdere situaties zijn die tot andere situaties kunnen leiden. Een belangrijkste eerste vraag die beantwoord moet worden is: "wil je dat de beschrijving van de begrippen vindbaar is op het web?". Als het antwoord op die vraag "ja" is, dan is een http(s) URI noodzakelijk: we willen dat deze standaard vindbaar is op het web EN we willen het zo eenvoudig mogelijk maken, dus zonder dat een dereferencing noodzakelijk is. Een reden om de begrippen op het web terug te kunnen vinden: dit geeft vertrouwen over de betekenis van de begrippen: door de Uri te volgen kom je op de pagina van de "eigenaar" van de URI en daarmee kun je controleren of de betekenis ook conform de eigenaar zo is als je verwacht (er is geen sprake van "valsmunters" bij het munten van de URI).

Besluit: voor thesaurus.ttl gaan we uit van http(s)-URI's

Daarnaast speelt dat in dit specifieke geval we er niet vanuit gaan dat we met tools of databases te maken hebben, dus dat je bv een canonieke "urn"-URI in de database kunt hebben en een alias-"http"-URI die ook resolved.

Een andere belangrijke vraag is: gaan we uit een betekenisloze sleutel voor de "local-name", of de voorkeursterm van het begrip. Een betekenisloze sleutel zou bv een UUID kunnen zijn, maar ook een volgnummertje dat steeds hoger wordt, afhankelijk van het tool dat gebruikt wordt. Een dergelijke betekenisloze sleutel vereist dat er een tool wordt gebruikt dat dergelijke betekenisloze sleutels toekent en een mechanisme dat we daarvoor hanteren. Dit is vooral handig bij grote vocabulaires (zoals bv bij de Aquo-standaard) en waar we het risico lopen dat de voorkeursterms aangepast wordt (zonder dat daarbij een nieuw begrip ontstaat).

In ons geval gebruiken we geen tools en is de kans dat de voorkeursterm wijzigt erg klein (en als het gebeurt kunnen we het zien als een nieuw begrip). Enige risico dat we lopen is dat we de taal zouden aanpassen. We gaan nu uit van het Nederlands omdat dit ook een Nederlandse standaard is.

Besluit: we gaan uit van de Nederlandse voorkeursterm voor de local-name van de URI.

Dan komen we bij het patroon dat we willen hanteren. In Nederland is gebruikelijk om hiervoor het patroon te hanteren dat er als volgt uit ziet: "http://{domeinnaam}/{conceptschemanaam}/id/begrip/{voorkeursterm}" (waarbij de conceptschemanaam eventueel optioneel is als dit al duidelijk is uit de domeinnaam)

Er lijkt niet echt reden te zijn om af te wijken van dit patroon, waarbij nog wel helderheid moet komen over de domeinnaam en de conceptschemanaam.

Besluit: we gaan uit van bovenstaand patroon (NB: in dit geval gebruiken we "begrip" en niet bijvoorbeeld "concept" omdat in onze standaard we ook gekozen hebben om "begrip" centraal te stellen.

Voor de domeinnaam zijn we voorstander van een domeinnaam die niet meer zal wijzigen. Dus niet "kadaster", "egonovum" of "pldn", maar dan liever "w3id" of "purl.org". We kunnen ook een domeinnaam claimen die past bij de standaard zelf (bv thesaurus.standaard-voor-begripsbeschrijvingen.nl)

Besluit: tijdens het overleg van 22 december kiezen we de daadwerkelijk domeinnaam.

Voor de conceptschemanaam is dit afhankelijk van de keuze die hierboven is gemaakt.

Besluit: tijdens het overleg van 22 december kiezen we of, en zo ja, welke conceptschemanaam we hanteren.

[KoosBoersma]

nlbegrip.nl nlbegrip.online zijn geregistreerd

[Bakkej]

Besluit: tijdens het overleg van 22 december kiezen we de daadwerkelijk domeinnaam. domeinnaam: "nlbegrip.nl"

Besluit: tijdens het overleg van 22 december kiezen we of, en zo ja, welke conceptschemanaam we hanteren. naam: "Begrippenkader Nederlandse standaard voor het beschrijven van begrippen"

[ArjenSantema]

1) Als we het ttl bestand volgen krijgt bijvoorbeeld 'alternatieve term' de uri 'http://nlbegrip.nl/sbb/id/begrip/AltLabel'. Dit is niet consistent: begrip is Nederlands, AltLabel is Engels en in strijd met het tweede besluit hierboven (Nederlandse voorkeursterm voor de local-name van de uri). Tot nu toe hebben we voor de naamgeving van de resource de van de Engelse voorkeursterm afgeleide UpperCamelCase spelling zonder spaties en diakrieten tekens gekozen. Engels om ook internationaal bruikbaar te kunnen zijn. Vanuit het Kadaster is dit relevant omdat wij onze begrippen ook willen 'harmoniseren' met (ongeveer) dezelfde/bredere/engere/gerelateerde begrippen uit andere landen. Ik denk dat dit ook voor anderen geldt.

2) Los daarvan is even de vraag of de uri 'http://nlbegrip.nl/sbb/id/begrip/AltLabel' of zoiets wordt (een id/begrip/.. uri) of iets als 'http://nlbegrip.nl/standaardbeschrijvingbegrippen#alternatieve-term (nu is het nog https://profielstelselcatalogus.pldn.nl/#dfn-alternatieve-term).

3) Voor begrippen die worden beschreven met ons profiel ligt het wel voor de hand om een ../id/begrip/.. uri te gebruiken, waarbij ik, vanwege de internationale interpreteerbaarheid de voorkeur heb voor concept in plaats van begrip. En we volgens mij twee practices hebben om de .. in te vullen, namelijk met een (UpperCamelCase) naam of met een UUDI.

[RiX012]

Misschien is het handiger om dit issue op te splitsen (close en 2 nieuwe met een mention) in twee delen:

1. Het vaststellen van de URI's voor dit Begrippenkader
2. Best practices voor URI's van begrippen, begrippenkaders. Momenteel heet de issue naar punt 2 en begint deze ook zo, maar eindigt deze met punt 1.

[ArjenSantema]

We hanteren de Nederlandse uri-strategie: http://{domain}/{type}/{concept}/{reference}

1. Domain: nlbegrip.nl/sbb (standaardbegripsbeschrijvingen is erg lang). Dit is ook de paginanaam van de reSpec.
2. Type: De begrippen in het profiel worden een web-resource, dus krijgen een uri van het type id,
3. Concept: De begrippen zijn een begrip/concept. We gebruiken de Engelse aanduiding om internationaal beter begrijpbaar te zijn. Voor een technische aanduiding is dit een pragmatische oplossing.
4. Reference: We gebruiken in de uri de ver-uppercamelcasede Engelse naam. UpperCamelCase is hiervoor inmiddels een in Nederland breed toegepaste conventie.

Dit vereist dat de begrippen worden ogenomen in een Linked data omgeving als Skosmos (BegrippenXL). In de begrippenlijst in de reSpec wordt naast de definitie, bron, toelichting, en alternatieve term ook deze uri opgenomen.