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

On Mon, 10 Mar 2008 at 14:38:02, Jakob Voss <jakob.voss@gbv.de> wrote
>
>Hi Antoine,
>
>ISSUE 40 is related but seems to go further. Some people distinguish 
>"postcombination" and "postcoordination":
>
>postcombinations:
>* holiday, 2008
>* 2008, holiday
>
>postcoordinations:
>* holiday IN 2008
>* holiday BEFORE 2008
>
>I think the second (postcoordination) is too complex, but 
>postcombination should be supported. Mapping to combinations of 
>concepts is just one application but more important is to encode 
>subject indexing with multiple concepts. The order of concepts may be 
>relevant and you surely want to encode additional metadata to subject 
>indexing (who assigned it? when was it assigned?). One solution is 
>reification but this is just terrible.

We have to be careful here about the terms we use, or we will create 
confusion. In normal thesaurus and classification practice, we use the 
expressions:

pre-coordination: meaning that the indexing terms assigned to a resource 
are combined into a structured string (with a defined order and possibly 
some link terms or symbols) at the time of indexing. For example, a 
resource could be given the pre-coordinated indexing string "holidays : 
2008" if the rules for citation order were that activity was cited 
before date.

post-coordination: meaning that when indexing terms are assigned to a 
resource they are not combined in any way.  A resource could be given 
the two independent terms "holidays" and "2008", but without any 
relationship between these being expressed. The compound concept would 
be retrieved if a search was made using the Boolean search statement 
("holidays" AND "2008").

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.

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.

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


>
>In Social tagging a common model is the triple model with resource <R>, 
>tag <T>, and author <A>. There should be an easy way to encode such an 
>indexing triple in SKOS. Thinking about this I found that Semantic 
>Tagging (tagging with concepts instead of labels) could be encoded with 
>skos:Collection. If person <P> tags resource <R> with concept <C>, this 
>could be:
>
>
><R> skos:subject [
>  rdfs:type skos:Collection ;
>  dc:creator <P> ;
>  skos:member <C>
>] .
>
>As said in the last mail this shoul entail
>
><R> skos:subject <C> .
>
>
>Antoine wrote:
>
>> I find the pattern quite meaningful, but am really not sure that
>> using Collections is optimal.
>
>Yes, using skos:Collection could be confusing - one alternative is to 
>create another class like "skos:Combination" - but then you have to 
>redefine skos:member. I find skos:Collection handy.
>
>Greetings,
>Jakob
>
>> -------- 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:
>>   #R skos:subject x:holiday .
>>  #R skos:subject x:y2k8 .
>>  Reification might be a solution but reification in RDF is where the 
>>real
>> problems start, so better avoid it. The second use case is how to map a
>> concept in one vocabulary to a union of two terms in another vocabulary.
>> The early mapping spec [1] contained the classed AND, OR, and NOT but
>> these seem to have faded away (?). OR is not a problem as far as I can
>> see and NOT could be dropped because of complexity, but how do you
>> encode an AND? Given a second Concept Scheme with a concept labeled
>> "holiday2008":
>>   x:h2008 a skos:Concept; skos:prefLabel "2008" .
>>  how do you encode the mapping between x:h2008 and x:holiday together
>> with x:y2k8 ?
>>  The solution I found, seems to answer both questions. First you have 
>>to
>> broaden the rdfs:range of skos:subject, skos:exactMatch,
>> skos:broadMatch, skos:narrowMatch and skos:relatedMatch from
>> skos:Concept to skos:Concept, skos:Collection and
>> skos:OrderedCollection. Second specify the semantics:
>>  <A> skos:subject <C> .
>> <C> a skos:Collection ; skos:member <X> , <Y> .
>>  entails
>>  <A> skos:subject <X> ; skos:subject <Y>
>>  And the same with mapping relations instead of skos:subject and with
>> skos:OrderedCollection instead of skos:Collection.
>>  What does this mean? You can now
>>  1. Map between a concept and and a set of coordinated concepts:
>>  x:y2k8 skos:exactMatch [
>>   a skos:Collection;
>>   skos:member x:holiday ;
>>   skos:member x:y2k8
>> ]
>>  2. Coordinate Concepts into a (sorted) collection and index 
>>resources
>> with this coordinated collection.
>>  #R skos:subject [
>>   a skos:Collection;
>>   skos:member x:holiday ;
>>   skos:member x:y2k8
>> ]
>>  Why is support of postcoordination needed in SKOS? Because without 
>>you
>> cannot specify the set and order of concepts that was used to index a
>> resource! How would you say person <P> indexed resource <R> with
>> concepts <C1> and <C2> at time <T>? With the proposed enhancement to the
>> current draft you can say it without additional classes and properties
>> or even reification:
>>  <R> skos:subject _:x .
>> _:x a skos:Collection ;
>>   dc:creator <P> ;
>>   skos:member <C1> ;
>>   skos:member <C1> .
>>  Actually the statement says "Ressource <R> is indexed with a set of
>> concepts <C1> and <C2> that was created at time <T> by person <P>" - but
>> in practise it's the same.
>>  Greetings,
>> Jakob
>>  [1] http://www.w3.org/2004/02/skos/mapping/spec/
>>   --
>> Verbundzentrale des GBV (VZG)
>> Digitale Bibliothek - Jakob Voß
>> Platz der Goettinger Sieben 1
>> 37073 Goettingen - Germany
>> +49 (0)551 39-10242
>> http://www.gbv.de
>> jakob.voss@gbv.de
>>
>
>

-- 
Willpower Information       (Partners: Dr Leonard D Will, Sheena E Will)
Information Management Consultants              Tel: +44 (0)20 8372 0092
27 Calshot Way, Enfield, Middlesex EN2 7BQ, UK. Fax: +44 (0)870 051 7276
L.Will@Willpowerinfo.co.uk               Sheena.Will@Willpowerinfo.co.uk
---------------- <URL:http://www.willpowerinfo.co.uk/> -----------------

Received on Tuesday, 11 March 2008 12:11:53 UTC