kunnen skos:concepts gebruikt worden in relatie tot rdf:properties

[MichelBohms]

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
1. Gegevensmodel	skos:ConceptScheme
2. Gegevensverzameling	n.v.t
3. Groep	skos:Collection
4. Concept	alleen voor subtypen van concrete concepten: skos:Concept
5. Individu	alleen voor individuen van het abstracte ‘Type’ concept: skos:Concept
6. Waardetype	n.v.t.
7. Waarde	n.v.t.
8. Attribuut
- Annotatie	bestaande RDFS/SKOS annotaties volgens 8.5
- Kwaliteit	n.v.t.
- Kwantiteit	n.v.t.
9. 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.
10. Beperking	n.v.t.
11. 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

[MichelBohms]

Nog toelichting opties vanuit nta8035. skos-binding.pptx

[RiX012]

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.

[RiX012]

Nog toelichting opties vanuit nta8035. skos-binding.pptx

Optie 1: Leuk, maar ga ik waarschijnlijk niet gebruiken. Optie 2: mijn voorkeur Optie 3: nehhhhh

[MichelBohms]

wie is Rix012? Rik? :)

[MichelBohms]

in de dikke van dalen staan denk ik wel relaties/werkwoorden......(advocaat vd duivel want ik ben het met je eens denk ik)

[MichelBohms]

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

[MichelBohms]

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.

[RiX012]

wie is Rix012? Rik? :)

Misschien... :P

[RiX012]

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.

[RiX012]

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.

[RiX012]

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.

[MichelBohms]

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

[RiX012]

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.