Hi all,
Alasdair wrote:
> Aida wrote:
>>
>>> 1. Indexing: How do you encode the statement "Person <P> indexed
>>> resource <R> with concepts <C1> and <C2>"?
>> IMHO this has nothing to do with SKOS or with vocabulary as such.
>> In all systems that I know of, this information is normally encoded
>> in meta-metadata - or administrative metadata. It is not part of
>> vocabulary or resource. These meta-metadata hardly have any value
>> outside local system scenario and many cataloguing agencies never
>> export it or include it in the process of information exchange. You
>> have to come up with some good argument why this information would
>> be relevant for resource discovery. Authority of metadata is usually
>> established through institutions not through individuals.
>
> I agree with this point of view: keep SKOS for capturing the generic
> features of the KOS and then allow systems to apply the KOS as they
> see fit. However, indications on how this can be achieved and whether
> any additional machinery are required should be considered, but in the
> end, the document which publishes the KOS should be kept focused on
> that one topic so that it can be easily reused.
Well, then we just don't agree in this point. I think Social Tagging and
Folksonomies show that you cannot divide an indexing vocabulary and its
usage (who indexed what in which context). Looks like we hit a current
research frontier of information science ;-)
Alasdair wrote:
>> As mapping can be done as direct mapping or through intermediary
>> vocabulary (pivot/spine vocabulary) <W>. So this may be published as
>> vocabulary crosswalks <X => W> and <Y =>W>.
>
> I don't think that approach works. In some cases, you will still need
> some way of saying that <A> exactMatch (<B> AND <C>). This is an
> important area which is lacking from the current SKOS reference.
That's the point. And I even think that these case are not just the
exception!
What do you think about the following solution:
The intersection (<B> AND <C>) is a subset of <B> and a subset of <C>,
right? So you can say
<B> skos:narrower (<B> AND <C>) .
<C> skos:narrower (<B> AND <C>) .
The mapping
<A> exactMatch (<B> AND <C>)
can then already be expressed with current SKOS:
<A> skos:exactMatch [
rdf:type skos:Concept ;
skos:broader <B> ;
skos:broader <C>
] .
Furthermore the union (<B> OR <C>) is a superset of <B> and a superset
of <C>. The mapping
<A> exactMatch (<B> OR <C>)
can then already be expressed with current SKOS:
<A> skos:exactMatch [
rdf:type skos:Concept ;
skos:narrower <B> ;
skos:narrower <C>
] .
Isn't that pretty? :-)
Aida wrote:
> 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?
[...]
> 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)
Well, I'll have a look. Personally I find rdf:Bag and rdf:Alt almost as
ugly as reification but maybe it can help.
> 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.
Good point. On the other hand that's an argument to define more precise
semantic instead of just using rdf:Bag/rdf:Alt.
Greetings,
Jakob
--
Jakob Voâ <jakob.voss@gbv.de>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 GÃ·ttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de