Re: Indicating Skolem Nodes (was Re: AW: {Disarmed} Re: blank nodes (once again))

On Mar 26, 2011, at 9:24 AM, David Booth wrote:

> On Fri, 2011-03-25 at 23:05 -0500, Pat Hayes wrote:
>> On Mar 25, 2011, at 10:44 PM, David Booth wrote:
>>> Please, at *least* make it dereferenceable to *some* kind of useful
>>> information.
>> How? These are supposed to be automatically generated and globally
>> unique. Will you have the skolemizing process also generate a web page
>> somewhere, one for each skolem constant? 
> No, you're missing my point.  I'm not talking about millions of
> auto-generated pages.  I'm talking about information about the
> skolomization process *itself*.  In the very least, the URI could point
> to the skolomization *specification* that was followed in generating
> it.  

But this is trivial. The process is, replace each bnode (in a graph) by a unique, newly minted, URI which is warranted (within some bounds of probability, perhaps)  to be distinct from all other URIs. Exactly how this "newness" is achieved is not really very important, and certainly does not need to be known by any consumer of the RDF. (Would you have current URIs somehow display the thought processes of the people who coined them? 

The point is that these URIs will be almost as blank as the blank nodes they replace. Ideally they should be *exactly* as blank, if that were possible. 

> Presumably, the entire reason for *standardizing* a way of skolomizing
> bnodes i

I dont think we should make this normative. What we should do is to provide one way to achieve this, so that people can use it off-the-shelf. But if someone wants to invent another way, good luck to them.

> s to permit RDF consumers to syntactically *recognize* those
> URIs as being skolomized bnodes and potentially do something special
> with them.  (Otherwise generators could just use whatever process they
> wanted, and there would be no need for us to discuss it.)  

There is a need to discuss this idea of being "new" and how to ensure it globally, if only to make it vividly clear that it is not enough to just grab some random URI and use it, or to re-use the same URI over and over, or other disastrous but cheap apparent short-cuts. 

> Hence, it would be helpful to give the RDF consumer who comes across one
> of these special URIs the *option* of easily derefererencing it to learn
> how it was generated and what information can be reliably concluded
> about it by syntactic inspection.  

I really cannot see the need for this, or even what it would consist of. And having these URIs resolve to information about the algorithm used to generate the URI, while other URIs resolve to information about what the URI is supposed to denote, would only produce confusion, IMO. 

> There are many possibilities for what this information might include,
> some of it mentioned already, such as:
> - The fact that this *is* a skolomized bnode URI.
> - The datetime when it was generated.
> - Who generated it.
> - What algorithm was used.
> This is similar to the idea of having an XML namespace document be
> dereferenceable to information about that namespace, although in this
> case the information would be about the URI itself rather than being
> about the thing that it represents semantically in an RDF graph.

Right, and this difference seems rather important. We would be embodying a use/mention ambiguity into the heart of URI meanings. Blech. 

And I can't see that this would have any purpose, other than to be in accord with a kind of doctrine about URI resolvability.


> BTW, lest anyone think this would violate the principle of URI opacity
> it would not, because the whole point is that the information would be
> specifically licensed -- not guessed.
> -- 
> David Booth, Ph.D.
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of his employer.

IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile

Received on Saturday, 26 March 2011 22:44:42 UTC