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

Guus Schreiber wrote:
> 
> 
> 
> Jon Phipps wrote:
>> Guus,
>>
>> It seems like a good case can be made for requiring labels to be
>> resources and an equally good case can be made for keeping the SKOS
>> spec as simple as possible.
>>
>> I have always been impressed by the practical utility of the Dublin
>> Core approach to balancing the competing needs of complexity of design
>> and simplicity of application by providing for a "dumber" expression
>> of metadata as well as a more complex expression in the same format
>> when needed.
>>
>> Is there any way to adopt _both_ the literal and resource approach to
>> labels and say that... if your application requires relationships
>> between labels then they may be expressed as resources and otherwise
>> they may/should be expressed as literals? And then provide a normative
>> way of expressing labels as resources that is 'compatible' with labels
>> expressed as simple literals.
>>
>> Several weeks ago Alistair suggested dropping the notion of separate
>> SKOS and SKOS-CORE brands, since there was no longer a distinction
>> between the two. I'm wondering if perhaps this discussion presents a
>> case for a simpler SKOS-CORE and a more complex but compatible SKOS
>> specification. But then maybe this is no longer an option or has even
>> worse side effects.
> 
> Well, I guess we could go down this road. It would mean that we do not 
> define ranges for skos:prefLabel and skos:altLabel. We can still define 
> a class skos:Term but do not require it to be the range of the label 
> properties. The Guide could then indicate the two patterns for 
> specifying terms. But it would also mean that we have to indicate how 
> people should manage interoperability between vocabularies using a 
> different pattern.
> 
> The more I think of it, the more it seems like a good resolution. It 
> follows the principle of minimal commitment. Whether it should lead to 
> an distinction between a Core part and Full part (possible several Full 
> parts) is another question. I would not like to go down the OWL road, 
> introducing several dialects. I prefer just showing usage patterns in 
> the Guide.

I forgot to add one more advantage of Jon's 
proposal: it preserves backward compatibility with 
existing SKOS vocabularies. If we would enforce a 
term-as-class approach some existing users might 
not be amused.

Guus

> 
> Guus
> 
>>
>> Just tossing some ideas around...
>>
>> --Jon
>>
>> On 2/28/07, Guus Schreiber <schreiber@cs.vu.nl> 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
>>>    - 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/
>>>
>>>
> 

-- 
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 17:00:47 UTC