- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Mon, 08 Dec 2003 14:56:29 +0000
- To: "Miles, AJ (Alistair) " <A.J.Miles@rl.ac.uk>
- Cc: "'Danny Ayers'" <danny666@virgilio.it>, Steve Cayzer <steve.cayzer@hp.com>, public-esw-thes@w3.org
Hi Alistair,
> Can I reduce the problem to the following stages:
>
> Stage 1: Agree RDF encoding for 'traditional' mappings.
>
> Stage 2: Agree RDF encoding for 'ordered' mappings.
>
> Stage 3: Agree RDF encoding for combined ordered + traditional mappings.
>
> ?
I guess. Though one approach to prioritizing the mappings would be to add
priority or distance metrics to the "traditional" mappings (i.e. skip stage 2).
> Having a crack at stage 2, would something like the following be sufficient
> [option 1] ...
>
> <rdf:Description rdf:about="#A">
> <soks-map:orderedMapping>
> <rdf:Seq>
> <rdf:_1 rdf:resource="#B"/>
> <rdf:_2 rdf:resource="#C"/>
> <rdf:_3 rdf:resource="#D"/>
> <rdf:_4 rdf:resource="#E"/>
> </rdf:Seq>
> </soks-map:orderedMapping>
> </rdf:Description>
>
> ... ? I mean does this fall foul of Steve's numbering problem, or is it
> simple enough for the numberings to be redefined if another concept is to be
> inserted into the list?
The critical thing here is how semantic *webby* you are trying to make
things. If all the orderings are defined in a single mapping file then this
is a perfectly reasonable way of representing order (though I still prefer
parseType="collection" as you suggest below). However, in a semantic web
application you might want to be able to merge mappings generated by
different sources. In that case you have no way to merge the Seqs.
> Or am I right in understanding that if you use the attribute
> parseType="collection" on a property, the ordering of the members is
> preserved when the serialised statements are compiled into a graph?
Yes.
> So then
> the following would also do the job (and dodges the numbering
> problem)[option 2] ...
>
> <rdf:Description rdf:about="#A">
> <soks-map:orderedMapping parseType="collection">
> <rdf:Description rdf:about="#B"/>
> <rdf:Description rdf:about="#C"/>
> <rdf:Description rdf:about="#D"/>
> <rdf:Description rdf:about="#E"/>
> </soks-map:orderedMapping>
> </rdf:Description>
Does the job - yes.
Preferable over Seq (IMHO) because it makes it clear that this is a closed
list and some application-specific logic will be needed to perform merging
of multiple orderedMappings.
Dodges the numbering problem - no. It makes the problem clear but it
doesn't dodge it. Fine in a closed system, possibly problematic in an open
system.
An alternative would be to define a semanticDistance relation and derive
ordering from that:
#A soks:semanticDistanceFrom [
a DistanceMetricUsingAlgorithmFooBar;
soks:mappedConcept #B;
soks:distance 4.67^^xsd:float;
soks:baseRelation soks:narrowerTerm] .
That way you can still capture inclusion information such as narrowerTerm
but can order the mappings by distance for any mappings which uses a
consistent metric and so can merge multiple mappings together. In practice
these distances might often be heuristically derived (i.e. guessed) and so
not strictly comparable but at least you have more flexibility. In some
applications you could, in fact, define real combinable metrics - for
example, based on a database of past user query terms and desired results.
[BTW I didn't think very deeply in constructing that example. There are
lots of small design choices. You could make the baseRelation a super
property of the semanticDistanceFrom property rather than an attribute of
the reified representation. You could replace soks:distance by a property
specific to the distance algorithm rather than rely on the type of the
reified relation to carry that information.]
Just a thought.
Dave
Received on Monday, 8 December 2003 09:57:35 UTC