W3C home > Mailing lists > Public > public-esw-thes@w3.org > May 2006

Change proposal

From: Mark van Assem <mark@cs.vu.nl>
Date: Sat, 20 May 2006 15:44:03 +0300
To: public-esw-thes@w3.org
Cc: Alistair Miles <a.j.miles@rl.ac.uk>
Message-id: <446F0F13.7000107@cs.vu.nl>


Hi all,

Alistair requested me some time ago to write a "change proposal" to
document the issue of not having URIs for terms in SKOS (instead they
are rdfs:Literals).

Basically this is to record the trade-offs of both solutions, because we
could not agree on what action to take.

I am still unconvinced that it is better to not have URIs for terms, but
   as the SWBP WG is at its end, I will settle for just recording the issue.

Alistair, can you add this to the CP list [1] (provided the text is ok)?

With regards,
Mark.

[1]http://www.w3.org/2004/02/skos/core/proposals

----------------------------------------------------------------------
Change Proposal

* Title: Additional properties of terms

* Type: known requirement for which solution has trade-offs

* Issue/Requirement

SKOS Core uses a class skos:Concept to represent "concepts" and
skos:prefLabel/skos:altLabel to represent "terms" or "labels" that
represent the concept lexically. Some concept schemes that are used in
practice represent additional information on terms, such as [1]:

- scope notes for terms, also referring to other terms to use
- lexical information about the term
- scope of usage of the lexical term
- etymological information
- register-related information
- standardization related information
- local identifiers for terms
- date of creation
- last date of modification
- term abbreviations
- source of the term (if the concept scheme is built up from other
sources)
- definitions of terms

However, because the range of skos:prefLabel/skos:altLabel is
rdfs:Literal it is not possible to attach these kinds of information
to terms (properties cannot have rdfs:Literal as domain).


* Possible Solution(s)

Provide a way to represent "terms" as instances of a class so that
additional properties can be attached to them.

- introduce a class skos:Term;
- rename skos:prefLabel/skos:altLabel to skos:prefTerm/skos:altTerm
- Change the range of these properties into skos:Term

With this solution in place it is possible to provide a set of common
term-centric properties in SKOS Core and/or provide superproperties that
can be locally extended.

* Trade-offs

+ less information loss in conversion of concept schemes that
   contain these kinds of information on terms
- model becomes more complex
- most retrieval purposes are already covered by the existing model
   (benefits of new model for information retrieval may be limited)


* Proposed action

Future SKOS activities should reconsider this Issue, make a definitive
choice and provide an explanation of the particular choice, detailing
the above mentioned trade-offs.

* References

[1]http://lists.w3.org/Archives/Public/public-esw-thes/2005Nov/0000.html



-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Saturday, 20 May 2006 12:44:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:54 GMT