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

Re: ISSUE 37+56

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 12 Mar 2008 16:48:12 +0100
Message-ID: <47D7FB3C.80907@few.vu.nl>
To: Guus Schreiber <schreiber@cs.vu.nl>
CC: "Sini, Margherita (KCEW)" <Margherita.Sini@fao.org>, SWD WG <public-swd-wg@w3.org>

Hi Guus,
>
>> Actually I've been forwarded yesterday a case of 'broader causative'. 
>> So I guess this would confim that your 'related causative' is not a 
>> candidate for predefined specialization, if we follow what Guus 
>> decided for 'related partitive'.
>>
>> By the way my position on this specialization aspect is simple: let's 
>> include nothing.
>> First, it adds relation to SKOS
>> Second, well, I feel that we're trying to do this to be more 
>> compliant with standards like ISO2788. But if we do it half-way 
>> (broaderGeneric and broaderInstantive but not broaderPartitive) that 
>> might look a bit shaky, even if there are valid motivations for doing 
>> so.
>
> Antoine,
> Sorry, my text was apparently not clear. It was my proposal to *keep* 
> broader/narrowerPartitive (and drop the related part-of variant), 
> because it is the intuitive one and also keeps the relation with ISO 
> 2788.

My fault. So this removes my objection.

>>
>> But if we include them anyway: I like very much the semantics Guus 
>> has proposed for broaderGeneric and broaderInstantive.
>
> On reflection, we might just define broaderGeneric and 
> broaderInstantive as owl:equivalentProperty of resp. rdfs:subClassOf 
> and rdf:type (and not as subproperties of these).

Intuitively I'm ok with that. The problem is that this makes almost 
every OWL class also a SKOS concept, by the domain and range of 
skos:semanticRelation!
We've got to be sure if we want this as a side effect of an apparently 
innocent extension ;-)

Antoine
>>
>>
>>> 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
>>> mentioned:
>>>
>>> - relatedCausative (all the ones like causes/isCausedBy,
>>> benefitFrom/isBeneficialFor, affects/isAffectedBy, etc...)
>>>
>>> - relatedTermporal (all the ones like follows/precedes,
>>> developsFrom/developsInto)
>>>
>>> - 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"...?
>>>
>>> regards
>>> Margherita
>>>
>>> -----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
>>> To: SWD WG
>>> Subject: ISSUE 37+56
>>>
>>>
>>>
>>> All,
>>> Here are some thoughts about the specialization/extension issues.
>>> Guus
>>>
>>> ISSUE 37 Skos Specialization 
>>> http://www.w3.org/2006/07/SWD/track/issues/37
>>> ISSUE 56 ReferenceSemanticRelationshipSpecializations
>>> http://www.w3.org/2006/07/SWD/track/issues/56
>>>
>>> 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
>>>
>>>
>>>   
>>
>
Received on Wednesday, 12 March 2008 15:48:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 March 2008 15:48:26 GMT