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

Hi Antoine,

Yes.

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

Received on Thursday, 1 March 2007 13:30:12 UTC