Re: Refers Or Denotes?

On 13 Feb 2013, at 20:03, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 2/13/13 1:15 PM, Henry Story wrote:
>> On 13 Feb 2013, at 18:51, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> 
>>> On 2/13/13 12:34 PM, Henry Story wrote:
>>>> On 12 Feb 2013, at 22:09, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>> 
>>>>>> I am not sure why "denotes" is being taken up by the RDF group nowadays, when most philosophy books and logic books tend to use the word "refer". Most engineers use the word refer too on a daily basis.
>>>>> Quite simple, when the context is Linked Data, an HTTP URI has an inherent duality whereby it denotes an entity and identifies a Web resource. This duality makes the use of "refers to" ambiguous as exemplified by the HttpRange-14 permathread. As I said, this matter was discussed to conclusion on the RDF working group list [1].
>>>> While I agree with the general thought you are expressing, putting things like this is liable to be confusing Kingsely, and part of the reason for the existence of the permathreads. This is why we need to clarify the different concepts involved.
>>>> 
>>>> I think the illustration here does this nicely:
>>>> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/img/WebID-overview.png
>>>> 
>>>> It shows that URIs just refer/denote.
>>> Yes, that works.
>>> 
>>> If possible, as already requested, you can add "(perception)" below "sense". It also adds visual uniformity too.
>> As I pointed out in my reply perception is not the right word. So I put "meaning" instead.
>> 
>> sense ( meaning )
>> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/img/WebID-overview.png
> 
> That will do for now. The context of my comments will play out over time, and maybe lead to the tweak I suggested, in due course :-)
> 
> Other comments follow.
>> 
>> which also works for you as one can think of it as the meaning as requiring a different sense if you want ( would that be intelligence ? ( just a rethorical question, let's not get too off topic here ))
>> 
>>>>  But as it happens with hash uris they are constitued as per URI definition of two URIs, or rather there is a very strong relation between the one and the other.
>>>> 
>>>> [[
>>>> The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.
>>>> ]
>>>>   http://tools.ietf.org/html/rfc3986#section-3.5]
>>>> 
>>>> This relation I name in the diagram to be the "sense" relation, which goes from the hash URI to the Profile document. This way there is no confusion between sense and reference, and it is clear how each accomplishes the task.
>>>> 
>>>> One could make a similar case for URIs with no hash but with a 303 redirect, though in this case the relation between the URI and the sense is not determinable in advance with the URI alone.
>>>> 
>>>> Henry
>>> A hash based HTTP URI is simply about *implicit* indirection.
>> There is nothing implicit in this indirection. It's part of the meaning of a URI. It is explicitly stated in the URI spec.
> 
> You are note *sensing* what I am trying to communicate. I say that because this isn't about the URI spec.
> I was commenting about how you get to data via identifiers that serve as generic names or locators.

ok. Not a big deal. All I was disagreeing was that this was "implicit", what would be an explicit indirection? I just don't think those are the correct words to use. But as you see below I understand you very well.

> 
>> It is part of the meaing of URIs if you want. This could not be more explicit.
> 
> We are talking past ourselves. You don't see the broader connection between Linked Data and data access by reference. I do, because I've worked on both, deeply. If you can't make any connection between Linked Data, ODBC, and JDBC, then (as already stated) we are just talking past ourselves.

Yes, we are talking a little past each other. But I don't see why you need to argue that I don't understand those relations. Below I give you a definition of them.

> 
> 
>> 
>> Also talk of indirection is not that helpful. The :reference relation and the :sense relation are
>> two different relations. One is not an indirection of another. It is only that with documents which the Web initially only deal with the :reference and the :sense of the URIs were the same.
> 
> You are mixing stuff up in that paragraph above, so of course you perceive it as unhelpful. I don't which is why I've spent some much time on this matter over the years.

So have I, so let's be attentive to each others words, and read carefully.

> 
> This is what I said to you, one more time:
> 
> With regards to Linked Data, a hash HTTP URI uses implicit indirection to disambiguate the entity it denotes and location of said entity's description (delivered by a Web Resource nee. Information Resource).

I think we are just looking at things differently. You are speaking in terms of message exchange diagrams, and there is indirection there if you want.

You are trying to define a relation that relates any URI to data that it is about. Let us call this relation k:data, ( and restrict it to http URIs for the moment to keep things simple )

 k:data a rdf:Property;
    rdfs:comment """
      A relation relating an http URI to the graph of data by following the procedure: 
      - If the URI is a hash URI create a new URI by removing the hash and fetch the graph from that document
      - otherwise fetch the document by making an HTTP request on the given uri by following 303 redirects if needed.
""";
    rdfs:range :Graph .

It seems to be close to log:semantics except that perhaps log:semantics is (being careful and conservative in my interpretation of it) always a relation from a document to a graph, whereas you have a more general k:data relation to be from any URI to a graph. Ok?

So for example: 

<http://www.w3.org/People/Berners-Lee/card#i> k:data [ log:includes {
     <http://www.w3.org/People/Berners-Lee/card#i> a foaf:Person. 
    }
 ] .

and 

<http://xmlns.com/foaf/0.1/mbox> k:data [ log:includes {
      <http://xmlns.com/foaf/0.1/mbox> a owl:InverseFunctionalProperty . 
   } ] .


