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

Hi Mark,

> -----Original Message-----
> From: Mark van Assem [mailto:mark@cs.vu.nl]
> Sent: 22 March 2007 13:00
> To: Miles, AJ (Alistair)
> Cc: public-esw-thes@w3.org; SWD WG
> Subject: Re: [SKOS] Proposed Resolution for ISSUE 26:
> RelationshipBetweenLabels
> 
> 
> Hi Alistair,
> 
> My apologies, indeed I quoted the wrong example. Indeed they are
> special cases of your Annotation vocabulary given in [1] (just
> repeating to get this clear for myself).
> 
> - In the example extension given in [1] you specialize skos:Annotation
> into an ex:AbbreviationRelation and the skos:annotatesLiteral into
> ex:abbrevFrom and ex:fullForm.
> 
> - in the animals/fauna extension you specialize skos:Annotation into
> ex:ThesaurusTerm and skos:annotation into ex:prefTerm ex:altTerm.
> 
> So the crucial bit here is that you can specialize skos:Annotation
> into either a class representing a relation, or a class representing a
> Term. 

Yes, that's exactly the idea.

> That's really clever. It does make me feel uncomfortable though,
> from an ontology engineering point of view it feels like wrong
> modeling. But I have no clear idea whether it really matters.

One advantage of this solution is that it would provide an extension
point, from which communities could explore a variety of classes of
entity and/or n-ary relation with different logical semantics. I.e. SKOS
wouldn't pin anyone down to a single notion of what a "Term" is or might
be - communities would be free to define their own extensions, from a
common, well-defined extension point.

A disadvantage of this solution is that the class skos:Annotation would
be rather general, with different extensions potentially serving quite
different purposes. How should generic SKOS applications handle this?

Cheers,

Alistair.

[1]
<http://lists.w3.org/Archives/Public/public-swd-wg/2007Mar/0092.html>


