W3C home > Mailing lists > Public > public-swd-wg@w3.org > February 2007

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

From: Guus Schreiber <schreiber@cs.vu.nl>
Date: Wed, 28 Feb 2007 14:22:49 +0100
Message-ID: <45E58229.7080409@cs.vu.nl>
To: Jan Henke <jan.henke@deri.org>
CC: 'Daniel Rubin' <rubin@med.stanford.edu>, 'SWD WG' <public-swd-wg@w3.org>



Jan Henke wrote:
> Dear all,
> 
> I'd like to add some arguments for the labels as classes approach:
> 
>>From an OO-point of view, the subject and object of Guus' Labelrelation can
> be seen as instances. If the same labels are used in different contexts, we
> duplicate them, i.e. introduce an unessacary redundance.
> 
> I think Guus' approach also violates the OO design heuristic "Keep related
> data and behaviour in one place" [1], because it externalizes some data
> although it is never used without the externalizing object (done by the
> inverseFunctional statement). In other words, you create a relation object
> which can only be used together with one concept c, and I think in such a
> case it is better to put the dependent part into c and create a reusable
> object out of the rest (i.e. the label object).
> 
> Guus' approach is basically an application of the "Introducing a new class
> for a relation" pattern [2] which I always regarded as somehow working but
> not really as a (nice) solution.

I'm apparently not making myself clear. Of course, 
this proposal will
not win a beauty contest. Theoretically speaking, the
term-as-class approach is much cleaner and nicer; 
we probably all
agree on that. I pointed in another message [1] to 
the WordNet example
where we followed precisely this approach.

However, the decision should not purely be based 
on beauty, but also
on usability. Let's take an Art & Architecture 
Thesaurus example [2]:

    with terms as literals:

    aat:300021503 rdf:type skos:Concept.
    aat:300021503 skos:prefLabel "Impressionist".
    aat:300021503 skos:altLabel "Impressionism".

    with terms as classes

    aat:300021503 rdf:type skos:Concept.
    aat:300021503 skos:prefLabel aat:termURI_1.
    aat:300021503 skos:altLabel aat:termURI_2.
    aat:termURI_1 rdf:type skos:Term.
    aat:termURI_1 rdfs:label "Impressionist".
    aat:termURI_2 rdf:type skos:Term.
    aat:termURI_2 rdfs:label "Impressionism".

   [omitted datatypes and language labels]

The price you pay for terms-as-classes is 
potentially three-fold:

   - more triples
   - less intuitive representation for naive user 
(thesaurus builder)
     through the level of indirection
   - the need to define a scheme for generating 
URIs for all terms

Dependent on your viewpoint this price may be low 
or high and we have
to balance this with the frequency of needing to 
represent term
relations and properties in the target 
vocabularies for SKOS.

So, I would like to hear arguments wrt this 
balancing issue.

Guus

[1] 
http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0210.html
[2] 
http://www.getty.edu/research/conducting_research/vocabularies/aat/

> Best regards
> Jan
> 
> [1] http://lcm.csa.iisc.ernet.in/soft_arch/OO_Design_Heuristic.htm
> [2] http://www.w3.org/TR/swbp-n-aryRelations/#pattern1
> 
> 
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: public-swd-wg-request@w3.org 
>> [mailto:public-swd-wg-request@w3.org] Im Auftrag von Daniel Rubin
>> Gesendet: Mittwoch, 28. Februar 2007 00:58
>> An: Guus Schreiber; SWD WG
>> Betreff: Re: [SKOS] Proposed Resolution for ISSUE 26: 
>> RelationshipBetweenLabels
>>
>>
>> At 03:42 AM 2/27/2007, Guus Schreiber wrote:
>>
>>> 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,
>> As I mentioned on the tcon today, I think that lexical labels 
>> should be represented as classes, precisely because they need 
>> to be able to participate in relations with other classes. I 
>> do not see doing this an undesirable complication of 
>> SKOS--this is an issue of what representation is needed in 
>> order to express the  necessary relations.
>>
>>> - 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
>> To me, this approach adds undesirable complexity to SKOS.
>>
>>
>>> 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/
>>
>>
> 
> 

-- 
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/
Received on Wednesday, 28 February 2007 13:23:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:17:28 GMT