IMBOR 2020-07 release gebruiken om basis versiebeheer IMBOR-LD te implementeren

[RiX012]

Impact/revisit van:
#2 #49 #82
We hebben het uitgebreid gehad over versiebeheer in het algemeen en CROW heeft het op zich genomen om hier hun expertise op te showen. Alleen binnen IMBOR-LD doen we het nu nog niet. In eerdere beslissingen is gesteld dat bij een nieuwe release van IMBOR en IMBOR-LD we versiebeheer gaan implementeren. Voor release 2020-08 is nu gekozen om basis versiebeheer te implementeren.
Daarnaast lopen we met bijvoorbeeld Amsterdam tegen zaken aan dat ze onze ontologie al gebruiken. Als wij zaken gaan veranderen moeten we ook goed versiebeheer doen anders wil niemand met onze ontologieën werken. We kunnen dan onze kennis van versiebeheer echt goed etaleren, en überhaupt goed bezig zijn
Dit betekent het volgende:

In de TriG file werd al een versie meegeven. Dit blijft zo. Deze benaming zal in lijn zijn met de IMBOR benaming (2020-08). Doordat in IMBOR-LD vaste URI's worden gebruikt (geen versie in de URL) zal alles te te vinden blijven. E.g. het beheerobject zal blijven op: http://linkeddata.crow.nl/publication-v2/ns/crow/imbor/def/objecttype/OBB400

De meeste wensen mbt versie management bij IMBOR-LD gaan over versie materialisatie. Wanneer we de analyse van CROW bekijken is de handigste strategie een IC (Indepent Copies) strategie Combinaties versiebeheer strategie. Eigenlijk wordt dit ook onderschreven door IMBOR: er komen een minimaal aatal publicaties per jaar en deze moeten allemaal ook nog eens altijd te raadplegen zijn.
Qua implementatie in techniek kom je dan dus op het delen van periodieke dumps. Dit is wat gedaan zou kunnen worden door in de publicatie URL een versie op te nemen. Dit is in ons geval minder handig dan het expliciet in de data opnemen. Kort gezegd publiceer je puur de info over de versie apart, met een rdfs:container en de members hier in met rdfs:member. Overigens weten we nog niet zeker welk 'groeping' mechanisme we gaan gebruiken. Wordt nog onderzocht.

Voordelen:

• Eenvoudig
• Te combineren met 'document' releases van TriG file en Access Database
• Met SPARQL op één endpoint te querien (door filter)
• Gehele versies te achterhalen
• Delta door te querien
• Resources blijven op zelfde plek
• Werkt op het LDP van CROW

Nadelen:

• Alleen Subjecten en Objecten worden meegenomen (geen predicaten). Dit betreffen in IMBOR-LD dus nu Objecttypen, Groepen, Eigenschappen, Waarden en de koppeling (shape) tussen Objecten en Eigenschappen. E.g. Als het concept Boom uit de groep Groen wordt gehaald, maar de groep Groen en het concept Boom gewoon blijven staan... is dit niet expliciet te achterhalen. Alleen doormiddel van logboeken of eventuele compare query's.
  Ondanks dat dit niet perfect is verwachten we dat het de meeste use-cases dekt.
• Omvangrijkere TriG file
• In query's moet versie info meegegeven worden
• Makkelijk om het in de query te vergeten (daarmee kans op niet juiste resultaten)

EDIT: 2020-08: In de uitweiding van deze issue worden de opties besproken en waarom voor 'optie 3' gekozen is.

[ElisabethKloren]

Softwareleveranciers vragen in het overleg 26-06-2020, of er delta query's tussen de vorige en deze versie gepubliceerd worden.

[NielsHoffmann]

De uitleg hierboven is wat mij betreft nog niet duidelijk genoeg.
Het uitgangspunt is helder: 'een imbor-ld versie per imbor (access database) release'.
Maar de uitwerking nog niet (ik snap dat er ook nog het een en ander uitgezocht wordt...) Maar bv. de laatste trig file die ik van @RiX012 gekregen heb bevat geen versie informatie in de graph uri's (terwijl ik dat eerder volgens mij wel gezien heb) alleen een versie statement in de ontologie definitie.

Dus ik hoop dat de uitwerking nog iets verder toegelicht kan worden...

[RiX012]

Dus ik hoop dat de uitwerking nog iets verder toegelicht kan worden...

Uiteraard! Bij deze.

@redmer en ondergetekende hebben drie opties verkend.

1. dcat:Datasets, i.c.m. met Graphs
2. rdf:bag (rdfs:container)
3. skos:collection
   Om het overzichtelijk te maken is van iedere optie een voorbeeld file bijgevoegd.

Optie 1:

We maken een TriG file met daarin verschillende graphs. Al deze graphs zijn ook dcat:Dataset. We introduceren één dcat:Catalog, met de dcat:dataset property, welke als waarde dcat:Dataset heeft. Vervolgens introduceren we één dcat:Distribution, hierop zetten we de daadwerkelijke versie info. Elke graphs (en dus dcat:Dataset) heeft de property dcat:distribution die als waarde de enige (versioned) dcat:Distribution class.
Dit is een zuivere manier en bij elke nieuwe versie hoeven we alleen maar de dcat:Distribution aan te passen. Hierin staan immers alle verwijzingen. Bij een nieuwe versie zorgen de dcat:Dataset ervoor dat de juiste Subjecten en Objecten in de juiste versie staan.

In een query kan het dan bijvoorbeeld zo worden opgevraagd:

PREFIX versie:   <http://linkeddata.crow.nl/publication-v2/ns/crow/imbor/version/>
SELECT * WHERE {
GRAPH ?g 
{  ?s ?p ?o . }  
?g dcat:distribution versie:*** .
}

