[SKOS] ISSUE 77 and ISSUE-40: proposal for postcoordination

Hi Jakob,

Coming back to your real problem.
For pre-coordination for the moment I don't have a definitive 
proposition, but for post-coordination, why don't you use rdf:Bag and 
rdf:Alt [1]? Has it been proposed before?

rdf:Bag intended meaning seems to fit quite well the semantics of AND in 
post-coordination, and rdf:Alt the semantics of OR

For instance your
>  #R skos:subject x:holiday .
>  #R skos:subject x:y2k8 .
would be represented as
#R skos:subject _:z .
_:z rdf:type rdf:Bag .
_:z rdf:_1 x:holiday .
_:z rdf:_2 x:y2k8  .

Notice that this lets application developers the care of handling these. 
But that's a bit what happens with post-coordination anyway.

So what do you think this proposal is usable for you? I do believe it is 
simpler, and appropriately re-uses existing RDF solutions (I think the 
examples given in [1] are really close to what you want to achieve)

Notice we MAY want to assign semantics for this proposal pattern, e.g. 
saying that all the members of the bag are the skos:subject of the 
document. But I'm not sure this actually fits the intended semantics of 
post-coordination. If a document is about a combination of concept in a 
post-coordination-based search system, it is not supposed to be "fully" 
about each concept.

Notice also that I don't have time, but it might be possible to use RDF 
containers for pre-coordination. Maybe more will come in the near future...

Cheers,

Antoine

[1] http://www.w3.org/TR/rdf-primer/#containers

> Hi Jakob,
>
> Your comment is a very valid one.
> Actually there is a closely related issue, ISSUE-40 ConceptCoordination
> Initially it is about pre-coordination, but I do believe that the same 
> representation mechanisms can be used for both problems (at least in 
> an RDF-oriented view)
>
> About the content of your proposal: I find the pattern quite 
> meaningful, but am really not sure that using Collections is optimal. 
> What  I'm afraid of is that in their current uses, Collections are 
> rather interpreted as 'unions' of concepts, while some coordination 
> cases makes me really think of 'intersection'(at least from a boolean 
> query perspective)
> But it may be worthwile to investigate this further...
>
> Best,
>
> Antoine
>
> [1] http://www.w3.org/2006/07/SWD/track/issues/40
>
>
> -------- 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
>
>

Received on Tuesday, 18 March 2008 08:48:41 UTC