W3C home > Mailing lists > Public > public-esw-thes@w3.org > December 2003

Re: RDF ordering questions

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Mon, 08 Dec 2003 14:56:29 +0000
Message-ID: <3FD4911D.5080300@hplb.hpl.hp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:51 GMT