RE: Broader, collections and the difference between SKOS and OWL

Stella:  Thank you very much for the thoughtful reply below, and great 
clarification on the underpinnings and goals of SKOS.  This was very 
helpful, that is -- to not be too stringent.  Although I do have concerns 
about problems that may arise when trying to achieve interoperabilty. 
Even so... I like what you are saying.  I like the spirit behind it all.

Mikael:  Thank you very much also for your other email re: the theoretical 
model.  As always, you make excellent points. ;)

All:  I regret that I had to sign off this list (a few weeks ago, after 
being stimulated and wanting to get into the mix of the discussion).  I'm 
dealing with immense email overload.  This is just how it is right now, as 
I face a series of looming deadlines.  Also, please note I have a new 
email address (janeg@email.unc.edu).

If someone wanted to share my post with the SKOS list, great, because I 
cannot reply directly now, with my old address.

Finally, wo la la... to all SKOS folks, please consider attending 
DublinCore 2008, in Berlin Germany (http://dc2008.de/)

All good wishes and peace!

jane

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jane Greenberg, Francis Carroll McColl Term Professor,
and Director of the Metadata Research Center <MRC>
School of Information and Library Science
University of North Carolina at Chapel Hill
CB #3360, 205 Manning Hall
Chapel Hill, North Carolina 27599-3360

Email:        janeg@email.unc.edu
Tel.:         919-962-8066; fax.: 919-962-8071
Web:          http://ils.unc.edu/~janeg
<MRC>:        http://ils.unc.edu/mrc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



On Tue, 19 Feb 2008, Stella Dextre Clarke wrote:

>
> Jane Greenberg asked:
>> Is not SKOS grounded, at least to some degree, in thesauri standards,
>> such as Z39.19, ISO 5964, ISO 2788..and general controlled vocabulary
>> practices of for named entity systems? (Doris Clack is a genius
>> here.)
>>
>> If not, why not?  My understanding is that these standards
>> have played a
>> role in the development of SKOS.
>
> Yes, SKOS was guided by these standards and particularly BS 8723-2,
> which all relate to thesauri. However, it also has ambitions to enable
> data exchange with other types of vocabulary, such as taxonomies,
> classification schemes, subject heading schemes and even folksonomies.
> These different vocabulary types have different approaches to
> hierarchical linkages. It is hard to satisfy all of them at once. In
> other words, you have to drop some of the constraints on strict
> hierarchical relationships - just accepting that whatever the vocabulary
> editor set up should be accepted without question.
>
> The tension between imposing strict semantic constraints and trying to
> serve everybody comes up again and again in the discussion list. For
> example, here's part of an exchange between myself and Antoine Isaac a
> few weeks ago, on ISSUE 44 (BroaderNarrowerSemantics):
>
> Stella:
>> 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!
>>
> Antoine:
> "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
> thing.
> 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.
>
> Best,
>
> Antoine"
>
> Well, I'm usually just a lurker on this list. But it's intriguing to see
> how this conundrum keeps recurring. Hopefully time will show how well
> the evolving solutions cope with real use cases. BTW, you can see the
> basic model for BS8723 in UML at http://schemas.bs8723.org/, latest
> version at http://schemas.bs8723.org/2008-01-08/Documentation/Home.html
>
> Enjoy it,
> Stella
> *****************************************************
> Stella Dextre Clarke
> Information Consultant
> Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
> Tel: 01235-833-298
> Fax: 01235-863-298
> stella@lukehouse.org
> *****************************************************
>
>

Received on Sunday, 16 March 2008 17:50:28 UTC