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

On Sat, 2011-03-26 at 17:44 -0500, Pat Hayes wrote: 
> 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, 

No, depending on the requirements, it may be *quite* important.  I
already gave some examples below of useful information that *could* be
encoded into the URI.  We need to collect the requirements and look at
potential solutions before weighing trade-offs.

> and certainly does not need to be known by any consumer of the RDF.

There's a big difference between the consumer *needing* to know about it
and the consumer *desiring* to know about it *if* *possible*.  The
consumer may be able to gain more value by knowing more.  As a simple
example, if the consumer knows that certain URIs are skolomized bnodes,
the consumer may choose to turn them back into bnodes.

>  (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. 

No, that may be true for the use cases that *you* have in mind, but it
may not be true for other people's use cases.  We need to collect the
requirements and look at potential solutions before making assumptions
about what is not needed.

> 
> > 
> > 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.

I agree.  I was not suggesting it be a mandatory standard.

> 
> > 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. 

Well, okay.  But above you said the process is trivial.  :)

> 
> > 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. 

I already gave some examples below, but most useful would be to look at
whatever requirements we collect.

> 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. 

I think people are smart enough to understand the difference.  And it
would be folly to write applications to assume that every resolvable URI
resolves to information about what the URI denotes.  Remember, most
resolvable URIs are to HTML pages -- not RDF.

> 
> > 
> > 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. 

No we wouldn't.  A 303 (for example) can redirect to *any* information.
If that information happens to be the skolomization specification by
which the URI was generated, then so what?  At least it enables the
consumer to find that specification more easily than by searching the
web.

> 
> 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.

The only purpose would be the same purpose of making *any* URI
dereferenceable: it makes it easier for consumers to GET information
that is related to it.  It's a click instead of a web search.  This
"doctrine" is merely the hyperlink, and the web has shown them to be
very helpful indeed.  

David


> 
> Pat
> 
> 
> 
> > 
> > BTW, lest anyone think this would violate the principle of URI opacity
> > http://www.w3.org/TR/webarch/#uri-opacity
> > it would not, because the whole point is that the information would be
> > specifically licensed -- not guessed.
> > 
> > 
> > -- 
> > David Booth, Ph.D.
> > http://dbooth.org/
> > 
> > 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
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 
> 
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 29 March 2011 02:15:49 UTC