RE: [SKOS] Amsterdam topic: "Label relations"

Hi all,

For the record, here is my position on the three options:

> > >   Three options will be discussed in Amsterdam
> > >    * 
> [http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBe
> tweenLabels/ProposalFour 
> > >      Alistair's "Minimal Label Relation" proposal]

I think this proposal is mature enough for consideration. There aren't any difficult or complicated logical semantics or dependencies on other parts of the SKOS vocabulary, and "telling the story" would be quite straighforward. We might need to discuss further about the precise meaning or name of the different components e.g. skos:seeLabelRelation, but we could at least agree to adopt this proposal *as a pattern*, then work on the details after.

If we have to make a decision at the f2f, I would recommend we agree to adopt the pattern used in this proposal, then work on the finer details of choosing URIs etc. 

> > >    * 
> [http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBe
> tweenLabels/ProposalThree 
> > >      Guus "Simple Extension" proposal]

I think this proposal needs further work, even as a pattern, and is not ready for consideration. 

The main reason is that there are two possible variants of this proposal, which are actually very different in nature, which could each be considered as a proposal in their own right (given a bit more work on the story). See <http://purl.org/net/skos/2007/10/f2f/label-relations.html> for more explanation of this point.

> > >    * 
> [http://lists.w3.org/Archives/Public/public-swd-wg/2007Sep/001
> 3.html Guus "remove range 
> > >      restriction for skos: prefLabel" proposal]

I would like to permanently rule out this proposal. 

The main reason is that having a complex range for the properties skos:prefLabel, skos:altLabel and skos:hiddenLabel makes for a very complicated semantics, which I don't know how to construct. For example, specifying the disjointess of these properties, or the cardinality of skos:prefLabel, would become very difficult, if not impossible. It's already hard enough to do this with just a simple range as the class of RDF plain literals. See <http://purl.org/net/skos/2007/10/f2f/labelling-properties.html> for more explanation of this point.

-- Conclusion --

If we *have* to make a decision at the f2f, then I think the only proposal which can be considered is the "Minimal Label Relation" proposal. I would recommend we agree to adopt the pattern illustrated in this proposal, then work some more on the details.

If we don't have to make a decision at the f2f, then we could do some more work on elaborating the two variants of the "Simple Extension" proposal, then make a decision in a couple of months. 

Being absolutely ruthless, I don't think label relations are mission-critical for SKOS. I.e. SKOS could be a successful specification and meet it's most important requirements without built-in support for label relations. Support for label relations could always be developed as extensions/add-ons to SKOS within the community of practice. Therefore, I think delaying the decision (or even postponing the requirement) would be acceptable.

On the other hand, I do think label relations would significant value to SKOS -- it would be nice if we could work out a solution.

Cheers,

Alistair.


--
Alistair Miles
Research Associate
Science and Technology Facilities Council
Rutherford Appleton Laboratory
Harwell Science and Innovation Campus
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 Wednesday, 3 October 2007 12:23:26 UTC