- From: Andrew Newman <andrew@tucanatech.com>
- Date: Mon, 13 Sep 2004 10:36:10 +1000
- To: www-rdf-interest@w3.org
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