RE: [PORT] new editor's working draft of SKOS Core Vocab Spec

Hi all,

So an interesting case is the comment on the skos:prefLabel property [1] which says:

'No two concepts in the same concept scheme may have the same value for skos:prefLabel in a given language.'

This is one of the few places where SKOS Core makes a recommendation wrt best practice in construction/design of a concept scheme.  We've previously avoided doing this for the reasons that Mikael so clearly describes below.

This 'constraint' comes directly from the thesaurus tradition.  However, what's interesting is that new styles of user interaction, mediated via computer systems with graphical user interfaces, is challenging the absolute necessity of this constraint. One example I saw recently was the 'metadata++' presentated by Marianne Lykke Nielsen at NKOS 2005 in Vienna [2], where effectively multiple concepts are allowed to have the same preferred lexical label, and meaning is disambiguated by the semantic (hierarchical) context of the concept.

This is very similar to e.g. DMOZ, where the categories...

Society: Religion and Spirituality: Christianity: Music
Arts: Television: Programs: Music
Games: Video Games: Music

... are obviously quite different, but all could be modelled as concepts with the same preferred lexical label 'Music'.

What I've started to explore recently, and what I want to discuss as part of the next review, is the use of SPARQL queries as a way of 'testing' whether an RDF data set 'conforms' to certain specified limitations on the graph pattern.  This gives publishers of RDF data a way of running 'quality checks' on RDF data before they publish it.  

E.g. you could use the SPARQL query:

PREFIX schemarama: <http://www.example.com/danbri-lets-coin-this-namespace#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
CONSTRUCT
{
  [] a schemarama:Warning;
    rdfs:comment 'Culprits have identical values for property skos:prefLabel and are in the same concept scheme.';
    schemarama:culprits (?x ?y);
    schemarama:implicated (?l1 ?l2 ?s);
}
WHERE
{
  ?x a skos:Concept;
    skos:inScheme ?s;
    skos:prefLabel ?l1.

  ?y a skos:Concept;
    skos:inScheme ?s;
    skos:prefLabel ?l2. 

  FILTER ( (?x != ?y) && (?l1 = ?l2) && (lang(l1) = lang(l2) )
}
 
This is based on the 'schemarama' work done by Libby Miller and Danbri a while ago [3].  

This query could be part of e.g. a thesaurus-like profile, where actually you would want to generate an 'Error' rather than a 'Warning'.  

What I'd like to do for the next (third) review is to write up a 'basic' schemarama-like profile for SKOS Core using SPARQL tests like the above, where e.g. violation of the prefLabel constraint would generate a 'Warning', but other things like discovering circularity in the skos:broader closure would generate an 'Error'.  I mean to write this up asap for further discussion.

That's all for now, cheers,

Al.



[1] http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20050510/#prefLabel
[2] http://www2.db.dk/nkos2005/Nielsen_Weaver_mfl.pdf
[3] http://swordfish.rdfweb.org/discovery/2001/01/schemarama/

> -----Original Message-----
> From: Mikael Nilsson [mailto:mini@nada.kth.se]
> Sent: 09 October 2005 21:30
> To: Stella Dextre Clarke
> Cc: tiago.murakami@itau.com.br; Miles, AJ (Alistair); 'Dan Brickley';
> public-esw-thes@w3.org
> Subject: Re: [PORT] new editor's working draft of SKOS Core Vocab Spec
> 
> 
> 
> 
> Stella Dextre Clarke wrote:
> > I share the reservations expressed by Tiago and Sue Ellen Wright. My
> > worry is that a jack of all trades tends to be master of 
> none. Trying to
> > meet everyone's objectives with one tool may reduce the 
> effectiveness of
> > the tool for the core jobs it should be designed for.
> 
> I must say I do not share your worries, and for a simle 
> reason - SKOS is 
> an enabling technology, not a policy standard. SKOS allows for the 
> *expression* of certain kinds of information structures - but 
> it wisely 
> avoids policy questions of the kind:
> 
> * how permanent/controlled should terms be?
> * how disjoint should terms be?
> * how should vocabularies be revised?
> 
> etc.
> 
> SKOS will let you use the policy that fits your use case. Saying that 
> SKOS would fail because it allows too many scenarios would be 
> similar to 
> claiming XML is doomed to failure because it allows many kinds of 
> validation, support different forms of extensibility, etc. 
> Just as each 
> XML language would specify what kinds of extensions are allowed, each 
> SKOS concept scheme will specify what policy rules it 
> follows. It's just 
> a technology.
> 
> So I do agree that folksonomies, at least the kind where "categories" 
> are more that just plain keywords, could/should use SKOS, and SKOS 
> should support that (through not caring about policy).
> 
> /Mikael
> 
> 
> -- 
> Plus ça change, plus c'est la même chose
>

Received on Monday, 10 October 2005 13:50:46 UTC