URI-strategie - werksessie 2015-05-15

Beste werkgroep-leden en geïnteresseerden,
De feestdagen in het voorjaar worden makkelijker over het hoofd gezien dan die in december. Maar ook de komende weken is de agenda een grote gatenkaas. Een mooi gaatje valt er op vrijdag 15 mei, de vrijdag na hemelvaart. Ik zou die dag dan ook graag benutten voor een conceptual friday over de URI-strategie. Verschillende van jullie hebben al aangegeven die dag te kunnen. Voor wie 15 mei niet kan: we zullen zorgen voor een verslag en een vervolgmeeting die ik met Datumplanner zal maken, zodat ik met meer agenda's rekening houd. Niet gehinderd door dringende zaken op het werk kunnen we de 15e lekker een dagje diep gaan. Linda houdt die dag Geonovum open, dus we kunnen daar gewoon terecht.
Op de agenda staan in ieder geval onderstaande onderwerpen en ik wil met jullie delen wat mij overkwam toen ik de URI-strategie wilde toepassen op de waardelijsten van OWMS. Verder hoor ik graag van jullie wat je belangrijk vindt.
Graag tot vrijdag 15 mei om 10:00 uur bij Geonovum. Laat even weten of je komt. Tot nu toe heb ik:
* Linda van den Brink (is bij Geonovum, ik weet niet of ze ook de (hele) sessie wil bijwonen)
* Lieke Verhelst
* Jeroen Hamers
* Marco Brattinga
Arjen Santema is verhinderd.
Groet,
Hans
----
Van: <Brattinga>, Marco Brattinga <Marco.Brattinga@ordina.nl>
Datum: dinsdag 7 april 2015 08:56
Aan: Lieke Verhelst <lieke@linkeddatafactory.nl>, Hans Overbeek <Hans.Overbeek@koop.overheid.nl>, Linda van den Brink <l.vandenbrink@geonovum.nl>, Marcia van Oploo <M.vanOploo@kennisnet.nl>, Frank Kooij <Frank.Kooij@kadaster.nl>, "Arjen.Santema@kadaster.nl" <Arjen.Santema@kadaster.nl>, "wnotenbomer@sbrcurnet.nl" <wnotenbomer@sbrcurnet.nl>, Martijn Odijk <Martijn.Odijk@minienm.nl>
Onderwerp: RE: Update voor 2 april sessie'''
Lieke,
 
Een vraagje: ik begrijp niet helemaal waarom je voor de instanties per class een graph nodig hebt. Waarom is het netjes om deze in een afzonderlijke graph te zetten? In de BAG demonstratie waar we gebruik hebben gemaakt van de URI strategie, hebben we juist graphs per gebeurtenis onderkend, en niet per class. Dus de nummeraanduidingen en openbare ruimten die gezamenlijk wijzigden (bijvoorbeeld na het aanleggen van een hele nieuwe straat) zijn ook in dezelfde graph beland, en niet een graph per nummeraanduiding c.q. openbare ruimte.
 
Nog wel een opmerking: hoewel de term “concept” is gekozen in de URI-strategie, wordt hiermee niet hetzelfde beoogd als een class in een owl:Class. Het kan best zijn dat het concept en de class verschillen. De reden om “concept” toe te voegen is meervoudig, maar als belangrijkste zou ik zelf zeggen dat het is om de URI uniek te maken, in de “klassieke” situatie dat referenties niet altijd uniek zijn (bijvoorbeeld: hoe onderscheid je de 9 cijferige BSN van een ander 9 cijferige identificatie). Op het moment dat de identificatie zelf uniek is, zou bijvoorbeeld een aanduiding “ding” ook voldoende kunnen zijn. Overigens is het ontwikkelen van best-practices voor het kiezen van het “concept” nog wel iets dat we wat mij betreft mogen uitwerken in het URI-strategie-project.
 
Tenslotte: ik kan me voorstellen dat het scheiden van domeinen zinvol kan zijn. Het is overigens niet noodzakelijk: het onderscheid tussen de vocabulaire en de data is ook al zichtbaar in het “type” deel van de URI-strategie: “def” of “id”.
 
Marco
----
Van: Lieke Verhelst 
Verzonden: zondag 29 maart 2015 13:15
Aan: 'Hans Overbeek'; 'Linda van den Brink'; M.vanOploo@kennisnet.nl; Frank.Kooij@kadaster.nl; Brattinga, Marco; Arjen.Santema@kadaster.nl; wnotenbomer@sbrcurnet.nl; Martijn.Odijk@minienm.nl
Onderwerp: RE: Update voor 2 april sessie 
Hoi Hans,
Ik had je ook nog beloofd om mijn ervaringen over de huidige URI strategie te delen. Bij deze (zie hieronder).
Verder nog een vraag. Wat is nu precies de scope van deze werkgroep? Hoort versiebeheer hier ook bij (named graphs met versie-identifier in URI)? En mapping (vanwege de discussie relaties tussen skos:Concept en owl:Class)? Misschien moeten we onderwerpen benoemen en afbakenen.
Tot donderdag!
Grt, Lieke
----
Mijn ervaringen met de huidige URI strategie betreft voornamelijk twee issues: graph management en betekenisvol/betekenisloos.
betekenisvol/betekenisloos
Soms speelt toch de discussie of de OWL class namen in de URIs niet beter betekenisloos zouden kunnen zijn.Kunnen we voors en tegens opnoemen en een richtlijn geven voor gebruik van het ene of het ander en wanneer?As donderdag vertel ik hier ook wat over.
Graph management
Misschien maak ik een interpretatiefout bij wat er precies wordt bedoeld. Ik lees de strategie als volgt. De huidige URI strategie zegt dat het voorgeschreven patroon is:http://{domain}/{type}/{concept}/{reference}
 
Het nadeel van het opnemen van het onderdeelconcept in de URI is dat als je dat netjes doet, je eigenlijk per concept een aparte graph zou moeten hebben voor de instanties. Bijvoorbeeld: je hebt een klein Linked Data bestand, maar er staan toevallig veel classes in, en per class weinig instanties. Dan zou je per class een aparte graph moeten maken waar je de instanties in opslaat bv:
classes: http://example.com/def#C1 , http://example.com/def#C2 , http://example.com/def#C3 enz (of moet hier eigenlijk nog concept tussen zodat het zo wordt: http://example.com/def/dingen#C1 ?)
De URIS van de instanties worden dan als ik het goed begrijp: http://example.com/id/C1/abc , http://example.com/id/C1/xyz , http://example.com/id/C2/ghjk etc
Je ziet waar dit heengaat als je het netjes wilt doen: alle instanties van C1 horen in een aparte graph , alle C2tjes enz. Dat geeft behoorlijk wat belasting op het graph beheer.
Moeten we eigenlijk nog iets meer zeggen over het domein deel van de ontologie en van de instanties? Je zou kunnen denken aan gescheiden opslag van model en data. Ik zie dat bij de stelselcatalogus voor model en data allebei gekozen is voor het domein: http://data.stelselvanbasisregistraties.nl . Bij scheiden van model en data zou je kunnen denken aan: http://voc.domein.nl als domein voor het model en http://data.domein.nl als domein voor de instanties. Voor kleine domeinen zoals stelselvanbasisregistraties.nl is dit niet zo belangrijk, maar als je gaat richting de grotere domeinen waar je verwacht dat er meerdere vocabulaires zullen worden geserveerd is het wel netjes en qua beheer gewenstdenk ik om die in een apart subdomein te zetten en data en model te scheiden
 
We zouden kunnen toewerken naar een URI strategie die voorschrijft maar afwijkingen toestaat. Die afwijkende scenario's zouden we deels kunnen beschrijven als voorbeeld. Die voorbeelden zijn nooit uitputtend uiteraard..