RE: [wiki] New: RyansActivities

Hi Ryan

> * Thinking and writing code to address bNode issue in 
> Longwell (likely implementation: faux URIs for blank 
> nodes, some sort of rules addressing 
> owl:inverseFunctionalProperty's and deducing owl:sameAs 
> relationships amongst bNodes)

It's worth talking to Damian about this, apparently this was a problem in
Brownsauce, and although Jena 1 had some classes that helped, they
disappeared in Jena 2 which caused problems when porting. 

I spoke to the Jena folks and there is a method called nodeId (I think??) we
could use, so if a node is bNode, no URI, so get the nodeId and use that to
create a property value constraint in Longwell instead. 

While we are on this subject, there seems to be a fundamental difference
here in my approach to modelling, and the approach the FOAF people use. I'm
not sure which is right, there are pros and cons to both approaches, but for
now I just want to note the difference. In FOAF they use bNodes, whereas I
really dislike bNodes, I give a URI to everything with some provisos:

- everything unique "thing" in a dataset must have a unique URI
- things that look the same from different datasets get different URIs
- we can always make the URI retrievable at some later date using a server
like Joseki
- if we give different URIs to the same thing, we can always map them
together later using owl:sameAs

As we've found, if you give things URIs, it makes query easier. However
owl:sameAs isn't quite the same as smushing, it has potentially much higher
overheads - we get a lot more statements when we run the inferencer. So I
guess there are some fundamental modelling questions here: when should you
use a bNode, and when should you create a URI? And when should you smush,
and when should you use owl:sameAs? 

Comments?

Dr Mark H. Butler
Research Scientist, HP Labs Bristol
http://www-uk.hpl.hp.com/people/marbut

Received on Wednesday, 5 May 2004 09:25:39 UTC