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


Reply via email to