RE: [SKOS]: [ISSUE 44] BroaderNarrowerSemantics

This correspondence make an uncanny parallel with one that was held just
two weeks ago on the very same lists, only it had different participants
and reached an opposite conclusion. The conclusion, it seems to me,
should depend on deciding "what is SKOS really for?" I'll come back to
that question in a minute.

The context of the earlier discussion was whether prefLabel needs to be
unique in a particular language in a particular vocabulary. It was
pointed out that in a thesaurus (as laid out in ISO 2788 and BS 8723-2,
and ANSI/NISO Z39.19 too) each concept does have to have a unique
preferred term, whereas in a classification scheme there is no such
thing as a preferred term, and the caption does not have to be unique,
but instead the notation has to be unique.  Of course, LCSH is different
again. The different types of vocabulary have good reasons to be
different from each other. And incidentally the key differences are
described in the recently published BS8723-3. Bernard Vatant commented:
> Although 
> I understand the rationale, seems to me that the current trend is 
> towards having SKOS semantics and constraints layer as light 
> as possible 
> in order to extend its scope to any form of structured 
> vocabulary used 
> for indexing, classification, search and retrieval.
> Additional constraints as the one we discuss here are indeed 
> application-specific, and therefore should not necessarily be 
> constrained by SKOS formal semantics, so that different types of 
> specific vocabularies/applications should be able to use the same 
> minimal format. It does not seem in contradiction with the 
> fact that " 
> ... internal constraints/validations when encoding any one vocabulary 
> may need to vary from one type of vocabulary to another".
> All the question is to know if those different types of constraints 
> should be specified by SKOS vocabulary and semantics, or specified by 
> technical annexes such as "Using SKOS for a thesaurus, Using 
> SKOS for a 
> classification scheme, etc" ...  or let to implementers.
The discussion about the semantics of broader/narrower relationships
could go the same way if it wished, because the way these are handled
varies from one type of vocabulary to another.

But what is SKOS really for? If its aim is to provide a single format
that can be used to transmit and receive any type of vocabulary, then we
should adopt Bernard's suggestion. But if the purpose is to enable
simultaneous searches across collections that have been indexed or
classified with a variety of different types of vocabulary, then a more
complex semantic structure may be needed. Allowance needs to be made for
the different ways of handling notations, preferred terms and captions,
as well as the hierarchical relationships. I suppose the allowance could
be made by the search engine rather than in SKOS itself, but how would
that work?

Maybe I've never been sure of what SKOS is for. The SKOS Core Guide
"SKOS Core provides a model for expressing the basic structure and
content of concept schemes (thesauri, classification schemes, subject
heading lists, taxonomies, terminologies, glossaries and other types of
controlled vocabulary)" These vocabulary types have several intrinsic
fundamental differences, and the differences are not about to go away.
If SKOS seriously wants to model the semantics/structure of all of these
in one scheme, it may have to get quite a bit more complex than it is!

Happy Christmas everyone,

Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298

> -----Original Message-----
> From: 
> [] On Behalf Of Ed Summers
> Sent: 17 December 2007 21:29
> To:;
> Subject: Re: [SKOS]: [ISSUE 44] BroaderNarrowerSemantics
> On Dec 17, 2007 4:22 PM, Daniel Rubin <> wrote:
> > Sorry, but I disagree with the suggestion that people define 
> > transitivity for themselves. SKOS should not leave such things 
> > undefined--to do so guarantees people will have different semantics 
> > for SKOS properties which will prevent interoperability.
> I appreciate this point Daniel. Can you provide a concrete 
> example of how interoperability would be disrupted?
> //Ed

Received on Tuesday, 18 December 2007 10:03:49 UTC