[SKOS] Proposal Form (was: RE: AW: [SKOS] Proposed Resolution for ISSUE 26: RelationshipBetweenLabels)

Hi all,

I've thought a bit more about making proposals for SKOS, and I've
written up the following:

<http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ProposalForm?action=recal
l&rev=15>

I'd like to offer this as a suggested format for structuring proposals.
It's the same as what I suggested below, except for the addition of a
section to describe syntactic constraints and a section for discussion.

I'm basically trying to ensure that proposals contain all the
information that would be required by a normative specification of SKOS.
This should enable us to directly and precisely compare alternative
proposals. This would also mean that, once a proposal is accepted, it
can simply be added directly to a draft of the normative specification,
because all the necessary information is already present.

Cheers,

Alistair.

--
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 Miles, AJ 
> (Alistair)
> Sent: 19 March 2007 17:14
> To: SWD WG
> Cc: public-esw-thes@w3.org
> Subject: 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/RelationshipsBet
> weenLabels
> 
> --
> 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 Wednesday, 21 March 2007 11:15:26 UTC