Re: Is there a systematic method for naming bnodes?

On 8 Oct 2010, at 14:06, Melvin Carvalho wrote:

>> If bnodes were given some kind of 'global' name, then they would be essentially the same as URI references. (And in fact, one can always use a URIref rather than a bnode, and write bnode-free RDF. Several authorities have urged this as a good practice, though I disagree.)  It would be analogous to prohibiting the use of words like 'someone' in English, and requiring instead that a name be used, even if the name is coined just for this purpose. A global naming scheme for bnodes would be like a convention that one had to say 'person-<hash-identifier>' rather than simply 'someone'.
>> 
>>> Seems to me you could solve a lot of the problems of RDF with this were the case?
>> 
>> What problems?
> 
> Three problems come to mind:
> 
> One problem is the canonicalization of RDF seriealizations, and hence, ability to sign it with DSIG.  It seems quite hard to canonicalize bnodes, right now.
> 
> Another is referring to data in another graph, say I wanted to annotate, access control, transform etc.
> 
> Another that I was personally trying to solve was an easy way to diff elements in a triple store cross domain, e.g. for sync purpose
> 
> But also it 'feels' like it would make things more elegant, and to my instincts, solve a number of issues that I havent considered.

These problems can be solved, albeit non trivially and at a computational cost, without changing the semantics of RDF. Your proposed solution (global names to bnodes) is not a solution, since you change radically the semantics of RDF, basically by saying that there are not bnodes anymore, but only URIs (and literals). By doing so, the RDF data model would instantaneously become a special case of the relational data model, and SPARQL a dialect of SQL.

> One problem is the canonicalization of RDF seriealizations, and hence, ability to sign it with DSIG.  It seems quite hard to canonicalize bnodes, right now.


You can solve it by using equivalence between graphs under simple entailment, instead of syntactical equality among graphs. This is computationally expensive.

> Another is referring to data in another graph, say I wanted to annotate, access control, transform etc.

Here I don't see the problem: you can still reify triples, even if they contain bnodes.

> Another that I was personally trying to solve was an easy way to diff elements in a triple store cross domain, e.g. for sync purpose

Here you need to extend the notion of syntactic diff to a notion of semantic diff modulo entailment, which is again bound to be expensive in the general case.

Note that *obviously* many problems which are easy in a standard relational data setting will become harder in RDF: we are willing to deal with the *semantic* web rather than the syntactic web: that's the divide.

Personally I believe that this is the real essence of the discussion: many people believe in the truly *semantic* features of RDF, since they represent an advance wrt the relational model, and they form the basis for the semantic web. Other people on the other hand still lack the simplicity of the relational model transposed *on the web*, and they ask RDF to fill this void. They are both legit demands.
The future I see is a fork in the RDF effort: on the one direction, we keep going semantical with RDF and the like, on the other direction we may start a sort of "jdbc-like" effort on the web, with endpoints, RESTful, etc.

cheers
--e.

Received on Saturday, 9 October 2010 09:01:49 UTC