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

Hi all,

I'd like to suggest a structure for making proposals. The structure
should help us avoid arguing at cross-purposes, by forcing us to make
our assumptions explicit. It should also help us to investigate in
detail the possible consequences of any specific proposal for software
applications, enabling us to make a highly informed decision.

One of the points I'd like to make about the argument between the
various design patterns laid out in [6] is that there are in fact *many
possible proposals* within each design pattern, each of which may have
*radically different semantics*. It only really makes sense to argue for
or against a *specific proposal* for which all the details are given as
illustrated below.

(Using Guus' original proposal [1] as an example...)

First, give the vocabulary of the proposal, e.g.:

skos:LabelRelation skos:labelRelationSubject skos:labelRelationObject

Second, give axiomatic triples using RDF and RDFS vocabularies, e.g.:

skos:labelRelationSubject rdfs:domain skos:LabelRelation.
skos:labelRelationSubject rdfs:range rdfs:Literal.
skos:labelRelationObject rdfs:domain skos:LabelRelation.
skos:labelRelationObject rdfs:range rdfs:Literal.

Third, give any further semantic conditions on the interpretation of the
vocabulary, that cannot be expressed as axiomatic triples. Semantic
conditions should be given formally, following the style used in *yellow
tables* in [2] (see e.g. the yellow table at [3]). E.g.:

(None required for Guus' original proposal [1].)

Fourth, give examples of consistent usage. E.g.:

--- Begin Turtle ---

@prefix ex: <http://www.example.com/example#>.
# skos: rdfs: rdf: conventional namespace prefixes

# first extend proposed vocabulary

ex:AbbreviationRelation rdfs:subClassOf skos:LabelRelation.

# now apply extended vocab

ex:A a skos:Concept;
  skos:prefLabel "Corporation"@en;
  skos:altLabel "Corp."@en.

[] a ex:AbbreviationRelation;
  skos:labelRelationSubject "Corporation"@en;
  skos:labelRelationObject "Corp."@en.

--- End Turtle ---

Fifth, give examples of inconsistent usage, e.g.:

(None possible for Guus' original proposal [1].)

Sixth, give any additional entailment rules which follow from the
semantic conditions specified above, following the style used in [5].
E.g.:

(None for Guus' original proposal [1].)

Cheers,

Alistair.


[1] http://lists.w3.org/Archives/Public/public-swd-wg/2007Feb/0181
[2] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
[3] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfs_interp
[4] http://www.dajobe.org/2004/01/turtle/
[5] http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rules
[6]
http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels

--
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 Antoine Isaac
> Sent: 01 March 2007 18:16
> To: Guus Schreiber
> Cc: Jon Phipps; Daniel Rubin; SWD WG
> Subject: Re: AW: [SKOS] Proposed Resolution for ISSUE 26: 
> RelationshipBetweenLabels
> 
> 
> Hi Guus,
> 
> This is seducing from a modelling point of view. However, wouldn't it 
> give a(nother) fatal blow to the OWL-DL compatibility?
> In such a setting, prefLabel could be used to point at resources or 
> literals, and would violate the constraint disjointness 
> between datatype 
> and object properties.
> 
> Unless we live happily with that, and decide to make a choice for an 
> OWL-DL compatible version of SKOS. But this raises again the issue of 
> having several versions of SKOS...
> 
> Cheers,
> 
> Antoine
> 
> >
> >
> >
> > 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/RelationshipsBet
> weenLabels 
> >>>
> >>
> >
> 
> 
>

Received on Monday, 19 March 2007 17:14:26 UTC