W3C home > Mailing lists > Public > public-swd-wg@w3.org > February 2007

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

From: Jon Phipps <jphipps@madcreek.com>
Date: Wed, 28 Feb 2007 10:04:22 -0500
Message-ID: <34b5049c0702280704m4897390bo956036259be1c280@mail.gmail.com>
To: "Guus Schreiber" <schreiber@cs.vu.nl>
Cc: "SWD WG" <public-swd-wg@w3.org>

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.

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/
>
>
Received on Wednesday, 28 February 2007 15:04:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:17:28 GMT