Voorbeeld bestand (gestript van content):
EXAMPLE imbor-ld - 2020-07 - Versiebeheer Optie 1 TriG File.txt

Optie 2:

We maken een TTL file zonder graphs en introduceren één klasse van het type rdf:bag. Hierin worden door middel van blanknodes alle Subject en Objecten geplaatst. Bij een nieuwe versie wordt er een nieuwe rdf:bag geïntroduceerd.

In een query kan het dan bijvoorbeeld zo worden opgevraagd (gebruikmakend van de inference/ruleset van rdfs):

PREFIX versie:   <http://linkeddata.crow.nl/publication-v2/ns/crow/imbor/version/>
SELECT * WHERE {
 ?s ?p ?o . 
FILTER ( versie:*** rdfs:member ?s || versie:*** rdfs:member ?o )
}

Voorbeeld bestand (gestript van content):
EXAMPLE imbor-ld - 2020-07 - Versiebeheer Optie 2 TTL File.txt

Optie 3:

We maken een TTL file zonder graphs en introduceren één klasse van het type skos:collection met daarin alle Subjecten Objecten. Daarnaast één dcat:Distribution class, hierop zetten we de daadwerkelijke versie info. De skos:collection is gewoon een groep met alle Subjecten en Objecten in één versie. Welke versie dat is wordt vermeld met een rdfs:isDefinedBy die als waarde de dcat:Distribution class heeft.

In een query kan het dan bijvoorbeeld zo worden opgevraagd:

PREFIX groep:   <http://linkeddata.crow.nl/publication-v2/ns/crow/imbor/def/groepering/>
SELECT * WHERE {
 ?s ?p ?o . 
FILTER ( groep:Versie2020-7 skos:member ?s || groep:Versie2020-7 skos:member ?o )
}

Voorbeeld bestand (gestript van content):
EXAMPLE imbor-ld - 2020-07 - Versiebeheer Optie 3 TTL File.txt

Conclusie
In alle opties publiceren we zowel de file als een endpoint. En in allebei de opties zijn alleen Subjecten en Objecten 'versioned'.

• Optie 1 is clean en het meest standaard. Deze bevat de juiste informatie en is eenvoudig te querien. Daarnaast is het ook simpel te onderhouden. Echter, het huidige CROW LDP ondersteund geen GRAPHS. Deze optie valt hiermee dus af.
• Optie 2 is simpel en doeltreffend. Verdient verder niet de schoonheidsprijs en is lastig te verwerken in transformatie scripts. Eigenlijk is het niet goed te doen om van een bulk transformatie een lijst met blanknodes te maken. Daarnaast kunnen niet alle SPARQL engines goed/op dezelfde manier omgaan met inference/rulesets. Hiermee valt deze optie ook af.
• Optie 3 blijft over. Deze is simpel, doeltreffend maar heel banaal. Dit is zeker ook geen mooie manier van versiebeheer. Maar it-does-the-job voor de huidige use-cases. Daarnaast is iedereen bekent met SKOS, dus moet het makkelijk te behandelen zijn.

Voorlopig willen we dus verder met optie 3, een skos:Collection.
@NielsHoffmann @MichelBohms graag jullie input/visie.

[NielsHoffmann]

dank voor de uitleg. Ik denk inderdaad dat optie 3 het beste is. Niet alleen omdat het CROW-LDP optie 1 niet ondersteunt, maar ook omdat een turtle file (in tegenstelling tot een trig) makkelijker te verwerken is voor de meeste partijen omdat trigs niet per se goed ondersteund worden...

[MichelBohms]

Mee eens. Voor velen is trig exotisch. Maar idd denk nog niet de ideale oplossing dus wellicht in toekomst nog schakelen bij consensus in bv coins 3.0 BP groep. Vg Michel Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel.bohms@tno.nl<mailto:michel.bohms@tno.nl> Location<https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707> [cid:image001.gif@01D65138.52DDE2E0]<http://www.tno.nl/> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. Van: Niels Hoffmann <notifications@github.com> Verzonden: Friday, July 3, 2020 12:01 PM Aan: Stichting-CROW/imbor <imbor@noreply.github.com> CC: Bohms, H.M. (Michel) <michel.bohms@tno.nl>; Mention <mention@noreply.github.com> Onderwerp: Re: [Stichting-CROW/imbor] IMBOR 2020-07 release gebruiken om basis versiebeheer IMBOR-LD te implementeren (#88) dank voor de uitleg. Ik denk inderdaad dat optie 3 het beste is. Niet alleen omdat het CROW-LDP optie 1 niet ondersteunt, maar ook omdat een turtle file (in tegenstelling tot een trig) makkelijker te verwerken is voor de meeste partijen omdat trigs niet per se goed ondersteund worden... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#88 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFJJOMHYA4YNDFBIGJGM4LTRZWT6RANCNFSM4OGSBBFA>.

[RiX012]

In de nieuwste TTL file is nu via een skos:collection de versie op te vragen. Voor inhoudelijke wijzigingen wordt nog verwezen naar het logboek. In een volgende versie zal de zelfde manier van versie management gebruikt worden, waardoor makkelijke een (basis) delta opgevraagd kan worden. Voor deze versie is dat nog niet gedaan omdat 2020-08 pas een release candidate van IMBOR-LD is. 2020-03 was een bèta.
Alle SPARQL queries zijn ook aangepast om de laatste (juiste) versie te bevragen. Dit geldt voor zowel degene in de Web applicatie van CROW, als degene in de voorbeelden binnen het juypyter notebook. Het wordt aanbevolen deze te raadplegen wanneer men wil gaan queryien.