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

Jon Phipps wrote:
> Hi Antoine,
> 
> Yes.

I had an amendment of this third proposal in mind. 
Instead of having two properties skos:prefTerm and 
skos:prefLabel, I would suggest to have just the 
current one, skos:prefLabel, and removing the 
range restriction (rdfs:literal). So, this means 
that if one queries for the the skos:prefLabel of 
a concept, one either gets a literal or a resource 
with a label equal to this literal. This prevents 
the use of construction rules and keeps the SKOS 
vocabulary simple. The only extension to the 
current SKOS vocabulary would a a class skos:Term.

In retrospect, skos:prefTerm might have been a 
better name than skos:prefLabel, but I propose to 
stick with the original name for 
backward-compatibility reasons.

Guus

PS The same holds of course for skos:altLabel.

> 
> And just to tie in last week's discussion that resulted in that page
> [1], here's a link to the last message in that thread...
> http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0167.html
> 
> --Jon
> 
> On 3/1/07, Antoine Isaac <aisaac@few.vu.nl> wrote:
>> Hi,
>>
>> Just a small question.
>> Is this alternative solution you are discussing similar to the third
>> solution I had put in [1]?
>>
>> Antoine
>>
>> [1] 
>> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels
>>
>> >
>> > At 08:55 AM 2/28/2007, 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.
>> >
>> >
>> > This is a possible solution, but then when you open the door to
>> > alternate practices, the next question arieses as to "best practice."
>> > And it also makes interoperability among different skos terminologies
>> > difficult.
>> > My feeling is that should only be a last resort if our community is
>> > irreconcilably divided.
>> >
>> >> 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/
>> >
>> >
>> >
>> >
>> >
>>
>>

-- 
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 Thursday, 1 March 2007 14:44:12 UTC