> 
> Cheers,
> Mark.
> 
> > The first example I gave (animals/fauna) was meant to illustrate how
a
> > "terms-as-classes" representation can be defined as an extension of
my
> > proposal [1].
> >
> > The second example I gave (Corporation/Corp. - which you quote
below)
> > was meant to illustrate how an "n-ary relations" representation can
be
> > defined an extension of my proposal [1]. I.e. the second example had
> > nothing to do with "terms-as-classes".
> >
> > Does that clarify?
> >
> > Cheers,
> >
> > Alistair.
> >
> >
> >> -----Original Message-----
> >> From: Mark van Assem [mailto:mark@cs.vu.nl]
> >> Sent: 20 March 2007 12:07
> >> To: Miles, AJ (Alistair); public-esw-thes@w3.org
> >> Subject: Re: [SKOS] Proposed Resolution for ISSUE 26:
> >> RelationshipBetweenLabels
> >>
> >> Hi Alistair,
> >>
> >> Why is terms-as-classes an extension of [1]? The whole idea of
> >> terms-as-classes is that properties can be made between the
> >> term-classes (i.e. between two URIs), while [1] assigns no
> >> URI to them
> >> but simply repeats the literal. If the range of
> >> abbreviatedForm were a
> >> resource (URI) instead of a literal, then I would agree that they
are
> >> equivalent (but still not an extension).
> >>
> >> ex:A a skos:Concept;
> >>    skos:prefLabel "Corporation"@en;
> >>    skos:altLabel "Corp."@en;
> >>    skos:annotation [
> >>      a ex:AbbreviationRelation;
> >>      ex:abbreviatedForm "Corp."@en;
> >>      ex:fullForm "Corporation"@en;
> >>    ].
> >>
> >> Cheers,
> >> Mark.
> >>
> >> [1]http://lists.w3.org/Archives/Public/public-swd-
> wg/2007Mar/0092.html
> >>
> >> Miles, AJ (Alistair) wrote:
> >>> As a point of interest, note that a representation following the
> >>> "terms-as-classes" pattern can actually be defined as an
> >> *extension* of
> >>> my proposal at [1]. Guus' proposal [3] (which follows the "n-ary
> >>> relations" pattern) can *also* be derived as an extension of [1].
> >>>
> >>> This demonstrates that it is not a simple "either-or"
> >> choice between the
> >>> "terms-as-classes" and "n-ary relations" patterns described at
[2].
> >>> There is a solution [1] from which both approaches may be derived
as
> >>> extensions.
> >>>
> >>> Example "terms-as-classes" extension ...
> >>>
> >>> --- Begin Turtle ---
> >>>
> >>> @prefix ex: <http://www.example.com/example#>.
> >>> # skos: rdfs: rdf: xsd: conventional namespace prefixes
> >>>
> >>> # Define the extension
> >>>
> >>> ex:ThesaurusTerm rdfs:subClassOf skos:Annotation.
> >>> ex:preferredTerm rdfs:subPropertyOf skos:annotation;
> >>>   rdfs:range ex:ThesaurusTerm.
> >>> ex:nonPreferredTerm rdfs:subPropertyOf skos:annotation;
> >>>   rdfs:range ex:ThesaurusTerm.
> >>> ex:literalValue rdfs:subPropertyOf skos:annotatesLiteral;
> >>>   rdfs:domain ex:ThesaurusTerm.
> >>>
> >>> # Apply extended vocabulary
> >>>
> >>> ex:A a skos:Concept;
> >>>   skos:prefLabel "animals"@en;
> >>>   skos:altLabel "fauna"@en;
> >>>   ex:preferredTerm [
> >>>     a ex:ThesaurusTerm;
> >>>     ex:literalValue "animals"@en;
> >>>   ];
> >>>   ex:nonPreferredTerm [
> >>>     a ex:ThesaurusTerm;
> >>>     ex:literalValue "fauna"@en;
> >>>   ].
> >>>
> >>> --- End Turtle ---
> >>>
> >>> Example "n-ary relations" extension ...
> >>>
> >>> --- Begin Turtle ---
> >>>
> >>> @prefix ex: <http://www.example.com/example#>.
> >>> # skos: rdfs: rdf: conventional namespace prefixes
> >>>
> >>> # Define the extension
> >>>
> >>> ex:LabelRelation rdfs:subClassOf skos:Annotation.
> >>> ex:AbbreviationRelation rdfs:subClassOf ex:LabelRelation.
> >>> ex:labelRelationSubject rdfs:subPropertyOf skos:annotatesLiteral;
> >>>   rdfs:domain ex:LabelRelation.
> >>> ex:labelRelationObject rdfs:subPropertyOf skos:annotatesLiteral;
> >>>   rdfs:domain ex:LabelRelation.
> >>> ex:hasLabelRelation rdfs:subPropertyOf skos:annotation;
> >>>   rdfs:range ex:LabelRelation.
> >>>
> >>> # Apply extended vocabulary
> >>>
> >>> ex:B a skos:Concept;
> >>>   skos:prefLabel "Corporation"@en;
> >>>   skos:altLabel "Corp."@en;
> >>>   ex:hasLabelRelation [
> >>>     a ex:AbbreviationRelation;
> >>>     ex:labelRelationSubject "Corporation"@en;
> >>>     ex:labelRelationObject "Corp."@en;
> >>>   ].
> >>>
> >>> --- End Turtle ---
> >>>
> >>> Finally, note that the proposal [1] is also a solution to
> >> the issue of
> >>> annotations on labels.
> >>>
> >>> Cheers,
> >>>
> >>> Alistair.
> >>>
> >>> [1]
> >> http://lists.w3.org/Archives/Public/public-swd-wg/2007Mar/0092.html
> >>> [2]
> >>>
> >> http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBet
> >> weenLabels
> >>> [3] http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0181
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: public-swd-wg-request@w3.org
> >>>> [mailto:public-swd-wg-request@w3.org] On Behalf Of Miles, AJ
> >>>> (Alistair)
> >>>> Sent: 19 March 2007 17:42
> >>>> To: Guus Schreiber; SWD WG
> >>>> Cc: public-esw-thes@w3.org
> >>>> Subject: RE: [SKOS] Proposed Resolution for ISSUE 26:
> >>>> RelationshipBetweenLabels
> >>>>
> >>>>
> >>>> I would like to offer an alternative proposal. This proposal
> >>>> is similar
> >>>> to Guus' original proposal [1] with the modification given in
[2].
> >>>> However, it it slightly more flexible, making less commitment
than
> >>>> [1]+[2].
> >>>>
> >>>>  - Vocabulary
> >>>>
> >>>> skos:Annotation skos:annotation skos:annotatesLiteral
> >>>>
> >>>>  - Axiomatic Triples
> >>>>
> >>>> skos:annotation rdfs:range skos:Annotation.
> >>>> skos:annotatesLiteral rdfs:domain skos:Annotation.
> >>>> skos:annotatesLiteral rdfs:range rdfs:Literal.
> >>>>
> >>>>  - Additional Semantic Conditions:
> >>>>
> >>>> None.
> >>>>
> >>>>  - Consistent Examples:
> >>>>
> >>>> --- Begin Turtle ---
> >>>>
> >>>> @prefix ex: <http://www.example.com/example#>.
> >>>> # skos: rdfs: rdf: conventional namespace prefixes
> >>>>
> >>>> # first extend proposed vocabulary
> >>>>
> >>>> ex:AbbreviationRelation rdfs:subClassOf skos:Annotation.
> >>>>
> >>>> ex:abbreviatedForm rdfs:subPropertyOf skos:annotatesLiteral;
> >>>>   rdfs:domain ex:AbbreviationRelation.
> >>>>
> >>>> ex:fullForm rdfs:subPropertyOf skos:annotatesLiteral;
> >>>>   rdfs:domain ex:AbbreviationRelation.
> >>>>
> >>>> # now apply extended vocab
> >>>>
> >>>> ex:A a skos:Concept;
> >>>>   skos:prefLabel "Corporation"@en;
> >>>>   skos:altLabel "Corp."@en;
> >>>>   skos:annotation [
> >>>>     a ex:AbbreviationRelation;
> >>>>     ex:abbreviatedForm "Corp."@en;
> >>>>     ex:fullForm "Corporation"@en;
> >>>>   ].
> >>>>
> >>>> --- End Turtle ---
> >>>>
> >>>>  - Inconsistent Examples:
> >>>>
> >>>> None possible.
> >>>>
> >>>>  - Entailment Rules
> >>>>
> >>>> None.
> >>>>
> >>>>  - Justification
> >>>>
> >>>> This proposal provides a general, extendable, framework
> >> for asserting
> >>>> n-ary relationsips between zero or more literals and zero or more
> >>>> concepts. The commitment is minimal, whilst still
> >> retaining consistent
> >>>> expectations with respect to the domains and ranges of properties
> >>>> involved.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Alistair.
> >>>>
> >>>>
> >>>> [1]
http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0181
> >>>> [2]
> >>>>
http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0195.html
> >>>>
> >>>> --
> >>>> Alistair Miles
> >>>> Research Associate
> >>>> CCLRC - Rutherford Appleton Laboratory
> >>>> Building R1 Room 1.60
> >>>> Fermi Avenue
> >>>> Chilton
> >>>> Didcot
> >>>> Oxfordshire OX11 0QX
> >>>> United Kingdom
> >>>> Web: http://purl.org/net/aliman
> >>>> Email: a.j.miles@rl.ac.uk
> >>>> Tel: +44 (0)1235 445440
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: public-swd-wg-request@w3.org
> >>>>> [mailto:public-swd-wg-request@w3.org] On Behalf Of Guus
Schreiber
> >>>>> Sent: 27 February 2007 11:43
> >>>>> To: SWD WG
> >>>>> Subject: [SKOS] Proposed Resolution for ISSUE 26:
> >>>>> RelationshipBetweenLabels
> >>>>>
> >>>>>
> >>>>> 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,
> >>>>> - 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
> >>>>>
> >>>>> 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/
> >>>>>
> >>>>>
> >>>
> >>>
> >>> --
> >>> Alistair Miles
> >>> Research Associate
> >>> CCLRC - Rutherford Appleton Laboratory
> >>> Building R1 Room 1.60
> >>> Fermi Avenue
> >>> Chilton
> >>> Didcot
> >>> Oxfordshire OX11 0QX
> >>> United Kingdom
> >>> Web: http://purl.org/net/aliman
> >>> Email: a.j.miles@rl.ac.uk
> >>> Tel: +44 (0)1235 445440
> >>>
> >> --
> >>   Mark F.J. van Assem - Vrije Universiteit Amsterdam
> >>         markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
> >>
> 
> --
>   Mark F.J. van Assem - Vrije Universiteit Amsterdam
>         markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark

--
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Web: http://purl.org/net/aliman
Email: a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440

Received on Tuesday, 27 March 2007 15:51:17 UTC