XML, RDF, Topic Maps, and naming things with URIs

Mark Baker posted a very small, very simple example of why you get more from RDF for cheap than you do from XML.

Both links from the comments at Sam Ruby's weblog, an informative dialog from some knowledgeable people. It covers some ground, getting into the issue of merging when identity is defined by the triples a node participates in rather than the URI of the node and the issue of using the URI of an addressable resource to indicate a non-adderssable resource where Topic Maps, I believe, have RDF beat by building merging rules of this type right into the standard and by clearly distinguishing between URI-as-address-of-resource, and URI-as-indicator-of-topic.

Those two things together has brought something slightly better into focus for me. FOAF uses blank nodes to represent people, and identity is based on the email address of a person (or the SHA1 checksum of that email address). That means that simply asserting triples from multiple FOAF graphs into one graph will not result in a properly merged graph, as there will be multiple blank nodes referring to the same person.

In return, it also means that there is no need to come up with some reliable mechanism for referring to people using URIs; that's the bit I hadn't noticed properly before.

It seems to me that RDF could really do with a standard way of dealing with this merging process. The pattern is going to be repeated over and over, and asking every application developer to deal manually with this merging for every vocabulary in which it is necessary aint good enough. But recognising the situations in which such merging is necessary is non-trivial, since RDF has no notion of a subject indicator. Could it be schema driven?

Comments

[Antoine Zimmermann]

This is typically the kind of problem I am dealing with for my Master's thesis. I am working on RDF merging under constraints (such as one email address corresponds to a unique person). I am actually studying merging in the case of bibliographic data (in RDF), with constraints defined as an ontology in OWL. Through this study I try to highlight recurrent problems which could be easily coded in a description language. If you have any information about this topic, or any question about my work, please send me an email.

[Hamish Harvey]

I wasn't aware of owl:InverseFunctionalProperty when I wrote this.