search

Stichting-CROW / Contracteisen

Aanleverspecificaties en datamodel voor contracteisen bij CROW
https://stichting-crow.github.io/Contracteisen/
Creative Commons Attribution 4.0 International
3 stars 0 forks source link

Contracteisen en OTL's verbinden #33

Open ElisabethKloren opened 3 years ago

ElisabethKloren commented 3 years ago

Ik realiseer me dat je waarschijnlijk nog geen concrete antwoorden hebt voor me voor de onderstaande vraagstukken, maar ik hoop dat jullie er al wel over aan het nadenken zijn…

Voor het projectje met het aanleveren van specificaties aan het PCB, waarbij opdrachtnemers de specificatie rechtstreeks uit het PCB zouden moeten kunnen gaan halen ben ik aan het nadenken hoe dat past in relatie tot de OTL… Als ik het cspec schema goed snap dan zijn de classes zowel skos:Concepts als owl:Classes. Volgens mij resulteert dit in owl:Full en daarvan kan ik de consequenties nog niet helemaal overzien.

Het patroon wat ik tot nu toe in onze OTL probeer te volgen is het patroon wat in nen3610-ld ook gevolgd wordt. Namelijk een begrippenkader gedefinieerd met skos (met eventueel verwijzingen naar de bron van de definitie van het begrip via dcterms:source e.d.) en dan een vocabulaire/ontologie met rdfs/owl classes die via dcterms:subject verwijzen naar het skos:Concept. Op die manier hou je de skos concepten en de rdfs/owl classes strict gescheiden.

Als ik nu dus een cspec:Specificatie heb en ik wil die via een cspec:specificeert relatie aan een Object ‘koppelen’ sta ik voor een dilemma. Relateer ik rechtstreeks naar mijn OTL, waarbij mijn OTL objecten dus opeens ook skos:concepts zijn (want de range van cspec:specificeert is een cspec:Object is een skos:Concept) en ik weet niet of ik dat wel wil…

In de eerste pilot met het aanleveren van onze esisenset wegen heb ik het zo opgelost dat ik cspec:Object via rdfs:seeAlso aan mijn OTL object heb gerelateerd. Zodat ik de ontologieën nog niet strak meng. Maar dan heb ik eigenlijk 2 duplicate ‘objectenbomen’ een volgens cspec en een volgens onze OTL design rules… ik ben geneigd om dat te blijven doen in de komende pilots, maar ik zou ook wel een soort van ‘roadmap’ willen hebben welke kant het in de toekomst uit gaat.

Hoe kijk jij hier tegenaan in relatie tot IMBOR-LD (waarvan ik aanneem dat we die idealiter als basis voor de cspec:Objecten zouden willen gebruiken waar toepasbaar) en de nen2660 waar natuurlijk ook een relatie fysiekObject – informatieObject in is gedefinieerd.

RiX012 commented 3 years ago

Voor het projectje met het aanleveren van specificaties aan het PCB, waarbij opdrachtnemers de specificatie rechtstreeks uit het PCB zouden moeten kunnen gaan halen ben ik aan het nadenken hoe dat past in relatie tot de OTL… Als ik het cspec schema goed snap dan zijn de classes zowel skos:Concepts als owl:Classes. Volgens mij resulteert dit in owl:Full en daarvan kan ik de consequenties nog niet helemaal overzien.

Dat klopt, daar ben ik ook niet gecharmeerd van en moeten we zeker heroverwegen bij het CSPEC/CDOC redesign.

RiX012 commented 3 years ago

Het patroon wat ik tot nu toe in onze OTL probeer te volgen is het patroon wat in nen3610-ld ook gevolgd wordt. Namelijk een begrippenkader gedefinieerd met skos (met eventueel verwijzingen naar de bron van de definitie van het begrip via dcterms:source e.d.) en dan een vocabulaire/ontologie met rdfs/owl classes die via dcterms:subject verwijzen naar het skos:Concept. Op die manier hou je de skos concepten en de rdfs/owl classes strict gescheiden.

