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: Tue, 27 Mar 2007 18:40:12 +0200
Message-ID: <460948EC.1040907@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,

> 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.

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
> 

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Tuesday, 27 March 2007 16:41:09 GMT

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