Re: Subjects as Literals

On 7 Jul 2010, at 04:23, David Booth wrote:

> On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
> [ . . . ] 
>> foaf:knows a rdf:Property .
>> 
>> Well we can dereference foaf:knows to find out what it means. This is
>> the canonical way to find it's meaning, and is the initial procedure we
>> should use to arbitrate between competing understandings of its meaning.
> 
> Right.  The document you get upon dereferencing -- the "follow your
> nose" document -- acts as a URI declaration.[1]
> 
> 1. http://dbooth.org/2007/uri-decl/ 

Yes, very interesting and useful paper. 

I can't say if I agree with all of it yet, as I would have to read it more carefully.  But I think reflection in this space is very much needed. 

A few notes. 

You use the word "URI" a lot in your paper, but I am not sure all URIs have a dereferencing mechanism. What is interesting about your paper is that it points to a reason for why this is really important part of a URI.

It would be interesting to make the case in terms of the Fregean Sense/Reference distinction. I have used that to explain "How does Secure Authentication Work with FOAF+SSL?" in the FAQ

  http://esw.w3.org/Foaf%2Bssl/FAQ

On the sense reference distinction, I think people tend to forget that in the semantic web, every URI we use is a relation between a string and a thing, intermediated by the sense.

  We could make this clear by creating the reference relation, perhaps log:reference
which would relate a URI string to the thing.

  <http://bblfish.net/#me> owl:sameAs "http://bblfish.net/#me"^^log:reference .

this makes it clear that the <...> notation is just the shorthand for the literal notation to the right, which if thought of this way, suggests we have been using literals in subject position all the time ;->

  So what is log:reference do? Well it is the relation that gives the reference of an object. But how does anyone come to know the procedure for finding the reference? (This is a very Michael Dummett like question). If there is no way to find the sense of a word, if there is no thing to learn that counts as knowing it, then there is no way of being right or wrong about its use. And so the word has no meaning. 

  In everyday human life for millennia there have been certain skilled user of a word, masters of the vocabulary, that are final arbiters of the words meaning. This has to be true in the semantic web too, but we need more mechanical ways of finding the sense.

  So to repeat: the log:reference has to be a relation that links the name to the referent via the sense. Since it is tying a string to a thing, it has to get going on information from the URI string. The only way of doing that is getting that string's log:semantics: ie dereferencing that string using the canonical method for dereferencing that URI given its scheme. A http URL is dereferenced using the HTTP scheme, a ftp url using the ftp scheme, https using http and TLS, etc.... 

   The document returned has to be interpreted giving us its log:semantics. Perhaps it would be more helpful to have the canonical semantics relation (and perhaps this is what named graphs are?)

   "http://bblfish.net/#me" log:canonicalSemantics #at a time?
               { :me a foaf:Person;
                     foaf:name "Henry Story";
                     foaf:homepage <http://bblfish.net/>;
                     is cert:identity of ... } .

 
  Notice now that the object of log:canonicalSemantics is a graph, which
we can think of as the set of possible worlds in which the statements therein
are true.

   I think up to here I feel pretty comfortable.

   There are a few interesting issues from there on that I need to think about more:

   - if the graph to the right does not individuate one thing, is that just bad practice? Does it make the url "http://bblfish.net/#me" essentially unuseable, until that detail is cleared up.

   - how much of the vocabulary inside the graph needs to be understood too? Perhaps
 one needs to get the meaning of each relation until one finds an identifying description.

   - Is the description in the graph to the right a way that would identify :me in every possible world, ie is it a description or a rigid designator? How does one distinguish rigid designators from general desciptions.

     I think your suggestion here is that it is a rigid designator -- which it can only be if there is a way to tie that meaning to the actual world.  You do this tying to the actual world by thinking of the description as a speech act, or a document publication act. That sounds good.  
   But perhaps we need a vocabulary then to help us distinguish such acts and general descriptions. I think a few examples would probably help here. If all the graph contained was
    { :me foaf:name "Henry Story" . }
   Then that certainly would be ambiguous. Would that mean the <http://bblfish.net/#me> then referred to any person named "Henry Story" ? In any possible world? 

     In the foaf+ssl space perhaps it does not matter because all the authentifying server knows is that a certain thing at the end of the actual connection was able to encrypt something with a private key which then matched the public key. From then on that server has two pieces of information: it has a description + it has information about an actual causal connection that took place, which then identify uniquely an actual agent. Once that piece of knowledge is added to the data store, that agent will in all further interactions be able to increase its causal access to that agent.
    
                                           
 Anyway, I think these things are tricky but solveable, and somehow we are on the right track. Speech act, sense/reference, all are important parts of the puzzle. 
Gareth Eveans btw in his book "The Varieties of Reference" has a very important contribution here concerning the relation between determinate descriptions and reference..... 

	Henry Story



> 
> 
> 
> -- 
> David Booth, Ph.D.
> Cleveland Clinic (contractor)
> http://dbooth.org/
> 
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of Cleveland Clinic.
> 
>

Received on Wednesday, 7 July 2010 08:33:42 UTC