Ah, ik had dat geadopteerd vanuit het MIM :), maar in essentie hetzelfde. Dit patroon passen we nu ook toe bij de nieuwe versie van IMBOR (en daarmee uiteindelijk IMBOR-LD). We zijn voornemens dit als CROW algemeen toe te passen.

RiX012 commented 3 years ago

Als ik nu dus een cspec:Specificatie heb en ik wil die via een cspec:specificeert relatie aan een Object ‘koppelen’ sta ik voor een dilemma. Relateer ik rechtstreeks naar mijn OTL, waarbij mijn OTL objecten dus opeens ook skos:concepts zijn (want de range van cspec:specificeert is een cspec:Object is een skos:Concept) en ik weet niet of ik dat wel wil…

Ja snap ik. Echter denk ik dat je onderscheidt moet maken tussen de echte vocabulair ontologie die je er op nahoudt, en het gebruik van SKOS. Want zodra je bijvoorbeeld skos:prefLabel gebruikt (wat men doet in de NEN2660) dan is het ding al een skos:Concept. Wij gebruiken SKOS en DC om onze vocabulair nu uit te drukken. Maar in bijvoorbeeld IMBOR-LD gebruiken we o.a. skos:prefLabel en skos:definition om meer zaken aan te geven. Hiermee wordt het dus ook in IMBOR-LD een skos:Concept (naast rdf:resource). Kortom, ik zou het wel of niet zijn van een skos:Concept geen onderscheidend argument laten zijn. Wel lijkt het me logisch dat we dit bij de redesign gaan vermijden.

RiX012 commented 3 years ago

In de eerste pilot met het aanleveren van onze esisenset wegen heb ik het zo opgelost dat ik cspec:Object via rdfs:seeAlso aan mijn OTL object heb gerelateerd. Zodat ik de ontologieën nog niet strak meng. Maar dan heb ik eigenlijk 2 duplicate ‘objectenbomen’ een volgens cspec en een volgens onze OTL design rules… ik ben geneigd om dat te blijven doen in de komende pilots, maar ik zou ook wel een soort van ‘roadmap’ willen hebben welke kant het in de toekomst uit gaat.

Die roadmap is er dus niet officieel, omdat er voor CSPEC/CDOC geen ontwikkeling(sbudget) gepland staat. Maar zoals je uit mijn vorige comment kan lezen zit ik in ieder geval op dezelfde lijn als jij.

RiX012 commented 3 years ago

Hoe kijk jij hier tegenaan in relatie tot IMBOR-LD (waarvan ik aanneem dat we die idealiter als basis voor de cspec:Objecten zouden willen gebruiken waar toepasbaar) en de nen2660 waar natuurlijk ook een relatie fysiekObject – informatieObject in is gedefinieerd.

Ik ga dus helemaal mee met jou patroon uit de NEN3610 (en/of MIM) en zeker ook de NEN2660. Ik heb gister van Michel de laatste versie opgevraagd waarin ook de Requirement is opgenomen. En heb op basis daarvan een eerste aanzet gemaakt voor een 'eisenmodelletje' voor binnen PCB en later CSPEC. Daar gaan we het nog in detail over hebben in het kader van de PCB pilot die je noemt.

NielsHoffmann commented 3 years ago

Ja snap ik. Echter denk ik dat je onderscheidt moet maken tussen de echte vocabulair ontologie die je er op nahoudt, en het gebruik van SKOS. Want zodra je bijvoorbeeld skos:prefLabel gebruikt (wat men doet in de NEN2660) dan is het ding al een skos:Concept.

is dat zo? Want een skos:prefLabel is een subproperty van rdfs:label en heeft geen domain gespecificeerd. en een rdfs:label heeft rdfs:resource als domain. Dus volgens mij kun je daar niet uit afleiden dat het subject van een skos:prefLabel automatisch een skos:Concept is.

RiX012 commented 3 years ago

is dat zo? Want een skos:prefLabel is een subproperty van rdfs:label en heeft geen domain gespecificeerd. en een rdfs:label heeft rdfs:resource als domain. Dus volgens mij kun je daar niet uit afleiden dat het subject van een skos:prefLabel automatisch een skos:Concept is.

Scherp, volgens mij ben ik in de war met de Collection/Member. Daar geldt het natuurlijk wel.