- From: Graham Klyne <GK-lists@ninebynine.org>
- Date: Fri, 14 Dec 2012 20:15:33 +0000
- To: Hugh Glaser <hg@ecs.soton.ac.uk>
- CC: Lee Feigenbaum <lee@thefigtrees.net>, Pat Hayes <phayes@ihmc.us>, David Booth <david@dbooth.org>, semantic-web Web <semantic-web@w3.org>
On 14/12/2012 11:16, Hugh Glaser wrote: > Hi Lee, > Great set of questions (my reformatting to make response easier). > I too would love to see peoples' answers. > I don't think I have seen a response - any takers? I'll bite: > On 13 Dec 2012, at 14:41, Lee Feigenbaum <lee@thefigtrees.net> wrote: > >> On 12/13/2012 2:00 AM, Pat Hayes wrote: > <snip> >>> And that is exactly what blank nodes are for, so I would like to use them to do that. >> >> What is the value of using a blank node here rather than minting an arbitrary URI? >> Is there inherent value in using something because that's what it was designed for? > >> Is there a property of blank nodes that you need that URIs don't have here? Yes - they're drop-dead easy to use (i.e. to generate). >> Is it the cost of minting an arbitrary URI? Yes - there are many situations I come across (code for generating RDF snippets from existing data comes to mind) where being required to generate a unique URI would be a royal PITA. Enough so to put me off using RDF in such circumstances. >> Is it the potential cost of having two URIs for the thing sometime down the road? Not really. In this respect, in my experience, it can be better to use URIs even if there are multiple URIs for a concept that get generated. Practically, when importing blank nodes into an environment which needs a clearer notion of node identity, generating unique URIs seems to be the way to go. (In the past, I've encountered difficulties with scoping of bNodes in inference environments which are easily resolved by replacing them with UUIDs or some suchlike.) >> Something else? Indirectly, the potential cost for having the same URI used for different things -- this is second order effect which could be very damaging, and it's the cost of avoiding it that underpins my previous responses. #g --
Received on Sunday, 16 December 2012 13:14:12 UTC