W3C home > Mailing lists > Public > public-esw-thes@w3.org > February 2005

Re: [PORT] progress update

From: Dan Brickley <danbri@w3.org>
Date: Fri, 4 Feb 2005 08:24:43 -0500
To: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>
Cc: public-esw-thes@w3.org
Message-ID: <20050204132443.GH10697@homer.w3.org>

* Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk> [2005-02-04 12:22-0000]
 
> Two things I could really do with your advice on:
> 
> 1. What to do about the SKOS Core 'Collections' vocab (see http://www.w3.org/2004/02/skos/core/guide/2004-11-25.html#seccollections).  I think the design of this bit is OK for the moment (do you?) but I am concerned that the term 'Collection' is overloaded - there are 'RDF Collections' which means RDF lists, and there are 'museum/library collections' which means repositories of stuff, both different from what is intended by a 'skos:Collection'.  
>

Tricky re terminology. People may well ask why we didn't simply use
RDF's existing structures. My advise is simply to note this as an issue 
and get the spec out as a Working Draft for proper review. Can always 
change later. 

The rules stuff is interesting btw. I was wondering if skos:narrower
etc semantics over collections could be done simply with OWL and 
transitivity etc., if Collection were a subclass of Concept, so
collections were concepts (are they?).

> I was thinking to change the names of these properties, do you think this is a good idea?  What could we call them?  
> 
> I thought of 'skos:ConceptGroup' instead of 'skos:Collection' and 'skos:groupMember' instead of 'skos:member' etc.  
> 
> Stella has suggested 'skos:Array' instead of 'skos:Collection', because the new BS thesaurus standard  calls these things 'arrays of concepts', and it would be nice to be in line with BS as much as poss.  But I'm concerned that 'array' has a specific meaning to compscis which is a bit different.  For 'arrays of concepts' sometimes the ordering is meaningful, and sometimes it isn't, whereas to compscis an 'array' is always an ordered set.  Anyway, what do you think?

Yes, array seems very software-oriented terminology. Is ordering important?
The current collections don't look ordered. How is order preserved? You
say "sometimes the ordering is meaningful" but I don't see any order in
the graph...


> 2. URIs in guide examples.  Currently all example concept URIs are of the form http://www.example.com/something#concept - because this URI form is a compromise between the folks who say you must use hash URIs, and the folks that want each concept URI to be able to de-reference to a different representation.  Tom B is concerned that this type of URI looks exotic, and we should explain the choice.  I want to avoid discussion of URI form in the SKOS Core guide as much as poss.  Should we just revert to example URIs of the form http://www.example.com/somescheme#something for now?


How about... just a sentence or so recording this as an open issue, one that is
orthogonal to the SKOS vocab design but important for implementors, and
that is related to practical deployment questions. Cite TAG
http-range-14 issue and WebArch REC, at least.

This is a can of worms. The best thing we can do to progress it, I
think, is to have a doc out there for review and feedback. We could ask 
TAG to review it, once published as a WD.

> Also I wrote a new introduction, see http://www.w3.org/2004/02/skos/core/guide/2005-01-25.html ... what do you think?

Looks good :) Nitpics follow:

s/SKOS family of standards/SKOS approach/   (we're not a standard yet,
amongst other things).

s/SKOS Core is a model/The SKOS Core provides a model/

I think we need a sentence or two on the relationship with RDF here.
Do you have that elsewhere we could borrow from? The relationship is 
pretty subtle, given that RDFS/OWL also capture conceptual schemes...


[[
SKOS Core is an extension of the RDF model [ref], which is in turn an
extension of the graph data model [ref]. For an explanation of these
concepts, please refer to [ref]. The reader of this guide should have at
least a basic understanding of the RDF model and the graph data model.
]]

This needs a little rewrite. The term 'RDF model' is unfashionable, 
post-RDFCore. It used to mean, roughtly, 'graph data model', but 
now evokes Model Theory etc. SKOS isn't a 'semantic extension' to the 
RDF model theory; this wording could give the impression it is. 

How about:

[[
The SKOS Core is an application of the Resource Description Framework
(RDF). RDF provides a simple data formalism for talking about things, 
their inter-relationships, categories ("classes"), and properties. 
See [RDF Concepts] for an overview of RDF, [RDF Semantics] for its formal mathematical 
basis, and [RDF Syntax] for details of the RDF/XML document format 
used to exchange descriptions of things in RDF. It can be useful to
understand the subtle, layered relationship between SKOS and RDF, 
particularly when building applications that combine SKOS data with
other information modeled using RDF.

In purely technical terms, SKOS is an RDF vocabulary (specified using RDFS/OWL);
a vocabulary that specialises in describing abstractions it calls 
'Concepts' and various of their properties and relationships. 

In more social terms, SKOS provides an encoding for data structures that 
are in the <em>Thesaurus</em> tradition. There are two main ways in which 
thesaurus-like data can be represented using RDF. The (non-SKOS) approach which
makes the most use of RDF and OWL features is to create a new 
RDFS/OWL vocabulary that captures the contents of the thesaurus. Since 
RDF is based on a "classes, instances and properties" modeling style, 
the translation of a thesaurus into an RDF vocabulary can be a major 
undertaking, particularly for large and/or informal thesauri, or those  
whose concept structures don't map clearly into "native RDF". An 
alternative approach is to use RDF, but to use RDF to describe the thesaurus 
itself. This is the SKOS approach. Technically, it creates an extra 
layer of indirection, so that from the RDF point of view we are 
describing things such as 'The concept of Economic integration', rather 
than <em>Economic integration<em> itself. @@a more instance-oriented eg
would be useful here@@        A SKOS representation of a thesaurus 
maps fairly directly onto the data original structures, and can 
often be created without expensive re-modeling and analysis.
As an application of RDF, SKOS concept descriptions share RDF's 
standard XML representation, and can be mixed, merged and queried 
with any other RDF data. However, because SKOS introduces its own 
notion of categorization hierarchies, represented in terms of relationships 
amongst named SKOS concepts, SKOS does not fully exploit all the 
representational facilities of RDF, RDFS and OWL. [brief OWL example here?] 
SKOS is intended to provide both a stable encoding of thesaurus data 
within the RDF graph formalism, as well as a migration path for exploring 
the costs and benefits of moving from thesaurus-like to RDF-like modeling 
formalisms.
]]


OK that's kinda rambling and too long for that bit of the doc, but 
maybe you can butcher it, or use elsewhere? 

I think it's important to say something like that up front...

I see you took out "SKOS Core is not an XML syntax for concept
schemes.", which makes sense; I guess what I was trying to do above
was give people some tools for thinking about what SKOS is, as 
well as what it is not. But it's v hard to do :(

cheers,

Dan
Received on Friday, 4 February 2005 13:24:43 GMT

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