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

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

Presumably, the entire reason for *standardizing* a way of skolomizing
bnodes is 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.)  

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.  

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.

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.

Received on Saturday, 26 March 2011 14:25:07 UTC