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

At 05:22 AM 2/28/2007, Guus Schreiber wrote:



>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

yes, but what about the terminology use cases for 
which you want to associate other metainformation 
with the "Impressionist" and "Impressionism" 
terms (provenance info, synonymy, etc)?
And the issue of intuitive representations is 
more of a tool issue of working with skos, no? 
(In protege, both models would have similar appearance).

>   - the need to define a scheme for generating URIs for all terms

I think having URIs for all terms is a good thing, though, no?


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

For the use cases I work with, representing term relations is very important.


>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 21:33:25 UTC