kunnen skos:concepts gebruikt worden in relatie tot rdf:properties
Closed this issue · 14 comments
Nu in 2660: alleen skos-Concepts voor groepe, concrete concepten en Type instanties (zoals enum type items) (eigenschappen/gewone-individuals kunnen wel skos eigenschappen hebben maar zijn niet getypeerd als skos:Concept):
| Metaverzameling/ ‑concept/ ‑relatie | SKOS-taalconstructie |
|---|
- Gegevensmodel | skos:ConceptScheme
- Gegevensverzameling | n.v.t
- Groep | skos:Collection
- Concept | alleen voor subtypen van concrete concepten: skos:Concept
- Individu | alleen voor individuen van het abstracte ‘Type’ concept: skos:Concept
- Waardetype | n.v.t.
- Waarde | n.v.t.
- Attribuut |
- Annotatie | bestaande RDFS/SKOS annotaties volgens 8.5
- Kwaliteit | n.v.t.
- Kwantiteit | n.v.t.
- Relation |
- Groepering | skos:inScheme, skos:member (geen gebruik van extra kenmerken ‘typeIndividuen’ en ‘aantalIndividuen’)
- Classificatie/Instantiatie | n.v.t.
- Generalisatie/Specialisatie | skos:broader
- Associatie | n.v.t.
- Beperking | n.v.t.
- Afleiding | n.v.t.
Dit kan algemener bv: ook voor properties, en zelfs voor instanties).
Bv, in: https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html
staat:
"As a point of interest, this pattern is compatible with viewing the transformation process as a "model-driven" transformation from OWL to SKOS, where each class, property and individual in the OWL ontology is mapped to a new SKOS conceptual resource etc."
Denk bij individual ook aan bv de enumeratieitems voor enumeratietypen (als referentieindividuals).
De vraag is hoe ver ga je er in.....
Voordeel nu: heerlijk simpel.
Voordeel als ook properties als skos concepten: rdfs/owl/shacl wordt weer wat cleaner (skos eigenschappen aan skos concept via isDefinedBy in skos scheme).
Nadeel dan weer: ga je ze ook nog onderling relateren (met bv skos:related) en zo ja, hoe dan? (op basis van restricties? En dan tussen property en concept of tussen concepten onderling? Etc.) zie ppt link hieronder een voorbeeld.
Hans jij noemde SKOS>RDFS generatie (de andere kant op), dus wellicht heb jij hier ook voorkeuren.
Graag hoor ik jullie ideeën. Het is nu nog mogelijk om de skos binding van 2660 uit te breiden voor attributen/relaties of zelfs individuals.
Thx Michel
Nog toelichting opties vanuit nta8035.
skos-binding.pptx
Graag hoor ik jullie ideeën. Het is nu nog mogelijk om de skos binding van 2660 uit te breiden voor attributen/relaties of zelfs individuals.
Ik zie geen waarde om dat te doen. Ik zou SKOS gebruiken voor het stellen van het begrippenkader. Relaties vind ik daar al weinig nut hebben. In de Dikke van Dale vind ik ook geen relaties tussen begrippen.
Nog toelichting opties vanuit nta8035.
skos-binding.pptx
Optie 1: Leuk, maar ga ik waarschijnlijk niet gebruiken.
Optie 2: mijn voorkeur
Optie 3: nehhhhh
wie is Rix012? Rik? :)
in de dikke van dalen staan denk ik wel relaties/werkwoorden......(advocaat vd duivel want ik ben het met je eens denk ik)
optie 2 is iets uitgebreider dan wat we nu doen. Issue wanneer is er een skos:related? alleen als er een property is, en een domain en een range? Vaak properties zonder domain of range, die niet? hmmmmmm
subissue: op dit moment wel skos:Concept voor type instanties dus bv enum item instantie. nen2660 vb: Client (als enum item voor requirementsource. reqsource zelf is echter geen skos:cocnept want geen concreetconcept (maar een metaclass under abstractconcept). dus ook geen broader hiernaar toe.
wie is Rix012? Rik? :)
Misschien... :P
in de dikke van dalen staan denk ik wel relaties/werkwoorden......(advocaat vd duivel want ik ben het met je eens denk ik)
Ik bedoel dat er tussen de termen geen 'relaties' aangeduid staat behalve 'zie ook' oid. Maar volgens mij zijn we het eens ja.
optie 2 is iets uitgebreider dan wat we nu doen. Issue wanneer is er een skos:related? alleen als er een property is, en een domain en een range? Vaak properties zonder domain of range, die niet? hmmmmmm
Optie 2 is voor CB-NL inderdaad uitgebreider. Mijn reactie was eigenlijk dat uberhaupt optie 2 het beste is. Maar voor CB-NL hebben we mijns inziens optie twee niet eens nodig inderdaad.
subissue: op dit moment wel skos:Concept voor type instanties dus bv enum item instantie. nen2660 vb: Client (als enum item voor requirementsource. reqsource zelf is echter geen skos:cocnept want geen concreetconcept (maar een metaclass under abstractconcept). dus ook geen broader hiernaar toe.
Voor de CB-NL vind ik dit dus geen issue. Dat soort relaties hoeven we niet te hebben in de vocabulair.
skos-binding.pptx
update met voorstel:
- skos termen voor classes en rdf:properties (dus attributen en relaties)
- ook termen voor Type instanties zoals EnumerationType instanties
- geen skos:related (alleen relevant als zowel domein als relevant gegeven zijn)
Kommentaar welkom.
ls ok dan pas ik de skos taalbinding licht aan.
(en breid ik de skos termen uit voor nen2660 zelf in bijlage C).
skos-binding.pptx
Voor CB-NL: Ik denk dat het inderdaad een goede optie is om SKOS termen te gebruiken voor:
- classes
- rdf:properties
- type instanties
En inderdaad geen skos:related. Dat is dan dus optie 6 volgens mij.
Voor de NEN2660-2 denk ik dat je een zelfde voorstel kan doen, maar uiteraard kun je het gebruiken van skos:related niet verbieden.