W3C home > Mailing lists > Public > public-esw-thes@w3.org > March 2007

Re: [SKOS] Proposed Resolution for ISSUE 26: RelationshipBetweenLabels

From: Mark van Assem <mark@cs.vu.nl>
Date: Thu, 22 Mar 2007 14:00:09 +0100
Message-ID: <46027DD9.1060505@cs.vu.nl>
To: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>
CC: public-esw-thes@w3.org, SWD WG <public-swd-wg@w3.org>


Hi Alistair,

My apologies, indeed I quoted the wrong example. Indeed they are 
special cases of your Annotation vocabulary given in [1] (just 
repeating to get this clear for myself).

- In the example extension given in [1] you specialize skos:Annotation 
into an ex:AbbreviationRelation and the skos:annotatesLiteral into 
ex:abbrevFrom and ex:fullForm.

- in the animals/fauna extension you specialize skos:Annotation into 
ex:ThesaurusTerm and skos:annotation into ex:prefTerm ex:altTerm.

So the crucial bit here is that you can specialize skos:Annotation 
into either a class representing a relation, or a class representing a 
Term. That's really clever. It does make me feel uncomfortable though, 
from an ontology engineering point of view it feels like wrong 
modeling. But I have no clear idea whether it really matters.

Cheers,
Mark.

