W3C home > Mailing lists > Public > public-swd-wg@w3.org > October 2006

SKOS requirements

From: Alistair Miles <a.j.miles@rl.ac.uk>
Date: Tue, 17 Oct 2006 12:54:34 +0100
Message-ID: <4534C47A.6030508@rl.ac.uk>
To: public-swd-wg@w3.org
CC: public-esw-thes@w3.org

Hi all,

Thanks to TomB for pointing to my presentation "SKOS: Requirements for 
Standardization" at the Dublin Core conference two weeks ago [1]. The 
full paper is also available online [2]. In this paper I tried to 
sketch a general scope and purpose for SKOS, and some ideas for how to 
proceed with the requirements analysis.

I have suggested that the overall purpose of SKOS be to support 
*retrieval applications* using *controlled vocabularies* that have a 
relatively simple structure.

I have also suggested that the use cases for SKOS should all conform 
to one of two general patterns.

The first of these patterns ("Pattern A" in [1]) involves the use of a 
controlled vocabulary to "index" a collection of objects (i.e. to 
create metadata about the objects), and then to pose "queries" which 
are evaluated in order to "retrieve" information relating to the objects.

The second of these patterns ("Pattern B" in [1]) involves a situation 
where one controlled vocabulary has been used to index a collection of 
objects, and a different controlled vocabulary is to be used to pose 
queries in order to retrieve information. In this situation, a 
*mapping* is required between the vocabularies, so that either the 
queries, or the index (i.e. the metadata), may be *translated* 
appropriately.

I have presented these suggestions to the Ecoterm group [3] (which 
includes members of ISO TC 37), at the Dublin Core Conference [4], and 
at a virtual talk hosted by the Metadata Research Centre at UNC Chapel 
Hill (slides at [5]). I have published these suggestions on the 
public-esw-thes@w3.org mailing list [6]. The BS 8723 working group is 
also aware of these suggestions - note that the scope I am suggesting 
for SKOS is very much complementary to the scope of BS 8723.

So far, I have not received any negative feedback in response to these 
suggestions.

It is on my TODO list to read the requirements/test cases/use cases 
documents for RDF [7], OWL [8], SPARQL [9] and rules [10].

I think the uses cases we describe should aim to provide a concise and 
complete description of the *functionality* that SKOS is intended to 
enable.

The example use case I gave in [2] is very much a sketch. Subsequent 
to writing [2] I published a dissertation on the theory of retrieval 
using structured vocabularies [11]. I intended that this theory would 
enable us to characterise the *retrieval functionality* that each use 
case is describing in a precise way (if we accept the general scope 
suggested above). For example, the following distinctions may help to 
characterise a use case:

  - single-field index vs. multiple-field index ([11] chapter 3)
  - relational field vs. functional field ([11] chapter 3)
  - atomic queries vs. composite queries ([11] chapter 4)
  - naive expansion vs. limited cost expansion ([11] chapters 3 and 5)
  - expansion of queries vs. expansion of index ([11] chapters 3, 4 and 5)
  - coordination vs. no coordination ([11] chapter 6)
  - structural mapping vs. query expression mapping ([11] chapter 7)
  - naive translation vs. limited cost translation ([11] chapter 7)
  - translation of queries vs. translation of index ([11] chapter 7)

[11] also contains some use cases, although I had hoped to develop 
these in more detail.

Note that [11] does not consider the ability to generate different 
types of "presentation" for humans (i.e. visualisation or rendering 
for other modalities) of a controlled vocabulary from a SKOS 
representation. I suggest that this to be a key feature of each use 
case, i.e. the types of presentation that are required.

Finally, I suggest that each use case, wherever possible, emphasises 
the requirement to merge (meta)data from more than one source. I.e. 
each use case should have a "Semantic Web" flavour to it. Use cases 
may also emphasise the need for extensibility in the language.

That's all I have for now on requirements.

Cheers,

Alistair.

[1] http://dc2006.ucol.mx/papers/miercoles/10.30/presentation.pdf
[2] 
http://isegserv.itd.rl.ac.uk/public/skos/press/dc2006/camera-ready-paper.pdf
[3] http://ecoterm.infointl.com/
[4] http://dc2006.ucol.mx/program.htm
[5] 
http://isegserv.itd.rl.ac.uk/public/skos/press/unc200610/unc-virtual.pdf
[6] http://lists.w3.org/Archives/Public/public-esw-thes/2006Jul/0010
[7] http://www.w3.org/TR/rdf-testcases/
[8] http://www.w3.org/TR/webont-req/
[9] http://www.w3.org/TR/rdf-dawg-uc/
[10] http://www.w3.org/TR/rif-ucr/
[11] http://purl.org/net/retrieval

-- 
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, 17 October 2006 11:54:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:17:26 GMT