( I use log:includes in order to not have to write out all the graph )

Essentiall if you want that is at least very close, if not identical to 
the :sense or :meaning  relation I am defining in the diagram. 
       
Good if we can agree this far, then we are not really disagreeing on 
the core at all.

All I am saying is that the k:data relation is not the same as the :refers
or :denotes relation. And I think you agree with that too.  
where ( :denotes owl:sameAs :refers )


> 
> Staying with the theme above, a hashless HTTP URI achieves the same thing via HTTP message exchange.

I know that, and I agree.  

> 
> In either case, you get to the data via indirection. You have two identifiers that get you to the same data. Those identifiers denote different things (or entities).

yes 

<http://www.w3.org/People/Berners-Lee/card#i> k:data :x.
<http://www.w3.org/People/Berners-Lee/card> k:data :x.

I.e. both URIs have the same k:data.

And indeed that is exactly what the diagram shows:

https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/img/WebID-overview.png

Except that I don't show the second k:data relation, since it would have the same
subject and object as the :denotes relation for the Personal Profile document, and
that would clutter the diagram.

Now it may be that the sense relation is a bit more complex that just k:data relation,
since one could say that some subgraph of the k:data gives the meaning of the 
WebID. Sense determines reference. 


> 
>> 
>>> The hashless HTTP URI is simply about *explicit* indirection using an HTTP redirection heuristic. In either case, abstraction is being used to enhance data access by reference (Name or Address).
>>> 
>>> ODBC and JDBC data access APIs offer the same capability via data source names (Names) and connections strings (Locators/Addresses). The shortcoming of ODBC (operating system specific) and JDBC (language specific)  boils down to not being as open as the Web. In addition, both suffer from underlying DBMS technology limitations due to SQL RDBMS specificity.
>>> 
>>> What's old is new :-)
>> yes, indeed. that's why I am pointing right to the work by Frege, who wrote and develoed the sense/reference distinction. If you follow Robert Brandom's courses on Kant and Hegel
>> especially his Woodbridge lectures
>> 
>>    http://www.pitt.edu/~brandom/multimedia.html
>> 
>> you will see him arguing that this distinction was already the one that Kant was grappling
>> with. As I understood him, Kant thought that senses/meanings were fixed ahead of
>> time ( and the problem was then how does one get to know them), where Hegel then
>> argued that these developed historically, though a process of judgements each of
>> which looks to precedents in the past to guide, and creates precedents for judges
>> in the future.
>> 
>> So yes, what is old is new. It does get improved and refined along the way through
>> what Hegel called Erfahrung.
> 
> Yes, of course :-)

:-)

> 
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/