Re: Upcoming wave of quad/namedgraph implementations ,was: Reification - whats best practice?

Hamish Harvey wrote:
> Andrew Newman wrote:
> 
>> The main problem we've had with named graphs is that it can be a pain 
>> on a machine that has multiple names or names that change over time.  
>> If I create a models based on machine names called 
>> "http://192.168.10.1/foo" and then move to another network and 
>> suddenly it's "http://10.0.0.42/foo" then all my existing queries stop 
>> working.  I now prefer URNs for models not URIs and add a level of 
>> indirection between them (I think this has been mentioned before).
> 
> Why tie the graph name to a machine? Surely you don't need to go as far 
> as URNs to solve this problem?
> 

The reason people tie a graph name to a machine name is simply because 
it's convenient.

I know that using URNs does require another level of infrastructure. 
You could, although I'm not sure if this is a good solution, map URIs to 
URNs.  For example, the model URI "http://foo.com/server1#bar" becomes 
"urn:foo-com:server1:bar".  When the machine name changes all the 
references on how to access the model change but model names stay the 
same thereafter.

Ideally, you would have an infrastructure that would allow indirection 
of models like DNS does with names to IP addresses.  It can be more than 
DNS though, you could change what's resolved based on a user's 
credentials, for example.  The security credentials, the protocol, the 
host name/IP, query string or any part of the URI should be separate 
from the name of the graph.  I don't think you should change your 
configuration/code/queries just because any of these details change. 
Semantically it's the same data.

Having model names you'll be able to check for things like when was it 
"last updated" and other metadata.  Some of these details maybe have 
been extracted at different levels - application, protocol, etc.  All of 
these details should be offered in a way for your query/application 
logic to check.  Sharing and storing model names and metadata then 
becomes an important function for all clients/servers/peers.

Others have mentioned using URNs to label models including Haystack[1] 
and @semantics[2].

[1] 
http://twiki.mygrid.org.uk/twiki/pub/Mygrid/PresentationStore/LifeScienceIdentifiers.ppt
[2] http://www.asemantics.com/presos/devdays-2004/

Received on Monday, 13 September 2004 00:36:43 UTC