search

Stichting-CROW / imbor

Een informatiemodel en objecttypenbibliotheek (né ontologie) voor assetbeheer van de openbare ruimte
https://www.crow.nl/imbor
10 stars 2 forks source link

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

Closed RiX012 closed 3 years ago

RiX012 commented 4 years ago

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:

Nadelen:

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

ElisabethKloren commented 4 years ago

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

NielsHoffmann commented 4 years ago

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 commented 4 years ago

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'.

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

MichelBohms commented 4 years ago

Mis ik hier wat context? Lijkt stukje mail/inleiding te missen…

Of simpelweg: 3 opties voor versiemngt?

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist

T +31888663107 M +31630381220 E michel.bohms@tno.nlmailto:michel.bohms@tno.nl

Locationhttps://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@01D6512A.C50F0320]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: RiX012 notifications@github.com Verzonden: Friday, July 3, 2020 10:54 AM 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)

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

Uiteraard! Bij deze.

@redmerhttps://github.com/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.txthttps://github.com/Stichting-CROW/imbor/files/4868520/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.txthttps://github.com/Stichting-CROW/imbor/files/4868523/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-7skos:member ?s || groep:Versie2020-7 skos:member ?o )

}

Voorbeeld bestand (gestript van content): EXAMPLE imbor-ld - 2020-07 - Versiebeheer Optie 3 TTL File.txthttps://github.com/Stichting-CROW/imbor/files/4868524/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'.

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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Stichting-CROW/imbor/issues/88#issuecomment-653434235, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFJJOME4H3KT3NXR7SBYHMLRZWMDLANCNFSM4OGSBBFA.

NielsHoffmann commented 4 years ago

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 commented 4 years ago

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.nlmailto:michel.bohms@tno.nl

Locationhttps://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 GitHubhttps://github.com/Stichting-CROW/imbor/issues/88#issuecomment-653463490, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFJJOMHYA4YNDFBIGJGM4LTRZWT6RANCNFSM4OGSBBFA.

RiX012 commented 3 years ago

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.