Re: a bnode URI scheme?!

hmm, i think my imprecise use of the phrase "not equal" caused the 
confusion -- to further clarify: 

URI nodes can never be removed from an RDF model without losing 
information (hence intensional). However bNodes, which are just 
asserting "there exists something with these properties",  can be 
removed without losing information if something else with the same 
extension is added to the model. (Since something else with these 
properties now exists in the model its redundent to say "there exists 
something with these properties"). Thus replacing a bNode with a URI 
reference is changing the meaning of the model and introducing URIs 
whose equivalence with other URIs can only be determined by a higher 
level semantics (such as OWL) in the context of a particular schema that 
must be known a priori. 

But if they stay bNodes we don't need to resort to this, RDF semantics 
will determine their equivalency without any need of a schema -- for 
example, collapsing a non-lean graph to a lean graph would remove the 
redundant nodes.

-- adam

Sandro Hawke wrote:

>>Consider the address bnode example in the RDF Primer 
>>There may be times when you want to reference that address externally 
>>(e.g. from another model) but the common sense approach to enable that 
>>by just replacing the bNode with a URI reference has a couple of problems:
>>* it changes the meaning of the model: bNodes serve as existential 
>>variables -- if you replace two distinct bNodes x and y with 2 different 
>>URIs you are adding information to the model: because there is nothing 
>>in the model that says x and y might not be equal but the two URIs that 
>>replace are indeed not equal (since RDF uses intensional semantics for 
>Not true.   
>I think you're saying 
><a> <b> <c>.
><d> <e> <f>.
><a> owl:differentFrom <d>.
>... but I really don't think that's the case.  Can you find some
>supporting text?
>(My recommendation: bNodes are a real pain to reason about, so avoid
>them unless doing so is an even bigger pain.)
>       -- sandro

Received on Friday, 12 March 2004 00:18:03 UTC