W3C home > Mailing lists > Public > public-swd-wg@w3.org > March 2008

RE: ISSUE 37+56

From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
Date: Tue, 11 Mar 2008 17:23:40 +0100
To: Guus Schreiber <schreiber@cs.vu.nl>, SWD WG <public-swd-wg@w3.org>
Message-id: <BA453B6B6B217B4D95AF12DBA0BFB669029DB01C@hqgiex01.fao.org>

Hi there,

If this can help, I can see the following top-level concept-to-concept
relationships that may be implemented in skos, in addition to the one already

- relatedCausative (all the ones like causes/isCausedBy,
benefitFrom/isBeneficialFor, affects/isAffectedBy, etc...)

- relatedTermporal (all the ones like follows/precedes,

- relatedEssive (all the ones like isUsedAs/isUseOf, isDerivedFrom/isSourceOf
, etc.)

- relatedInstrumental (all the ones like growsln/isAGrowthEnvironmentFor,
isMeansFor /isPerformedByMeansOf, etc.)

but, I can see that we would like to limit to "a limited number of predefined
specializations"... So maybe the aboves are just to keep in mind and will
just be implemented in SKOS with the simple "related"...?


-----Original Message-----
From: public-swd-wg-request@w3.org [mailto:public-swd-wg-request@w3.org] On
Behalf Of Guus Schreiber
Sent: 11 March 2008 15:59
Subject: ISSUE 37+56


Here are some thoughts about the specialization/extension issues. 


ISSUE 37 Skos Specialization http://www.w3.org/2006/07/SWD/track/issues/37
ISSUE 56 ReferenceSemanticRelationshipSpecializations

Here are some initial thoughts before proposing a resolution for these two
issues. I suggest we propose no drastic changes, basically saying:

1. There are a limited number of predefined specializations in the SKOS
   vocabulary, that are in common use in the thesaurus world
2. Vocabulary owners can define their own specializations by defining
   subproperties of SKOS concepts, semantic relations and label
   relations. The SKOS Reference and Primer contain examples as guidelines

Ad 1.

The current SKOS extension module predefines 8 specializations: namely 
- broader/narrower-Generic/Instantive/Partitive
- related-hasPart/PartOf

The problem I see is that these specializations define two different ways of
specifying part-whole relations. This may be very confusing. I suggest to
keep only the intuitive one, namely "broader/narrower Partitive". I assume
the "related" part-whole relations are typically used to link, for example,
concepts in a hierarchy of products with concepts in a hierarchy of
ingredients or materials. However, I suggest this should not be a
*predefined* specialization.

Wrt the semantics of the specializations: 

* broaderGeneric

  The strictest semantics would be to include the following axiom in
  the SKOS scheme:  

    skos:broaderGeneric rdfs:subPropertyOf rdfs:subClassOf .

  This also mean that subject and object of skos:broaderGeneric are
  considered RDF/OWL classes (domain and range of rdfs:subClassOf is
  rdfs:Class). This is fine in RDF/OWL Full but not in OWL DL.
  Alternatively, we could also just state that it would be reasonable
  for application developers to expect this interpretation to be a
  correct one.

* broaderInstantive

  The strictest semantics would be to include the following axiom in
  the SKOS scheme:  

    skos:broaderInstantive rdf:subPropertyOf rdf:type .

  Same discussion as above (in this case only the subject is a
  RDF/OWL class). 

Typical examples: 

 ex:Asia skos:broaderInstantive ex:Continent .
 ex:Rembrandt skos:broaderInstantive ex:Artist

Ad 2.

a. Subproperties of skos:related:

typical examples: artist thesaurus
  ex:teacherOf rdfs:subPropertyOf skos:related .
  (not symmetric)

  ex:workedWith rdfs:subPropertyOf skos:related .
  ex:workedWith rdf:type owl:Transitive Property .
  (symmetry does not inherit, so needs to be specified explicitly)

b. Subproperties of broader/barrower

- Use as much as possible the predefined specializations

@@ to be extended

VU University Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
T: +31 20 598 7739/7718; F: +31 84 712 1446 
Home page: http://www.cs.vu.nl/~guus/
Received on Tuesday, 11 March 2008 16:23:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:50 UTC