Verslag werkgroep URI-strategie 1-7-2015

Deze pagina geeft het verslag van de workshopbijeenkomst op de werkgroep bijeenkomst van 1 juni 2015 bij Surf in Utrecht met dank aan Linda van den Brink voor de aantekeningen.
Moderatie: Hans Overbeek
Sheets:
* Presentatie Hans, gebruikt tijdens de sessie
* Bestand:RCE URI-Strategie versie 0.2.pdf 
Korte herhaling van doel van de URI-strategie: 
Gericht op Registerhouder. Register is in de context van de URI-strategie een publicatie van een standaard of van referentiedata, zoals codelijsten of waardelijsten die door derden gebruikt worden.
Je stopt informatie in URI's, maar toch zijn ze betekenisloos - het is 'verboden' deze informatie te interpreteren. Best moeilijk te begrijpen.
URI strategie adviseert een patroon, maar dit is niet verplicht. Hoe heilig moeten we dit maken?
: http://{domein}/{pad}/{type}/{concept}/{referentie} ter discussie!
Een goede URI-strategie leidt tot bruikbare Q-names van de vorm;
: {prefix}:{reference}
prefix.cc geeft namespaces van bekende prefixes zoals skos, owl, rdf, etc.
John: QURI of Q-name? Qname = XML dus de local name mag dan niet met een cijfer beginnen. Bij een QURI wel. Dit in de URI strategie opnemen.
Wel of geen herkenbare {reference}? Vuistregel: Bij grote aantallen gebruik je snel nummertjes, in vocabulaires herkenbare namen. Maar er is een grijs gebied.
Huidige succesvolle URIs gebruiken meestal het patroon niet. Dus Hans stelt voor om dat patroon minder heilig maken.
URI strategie moet verzameling goede aanbevelingen zijn.
RCE is aan de slag gegaan met URI strategie voor hun eigen data zie link hierboven. RCE Gebruikt het URI strategie patroon met een vrije interpretatie van {concept}. Op deze plek zet RCE de thesaurus/ontologie. Dit resulteert in een strak en bruikbaar patroon.
Frans van der Zande RCE: alleen begrijp ik nu dat we een probleem hebben: We gebruiken UUID als reference, maar UUID kan met cijfer beginnen en in XML is dat een probleem. John: In ttl niet! Hans: Dit ook in URI strategie uitleggen!
Dimitri vindt het {type} onderscheid id/doc overbodig. Als je dit weg laat heb je REST patroon. Hans: Verwijst naar Linke Data theorie waarin wordt uitgelegd dat een URI van de documentatie over een resource nodig is naast de URI van die resource.
Dimitri: naast http zou je ook http moeten toestaan, want dit wordt steeds meer gebruikt en ook door Google en W3C als betrouwbaarder web-sites gezien. Hans: Dit is voor de URI-strategie geen enkel probleem, dus opnemen. Nog niet over voorkeur voor een van beiden gesproken.
Hans: Zijn er mensen die willen helpen met de URI strategie?
Onderwijsgroep wil hun overwegingen opsturen.
Matthijs: het klinkt al compleet, waar kun je aan meeschrijven?
Hans: Afzwakken van de nadruk op het patroon en verder zie werkplan URI-strategie: Doorontwikkeling met patronen voor referentie naar wet- en regelgeving.
Onderwerp voor de werkgroepsessie van vandaag:
URIs van derden. 
Argument 1 voor zelf uris munten: ik wil de gebruikers op mijn eigen site houden.
Marc v Opijnen: hebben we het over de URI of over de http URI? De URI van bv een wet is het BWB nummer.
Hans: In de context van het PLDN volgen we het spoor van het W3C die aanbeveelt: gebruik http-uri's om resources te identificeren.
Matthijs Vonder: als ik bij metalex ben kan ik dan nog zien waar die data vandaan komt? Hans: Ja, bijvoorbeeld als Metalex owl:sameAs relatie naar wetten.nl legt. Maar als metalex niet eigen uris had gemunt had je die sameAs niet hoeven opzoeken.
Argument 2 voor zelf URI's munten: Het is niet dezelfde resource. Want een ander formaat en ander aspect, namelijk niet de oorspronkelijke tekst van de regeling, maar de metadata over de regeling.
Dus wanneer spreek je van een andere resource? Dit kan zeer subtiel liggen en is vaak heel moeilijk te bepalen. In geval van Metalex en wetten.overheid.nl ziet de leek op het eerste gezicht dat de twee resources hetzelfde zijn: Ze gaan over dezelfde regeling.
In andere gevallen is het duidelijker, bijvoorbeeld als de een wijzigingen toestaat die voor de ander in een nieuwe resource resulteren. Voorbeeld: vandaag verandert gemeente "De Friese Meren" van naam. De nieuwe naam luidt "De Fryske Marren". De BRP kent in dat geval een nieuwe gemeentecode toe *), en ziet dus twee gemeenten, maar er zijn applicaties die vinden dat de gemeente dezelfde blijft en slechts een nieuw label krijgt. 
Juridisch wordt een gemeente geïdentificeerd door een gemeentecode die wordt toegekend door de Basisregistratie Personen (BRP). De BRP kent de gemeentecode toe op basis van gemeentenaam. Een naamswijziging betekent dus een nieuwe gemeentecode, ook al verandert er verder niets, en een gemeentelijke herindeling waarbij een aantal oude gemeenten samengevoegd worden tot een nieuwe gemeente die de naam krijgt van een van de oude gemeenten, resulteert niet in een een nieuwe gemeentecode.
Marcel: blijf je afvragen of het nog wel werkt. Als je wel eens misverstanden hebt over de identiteit van een ding, zijn het 2 resources. Zo niet, beschouw het dan als het zelfde ding, dit is dan goed genoeg.
Tot slot een niet afgeronde discussie over voor- en nadelen van betekenisvolle references. Enkele argumenten uit de ze discussie:
; UUID's
: +/+ zijn absoluut uniek;
: -/- zijn erg lang; 
: -/- moeilijk over te typen;
: -/- vrijwel niet te herkennen; 
: -/- ooit ontwikkeld en bedoeld voor interne identificatie, niet voor interoperabiliteit.
; Betekenisloze identifiers
: +/+ worden niet geïnterpreteerd door gebruiker/ontwikkelaar, dus geen discussie over of de "URI wel klopt" 
: -/- worden niet herkend, dus altijd look-up nodig;
: -/- als ze beginnen met een cijfer leiden ze niet tot valide Q-names in XML.
; Betekenisvolle identifiers
: +/+ worden herkend, dus zijn gemakkelijk in gebruik en veelal voorspelbaar of te onthouden 
: -/- doorgaans gebaseerd op het prefLabel, dus rijzen er twijfels als reference afwijkt van het preflabel (spelfout?) of het prefLabel wijzigt ("Ik wil onze oude naam niet meer in 'onze'(!) URI") 
: -/- doorgaans gebaseerd op het prefLabel, dus verleiding is groot om het prefLabel niet op te zoeken, maar uit de URI te 'knippen'. Dit ondanks de regel: De URI is betekenisloos!