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

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

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Fri, 30 Mar 2007 13:51:06 +0200
Message-ID: <460CF9AA.6070707@few.vu.nl>
To: Mark van Assem <mark@cs.vu.nl>
CC: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>, public-esw-thes@w3.org, SWD WG <public-swd-wg@w3.org>

Hello Alistair and Mark,

>
>
>> A disadvantage of this solution is that the class skos:Annotation would
>> be rather general, with different extensions potentially serving quite
>> different purposes. How should generic SKOS applications handle this?
>
>
> Maybe providing two subclasses of skos:Annotation for modeling either 
> Relations or Terms provides some support for generic apps to 
> understand the extensions? That immediately provides clues on how to 
> interpret skos:annotation and skos:annotatesLiteral in the two cases.

To me this amounts to explicitly endorse both Term-as-class and 
Relation-as-class approaches in the standard.
Notice that in my opinion, if we choose the generic approach Alistair 
proposes in [1], introducing explicitly this specializations appears the 
only tractable solution. There is elegance in the proposed model, which 
does the job, that's sure. But from a practical point of view, letting 
users deal alone with an Annotation class sounds to me more like a 
nightmare, if this class groups resources that can be terms, relations 
between literals, as well as "standard" annotations (like creation date).

Also, when you look at [2] and the Term-as-class implementation example, 
a concept has both a preferredLabel (pointing to a literal) and a 
preferredTerm (pointing to a resource)

>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;
>  ].
>
I don't think this is really good practice: I would even prefer the 
sloppiness introduced by the range underspecification in Guus' second 
(or third? ;-) proposal [3]

Cheers,

Antoine

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2007Mar/0092.html
[2] http://lists.w3.org/Archives/Public/public-swd-wg/2007Mar/0099.html
[3] http://lists.w3.org/Archives/Public/public-swd-wg/2007Mar/0004.html

>
> If only the Pattern for N-ary relations [1] had already provided a 
> class for Relation it would have been great to use that.
>
> Cheers,
> Mark.
>
> [1]http://www.w3.org/TR/swbp-n-aryRelations/
>
>> Cheers,
>>
>> Alistair.
>>
>> [1]
>> <http://lists.w3.org/Archives/Public/public-swd-wg/2007Mar/0092.html>
>>
>>
>>> 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
>>
>>
>> -- 
>> 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
>>
>
Received on Friday, 30 March 2007 11:51:26 GMT

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