W3C home > Mailing lists > Public > public-swd-wg@w3.org > March 2008

Re: ISSUE 77 and postcoordination [and ISSUE-40!]

From: Stella Dextre Clarke <stella@lukehouse.org>
Date: Fri, 14 Mar 2008 10:51:57 +0000
Message-ID: <47DA58CD.6020406@lukehouse.org>
To: Leonard Will <L.Will@willpowerinfo.co.uk>, public-esw-thes@w3.org
CC: public-swd-wg@w3.org

How well Leonard puts these points. Sorry I've not had time to 
participate in all these conversations, but I'll try to chip in a couple 
of additional points below .

Leonard Will wrote:
> Pre- and post- therefore refer to whether concepts are coordinated 
> before or after the cataloguing of the resource is completed and stored 
> ready for retrieval.
Agreed. And I am therefore puzzled as to why anyone wants to represent 
postcoordination in SKOS. Postcoordination is something we use at the 
time of searching, i.e. postcoordination is applied in the queries of 
searchers, to detect combinations found in the metadata of indexed 
resources.   But it is not part of the vocabulary - any preferred 
term/concept in a thesaurus can in principle be postcoordinated with any 
other preferred term/concept. If SKOS is for publishing/exchanging 
vocabularies, it does not need to do anything about postcoordination.
> The term "postcombination" is not one I have ever come across, and I 
> suggest that it should not be used as it is liable to be misinterpreted.
I've heard Dagobert Soergel maintain that the term "postcombination" 
should be used in preference to "postcoordination", but I have not 
challenged him to explain why. Perhaps it is just because in the 
mathematics classroom the terms permutation and combination are used, 
with no mention of coordination? Anyway, I'm sticking with 
postcoordination (though I'm more flexible about the hyphens that can be 
in it).

> As I understand it, the SKOS use of the term "collection" is for 
> something different altogether. SKOS usage seems to be that "collection" 
> is what in thesaurus practice we would call an "array", i.e. a set of 
> sibling concepts, sharing a common broader parent. This is part of the 
> structure of a controlled vocabulary, and is not related to the 
> assignment of more than one term when indexing a resource.

> Leonard Will
>>> -------- Message d'origine--------
>>> De: public-esw-thes-request@w3.org de la part de Jakob Voss
>>> Date: lun. 10/03/2008 04:22
>>> : public-esw-thes@w3.org
>>> Objet : ISSUE 77 and postcoordination
>>>   Hi!
>>>  I must raise another issue related to ISSUE 77 (skos:subject) about
>>> collections of concepts. How do you encode postcoordination? After
>>> dealing with the encoding of classifications and authority files in SKOS
>>> I am working on a paper on encoding social tagging information with
>>> SKOS. So I stumbled upon the skos:subject property and encoding of
>>> subject indexing.
>>>  I was somehow suprised to see skos:subject missing in the current
>>> working draft (chapter 11.2, issue 77). To my point of view skos:subject
>>> is one of the pillars of SKOS (together with skos:Concept,
>>> skow:prefLabel and skos:broader/narrower). It might be enough to use
>>> dc:subject but then the SKOS recommendation should clearly state the
>>> semantics it implies with using dc:subject.
>>>  In particular I found two related gaps in the current draft. First is
>>> how to encode postcoordination of concepts and second is how to map to
>>> coordinated concepts. Let me give an example:
>>>  Given one Concept Scheme with two concepts labeled "holdiay" and 
>>> "2008":
>>>   x:holiday a skos:Concept; skos:prefLabel "Holiday" .
>>>  x:y2k8 a skos:Concept; skos:prefLabel "2008" .
>>>  How do you encode that fact that a resource '#R' was indexed with both
>>> together in a specific context (person, date, etc.)? You somehow have to
>>> connect two statements:
Why do this in SKOS? Why not leave it to a downstream application?

Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, Oxon, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
Received on Friday, 14 March 2008 15:02:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:50 UTC