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

I'm sorry I will not be able to comment on this issue until the 12th of March at the earliest. I request that a resolution on this issue be postponed until the telecon of the 20th March.

Thanks,

Alistair. 

> -----Original Message-----
> From: public-swd-wg-request@w3.org [mailto:public-swd-wg-request@w3.org]
> On Behalf Of Guus Schreiber
> Sent: 01 March 2007 14:44
> To: Jon Phipps
> Cc: Antoine Isaac; Daniel Rubin; SWD WG
> Subject: 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 18:20:27 UTC