IMBOR 2020-07 release gebruiken om defintieve release NTA8035 te commiteren

[RiX012]

Impact/revisit van:

4 #17 #18 #19 #20 #21 #23 #33 #44

Commiteren aan de laatste versie van de NTA is nodig omdat we de NTA willen volgen. We hebben tijdens de eerste fase steeds gewerkt met een dynamische NTA. En ergens in de tijd hebben we gezegd dat we ons niet meer gingen vormen naar verdere wijzigingen aan de NTA. Nu is de NTA echter vastgesteld en heeft IMBOR-LD dus last van de wet van de remmende voorsprong. We wijken nu op een aantal (essentiële punten af van de NTA). Zeker met de voortrekker/voorloper functie die we hebben lijkt het ons nodig om de afwijkingen goed in kaart te brengen en ons (net zoals we dat van anderen willen) volledig te commiteren aan de geldende NTA. En als we met andere LD sets willen gaan linken (Amsterdam OTL en GWSW bijvoorbeeld) die zich nu ook op de geldende NTA baseren, wordt dat uiteraard veel makkelijker! Dit is de conclusie wat we wel en niet gaan aanpassen:

• URI-strategie De NTA adviseert human-readable identifiers. Bij IMBOR-LD doen we dat niet. Na overleg met @MichelBohms is duidelijk dat het een advies is (met name in situatie waarin ontologieen opgestart worden), maar niet hoeft. In de internationale versie van de NTA (SMLS) wordt het ook niet afgedwongen. Vanwege de hoeveelheid data en de vele dubbelingen in terminologie besluiten we voor IMBOR-LD dat we betekenisloze codes aanhouden.

• skos:collection vs. rdfs:container Vanuit OTL-Amsterdam werd aangegeven dat IMBOR-LD skos:Collection gebruikt ipv rdf:container. Er was onduidelijkheid of dit goed was of niet. Na een goede discussie met de volgende argumenten:

  1. @MichielBohms: Als je sterke grouping wilt en al op rdfs level of hoger zit dan is meest logisch rdfs grouping Als je op rdfs of hoger zit en je doet OOK skos-level (dus niet alleen skos-annotatie hergebruik maar echt skos-concepts) dan heb je dus keuze uit zwakke (term grouping) of sterke rdfs groeping. Hier is die keuze dus zwak omdat het iets is uit verleden waar je niet echt mee door wilt…..(?)
  2. @NielsHoffmann: Mijn redenering zou zijn dat de groeperingen en thematische verdelingen in imbor-ld vooral bedoelt zijn om de gebruiker te helpen orde in het model te ontdekken. (oftewel, welke klassen zijn er allemaal in een bepaald thema) De groeperingen zijn er niet in meer ‘technische’ zin om te definiëren welke attribuut groepen bij een class horen (dat is volgens mij iets wat met shacl gedaan wordt?). Vanuit dat oogpunt vind ik dat de beschrijving van objecttypegroepen en thema’s ergens aansluit op het niveau wat je typisch met skos beschrijft, en dat daarmee de keuze voor skos:collections in imbor prima te verdedigen is… Ik heb er in een eerdere fase al eens voor gepleit om de NTA als ‘concept’ te beschouwen en nog niet meteen als 1.0 ‘definitief’ te beschouwen. Dit is voor mij zo’n voorbeeld waar we nog niet per se consensus over hebben…Laten we er alsjeblieft voor waken dat we nu patronen gaan implementeren ‘omdat de NTA het zegt’, terwijl er misschien een beter patroon is voor het beoogde doel. Als je kijkt naar de modelleer patronen van kadaster/basisregistraties dan bouwen zij de modellen heel ‘gelaagd’ op. Om te beginnen met skos concepten (met definities en verwijzingen naar bron teksten e.d.) en vervolgens een ontologie met rdfs:classes die verwijzen naar de skos concepten voor hun definitie en daarbovenop shacl voor de restricties e.d. Op die manier ‘bouwen’ de LoC’s door op elkaar. Dat zou wat mij betreft het beste patroon zijn… Het zou wat dat betreft mooi zijn als we een soort ‘levend addendum’ aan de NTA kunnen toevoegen om dit soort discussies vast te leggen en naar een gemeenschappelijk beeld toe te groeien.

Zijn we tot de conclusie gekomen dat we voorlopig de skos:collection blijven hanteren omdat 1) het zijn inderdaad groeperingen en thematische indelingen om het model te ontdekken en 2) het gebruik van SKOS toch al gedaan wordt (voor labels) en we hiermee uit de voeten kunnen.

• Aanpassen van manier vastleggen Eigenschappen en Quantity values @redmer Vul jij dit aan als je de changes duidelijk hebt?

[MichelBohms]

Korte feedback:

• 1 en 2 bijt elkaar niet (nta laat oplossing toe)
• het is niet rdf:Container maar rdfs:Container
• sh:PropertyGroup is meer voor applicatie/gui doeleinden (forms, order, …) maar goed, je kunt er ook een bepaalde shape mee aan deze groep hangen dus wellicht ook semantisch toepasbaar; ik zal dit eens polsen bij TQ

2.3.2.3 sh:group Property shapes may link to an SHACL instancehttps://www.w3.org/TR/shacl/#dfn-shacl-instance of the class sh:PropertyGroup using the property sh:group to indicate that the shape belongs to a group of related property shapes. Each group may have additional triples that serve application purposes, such as an rdfs:label for form building. Groups may also have an sh:order property to indicate the relative ordering of groups within the same form.

VG Michel

[RiX012]

• het is niet rdf:Container maar rdfs:Container

Thanks. En dit is aangepast.

[RiX012]

Overigens zouden we de owl:Data / Annotation / ObjectProperty weg kunnen laten uit de data. Dit scheelt met mappen naar andere ontologieen (je maakt het generieker). Nadeel: Protege enzo interpreteert het niet lekker. We zouden dan wel weer de OWL properties op kunnen nemen als SHACL construct.

[RiX012]

Overigens zouden we de owl:Data / Annotation / ObjectProperty weg kunnen laten uit de data. Dit scheelt met mappen naar andere ontologieen (je maakt het generieker). Nadeel: Protege enzo interpreteert het niet lekker. We zouden dan wel weer de OWL properties op kunnen nemen als SHACL construct.

Voor de nieuwe release 2020-07 laten we de OWL properties er uit en wordt alles rdf:property. We gaan op basis van feedback die daarna komt kijken of dit handig is.

[RiX012]

Alle issues welke aan gerefereerd wordt zijn besproken. De meeste zijn opgelost. Volgens ons voldoen we hiermee voldoende aan de NTA8035 (deze is nu vastgesteld). Dit is ook gevalideerd bij @MichelBohms.