Re: About computer-optimized RDF format.

On 25 Jul 2008, at 13:59, Harry Halpin wrote:
[snip]
> It seems the URI-based graph-merger is the best (and perhaps  
> *only*) selling point of RDF in comparison with say, normalizing  
> XML and OO XML Schema extension.

I'm not sure it's so dire, but I think one has to be clear on the  
exact nature of the use cases.

> Is that in terms of XML vs. RDF for data integration - not queries  
> etc. - addressed anywhere?

The closest I've seen is talking about RDF having a notion of objects  
and OID. That *is* a constraint which has some advantages.

But note that this is pretty specialized, in some sense. I.e., I  
think it *is* a win if you are collecting property/values about  
identifiable objects. RDFS is also often a win if you have a simple  
hierarchy of such objects. See:

	http://clarkparsia.com/weblog/2006/09/17/the-svg-argument/

for a variant of that argument.

RDF is a clear loser for syntax for almost exactly this reason (and a  
whole slew of others). Having to name all your intermediate forms,  
the lack of context for uses of URIs, the lack of validation, the  
semantics of bnodes, the unstructuredness of the sea of triples, the  
weirdness of XMLLiterals, etc. etc. make it a really really bad tool  
for syntax.

> As someone who does some data merger, I used to do it in XML via  
> XSLT, and now I just move things over to RDF after a process of  
> "URI normalization" - i.e. making sure we use the same URIs as  
> keys. I'd like to hear about other people's experiences here.
[snip]

It would be interesting to know more about the sorts of data and  
integration tasks you have and whether it has certain characteristics  
that make it well suited for this. If so, that would make a nice  
little decision tree.

Cheers,
Bijan.

Received on Friday, 25 July 2008 13:17:01 UTC