W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2008

Re: [SKOS]: [ISSUE 44] BroaderNarrowerSemantics

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Sun, 13 Jan 2008 23:26:53 +0100
Message-ID: <478A902D.7050608@few.vu.nl>
To: Stella Dextre Clarke <sdclarke@lukehouse.demon.co.uk>
CC: public-swd-wg@w3.org, public-esw-thes@w3.org

Hi Stella,

> 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.

It seems that our discussions on SKOS indeed bounces back very 
regularly, cf [1], its premises as well as the answers it got
[1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0020.html
I had kept your mail in mind during the holiday, and now it seems right 
the time to give (again) my own opinion (which could actually have 
changed a bit over the past months months, precisely thanks to all these 

> 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
> says:
> "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!

To me SKOS is really intended to be the common denominator for a number 
of approaches to create KOSs, mainly for the KOSs intended as 
(conceptual) languages for description and retrieval: thesauri, etc.
As such, there are two options envisioned, as you recall it:
- keep basic, and present a model that allow to represent the 
fundamental features recurring in these approaches, even if to represent 
them on a quite superficial level (with limited semantic definitions);
- be extensive: offer modelling features as well as semantic constraints 
that fit each of these different approaches (which might be a bit what 
Ceri hinted at in [2])

I would follow the first option, and would like to emphasize (and 
propose to discussion) the two following reasons for it:
1. SKOS is for the semantic web, and it should therefore present simple, 
and, importantly, pragmatic approach for KOS representation. Perhaps 
some people around here will find it debatable, but I think SKOS should 
for instance accomodate the representation of Wikipedia categories [3] 
in SKOS, without having to spend years on re-structuring the complete 
2. SKOS shall not enter in a competition with all kind of initiatives 
that are currently running, and whose aim is to carefully define and 
give guidelines for the design of precise KOS categories, e.g. BS 8723. 
SKOS has to be compatible with the models these initiative build, this 
does not mean that it has to represent all what the corresponding models 
are up to.

Indeed that implies the opposite: if we want to be compatible with these 
different approaches (that is, if e.g. BS 8723 want to define its 
thesaurus model as an extension/refinement of SKOS, which is how it 
should be done, I believe) we have to be very careful with the semantic 
conditions we introduce.
It might be frustrating (and most of the time it is for me), because it 
results in an ontology that is more lightweight than what was thought of 
initially. But I think we cannot really avoid that, that's an inherent 
part of this "let's design a semantic web standard" game.



[2] http://lists.w3.org/Archives/Public/public-esw-thes/2008Jan/0015.html
[3] http://en.wikipedia.org/wiki/Wikipedia:Categorical_index
Received on Sunday, 13 January 2008 22:27:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:09 UTC