> The first example I gave (animals/fauna) was meant to illustrate how a
> "terms-as-classes" representation can be defined as an extension of my
> proposal [1].
> 
> The second example I gave (Corporation/Corp. - which you quote below)
> was meant to illustrate how an "n-ary relations" representation can be
> defined an extension of my proposal [1]. I.e. the second example had
> nothing to do with "terms-as-classes".
> 
> Does that clarify?
> 
> Cheers,
> 
> Alistair.
>  
> 
>> -----Original Message-----
>> From: Mark van Assem [mailto:mark@cs.vu.nl] 
>> Sent: 20 March 2007 12:07
>> To: Miles, AJ (Alistair); public-esw-thes@w3.org
>> Subject: Re: [SKOS] Proposed Resolution for ISSUE 26: 
>> RelationshipBetweenLabels
>>
>> Hi Alistair,
>>
>> Why is terms-as-classes an extension of [1]? The whole idea of 
>> terms-as-classes is that properties can be made between the 
>> term-classes (i.e. between two URIs), while [1] assigns no 
>> URI to them 
>> but simply repeats the literal. If the range of 
>> abbreviatedForm were a 
>> resource (URI) instead of a literal, then I would agree that they are 
>> equivalent (but still not an extension).
>>
>> ex:A a skos:Concept;
>>    skos:prefLabel "Corporation"@en;
>>    skos:altLabel "Corp."@en;
>>    skos:annotation [
>>      a ex:AbbreviationRelation;
>>      ex:abbreviatedForm "Corp."@en;
>>      ex:fullForm "Corporation"@en;
>>    ].
>>
>> Cheers,
>> Mark.
>>
>> [1]http://lists.w3.org/Archives/Public/public-swd-wg/2007Mar/0092.html
>>
>> Miles, AJ (Alistair) wrote:
>>> As a point of interest, note that a representation following the
>>> "terms-as-classes" pattern can actually be defined as an 
>> *extension* of
>>> my proposal at [1]. Guus' proposal [3] (which follows the "n-ary
>>> relations" pattern) can *also* be derived as an extension of [1]. 
>>>
>>> This demonstrates that it is not a simple "either-or" 
>> choice between the
>>> "terms-as-classes" and "n-ary relations" patterns described at [2].
>>> There is a solution [1] from which both approaches may be derived as
>>> extensions.
>>>
>>> Example "terms-as-classes" extension ...
>>>
>>> --- Begin Turtle ---
>>>
>>> @prefix ex: <http://www.example.com/example#>.
>>> # skos: rdfs: rdf: xsd: conventional namespace prefixes
>>>
>>> # Define the extension
>>>
>>> ex:ThesaurusTerm rdfs:subClassOf skos:Annotation.
>>> ex:preferredTerm rdfs:subPropertyOf skos:annotation;
>>>   rdfs:range ex:ThesaurusTerm.
>>> ex:nonPreferredTerm rdfs:subPropertyOf skos:annotation;
>>>   rdfs:range ex:ThesaurusTerm.
>>> ex:literalValue rdfs:subPropertyOf skos:annotatesLiteral;
>>>   rdfs:domain ex:ThesaurusTerm.
>>>
>>> # Apply extended vocabulary
>>>
>>> ex:A a skos:Concept;
>>>   skos:prefLabel "animals"@en;
>>>   skos:altLabel "fauna"@en;
>>>   ex:preferredTerm [
>>>     a ex:ThesaurusTerm;
>>>     ex:literalValue "animals"@en;
>>>   ];
>>>   ex:nonPreferredTerm [
>>>     a ex:ThesaurusTerm;
>>>     ex:literalValue "fauna"@en;
>>>   ].
>>>
>>> --- End Turtle ---
>>>
>>> Example "n-ary relations" extension ...
>>>
>>> --- Begin Turtle ---
>>>
>>> @prefix ex: <http://www.example.com/example#>.
>>> # skos: rdfs: rdf: conventional namespace prefixes
>>>
>>> # Define the extension
>>>
>>> ex:LabelRelation rdfs:subClassOf skos:Annotation.
>>> ex:AbbreviationRelation rdfs:subClassOf ex:LabelRelation.
>>> ex:labelRelationSubject rdfs:subPropertyOf skos:annotatesLiteral;
>>>   rdfs:domain ex:LabelRelation.
>>> ex:labelRelationObject rdfs:subPropertyOf skos:annotatesLiteral;
>>>   rdfs:domain ex:LabelRelation.
>>> ex:hasLabelRelation rdfs:subPropertyOf skos:annotation;
>>>   rdfs:range ex:LabelRelation.
>>>
>>> # Apply extended vocabulary 
>>>
>>> ex:B a skos:Concept;
>>>   skos:prefLabel "Corporation"@en;
>>>   skos:altLabel "Corp."@en;
>>>   ex:hasLabelRelation [
>>>     a ex:AbbreviationRelation;
>>>     ex:labelRelationSubject "Corporation"@en;
>>>     ex:labelRelationObject "Corp."@en;
>>>   ].
>>>
>>> --- End Turtle ---
>>>
>>> Finally, note that the proposal [1] is also a solution to 
>> the issue of
>>> annotations on labels. 
>>>
>>> Cheers,
>>>
>>> Alistair.
>>>
>>> [1] 
>> http://lists.w3.org/Archives/Public/public-swd-wg/2007Mar/0092.html
>>> [2]
>>>
>> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBet
>> weenLabels
>>> [3] http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0181
>>>
>>>
>>>> -----Original Message-----
>>>> From: public-swd-wg-request@w3.org 
>>>> [mailto:public-swd-wg-request@w3.org] On Behalf Of Miles, AJ 
>>>> (Alistair)
>>>> Sent: 19 March 2007 17:42
>>>> To: Guus Schreiber; SWD WG
>>>> Cc: public-esw-thes@w3.org
>>>> Subject: RE: [SKOS] Proposed Resolution for ISSUE 26: 
>>>> RelationshipBetweenLabels
>>>>
>>>>
>>>> I would like to offer an alternative proposal. This proposal 
>>>> is similar
>>>> to Guus' original proposal [1] with the modification given in [2].
>>>> However, it it slightly more flexible, making less commitment than
>>>> [1]+[2].
>>>>
>>>>  - Vocabulary
>>>>
>>>> skos:Annotation skos:annotation skos:annotatesLiteral
>>>>
>>>>  - Axiomatic Triples
>>>>
>>>> skos:annotation rdfs:range skos:Annotation.
>>>> skos:annotatesLiteral rdfs:domain skos:Annotation.
>>>> skos:annotatesLiteral rdfs:range rdfs:Literal.
>>>>
>>>>  - Additional Semantic Conditions:
>>>>
>>>> None.
>>>>
>>>>  - Consistent Examples:
>>>>
>>>> --- Begin Turtle ---
>>>>
>>>> @prefix ex: <http://www.example.com/example#>.
>>>> # skos: rdfs: rdf: conventional namespace prefixes
>>>>
>>>> # first extend proposed vocabulary
>>>>
>>>> ex:AbbreviationRelation rdfs:subClassOf skos:Annotation.
>>>>
>>>> ex:abbreviatedForm rdfs:subPropertyOf skos:annotatesLiteral;
>>>>   rdfs:domain ex:AbbreviationRelation.
>>>>
>>>> ex:fullForm rdfs:subPropertyOf skos:annotatesLiteral;
>>>>   rdfs:domain ex:AbbreviationRelation.
>>>>
>>>> # now apply extended vocab
>>>>
>>>> ex:A a skos:Concept;
>>>>   skos:prefLabel "Corporation"@en;
>>>>   skos:altLabel "Corp."@en;
>>>>   skos:annotation [
>>>>     a ex:AbbreviationRelation;
>>>>     ex:abbreviatedForm "Corp."@en;
>>>>     ex:fullForm "Corporation"@en;
>>>>   ].
>>>>
>>>> --- End Turtle ---
>>>>
>>>>  - Inconsistent Examples: 
>>>>
>>>> None possible.
>>>>
>>>>  - Entailment Rules
>>>>
>>>> None.
>>>>
>>>>  - Justification
>>>>
>>>> This proposal provides a general, extendable, framework 
>> for asserting
>>>> n-ary relationsips between zero or more literals and zero or more
>>>> concepts. The commitment is minimal, whilst still 
>> retaining consistent
>>>> expectations with respect to the domains and ranges of properties
>>>> involved.
>>>>
>>>> Cheers,
>>>>
>>>> Alistair. 
>>>>
>>>>
>>>> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0181
>>>> [2] 
>>>> http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0195.html
>>>>
>>>> --
>>>> Alistair Miles
>>>> Research Associate
>>>> CCLRC - Rutherford Appleton Laboratory
>>>> Building R1 Room 1.60
>>>> Fermi Avenue
>>>> Chilton
>>>> Didcot
>>>> Oxfordshire OX11 0QX
>>>> United Kingdom
>>>> Web: http://purl.org/net/aliman
>>>> Email: a.j.miles@rl.ac.uk
>>>> Tel: +44 (0)1235 445440  
>>>>
>>>>> -----Original Message-----
>>>>> From: public-swd-wg-request@w3.org 
>>>>> [mailto:public-swd-wg-request@w3.org] On Behalf Of Guus Schreiber
>>>>> Sent: 27 February 2007 11:43
>>>>> To: SWD WG
>>>>> Subject: [SKOS] Proposed Resolution for ISSUE 26: 
>>>>> RelationshipBetweenLabels
>>>>>
>>>>>
>>>>> ISSUE-26 [1]
>>>>> RelationshipsBetweenLabels
>>>>>
>>>>> Considering that:
>>>>> - representing lexical labels as classes would 
>>>>> lead to an undesirable complication of SKOS in 
>>>>> straightforward use cases for the application of SKOS,
>>>>> - representing relationships between labels is 
>>>>> required in some use cases, and therefore an 
>>>>> escape mechanism should preferably be available 
>>>>> for such thesauri,
>>>>>
>>>>> I propose the WG opts for an amended version of 
>>>>> the second solution proposed in [2]:
>>>>>
>>>>> RESOLUTION
>>>>>
>>>>> The WG resolves to add the following classes and 
>>>>> properties to the SKOS specification [3]:
>>>>>
>>>>> - the class skos:LabelRelation
>>>>> - the properties skos:labelRelationSubject and 
>>>>> skos:labelRelationObject with domain LabelRelation 
>>>>> and range rdfs:literal
>>>>>
>>>>> In addition, the SKOS Guide should describe 
>>>>> guidelines for SKOS users to define their label 
>>>>> relations as specializations of LabelRelation and 
>>>>> gives examples of its intended usage. The SKOS 
>>>>> specification refrains for now to predefine 
>>>>> specializations of LabelRelation.
>>>>>
>>>>> Contrary to the proposal in [2] the class 
>>>>> LabelRelation is not defined as a subclass of 
>>>>> skos:Annotation (which is in any case not yet part 
>>>>> of the spec), as it is not an "annotation", but a 
>>>>> lexical relationship.
>>>>>
>>>>>
>>>>> [1] http://www.w3.org/2006/07/SWD/track/issues/26
>>>>> [2] 
>>>>> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBet
>>>>> weenLabels
>>>>> [3] http://www.w3.org/TR/swbp-skos-core-spec/
>>>>>
>>>>> -- 
>>>>> Vrije Universiteit 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/
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Alistair Miles
>>> Research Associate
>>> CCLRC - Rutherford Appleton Laboratory
>>> Building R1 Room 1.60
>>> Fermi Avenue
>>> Chilton
>>> Didcot
>>> Oxfordshire OX11 0QX
>>> United Kingdom
>>> Web: http://purl.org/net/aliman
>>> Email: a.j.miles@rl.ac.uk
>>> Tel: +44 (0)1235 445440  
>>>
>> -- 
>>   Mark F.J. van Assem - Vrije Universiteit Amsterdam
>>         markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
>>

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Thursday, 22 March 2007 13:01:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:55 GMT