Re: Refers Or Denotes?

On 2/13/13 1:15 PM, Henry Story wrote:
> On 13 Feb 2013, at 18:51, Kingsley Idehen <> wrote:
>> On 2/13/13 12:34 PM, Henry Story wrote:
>>> On 12 Feb 2013, at 22:09, Kingsley Idehen <> 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:
>>> 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 )

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

> 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 

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

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

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

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

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



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Wednesday, 13 February 2013 19:03:39 UTC