Re: How about "identifying URL" instead of "canonical" URL?

On 6/25/14 2:59 PM, Kingsley Idehen wrote:
> On 6/25/14 10:26 AM, John Arwe wrote:
>> > URIs denote things. They refer to things. They don't identify 
>> things, implicitly.
>> > Denotation is not the same thing as Identification. That's clearly 
>> understood and reflected in RDF and related AWWW documents.
>>
>> Citation(s) please?
>>
>> I'll note up front, having just searched, that "denote" occurs 
>> exactly zero times in [1].  Section 2.2 [2] even names a Constraint 
>> "URIs Identify a Single Resource ", which on the surface appears to 
>> contradict your response.  The "denot" (sic - searched for the root 
>> in both documents) count is 3 in RFC 3986 [3], none of which are 
>> definitional; the variations on "identif" are (predictably) more 
>> common, with section 1.1 containing an entire paragraph (under the 
>> "heading" *Identifier*).
>>
>> Looking at RDF Semantics [4] and the David Booth thread [5], "denote" 
>> vs "identify" is covered in [4] section 4, "denote" is an 
>> RDF-specific layer that nets out to "denote" = "identify" + 
>> "interpretation", or more specifically  "RDF-denote" = 
>> "WebArch-identify" + "RDF-interpretation".  Keeping in mind that the 
>> LDP WG is about evenly divided between people whose natural habitat 
>> is "REST" (but most can spell RDF) and those ... "RDF" (most of whom 
>> can spell REST/HTTP), it might be we have another case where it's 
>> tricky to get everyone understanding things equally because of our 
>> differing backgrounds.  What's "clearly understood" in one context 
>> has proven in the past to sometimes be "new news" in the other over 
>> the short history of this WG.
>>
>
> Denotation [1], Connotation [2].
>
> The World Wide Web is driven by HTTP URIs that provide both Denotation 
> and Connotation via implicit (e.g., hash based HTTP URIs) or explicit 
> indirection (what you see re. 303 and/or 303 combined with "Link:" 
> header responses, even more so in the latest HTTP specs). It just so 
> happened that it was bootstrapped on the back of denotation of content 
> locations (documents) via HTTP URI/URLs.
>
>> That distinction might also lead people to lean one way vs another 
>> when it comes to choosing which terminology to re-use.  Since an LDPR 
>> might (or might not) be an LDP-RS, and the subject discussion is 
>> about LDPRs in general (not the smaller class of LDP-RS's), people 
>> might be understandably reluctant to apply RDF-specific terminology 
>> (no matter how well-defined) in contexts that are not RDF-specific. 
>>  Or not; that's why we have discussion lists.
>>
>>
>
> Links:
>
> [1] http://www.merriam-webster.com/dictionary/denotation -- denotation
> [2] http://www.merriam-webster.com/dictionary/connotation -- connotation
> [3] http://www.w3.org/DesignIssues/HTTP-URI2.html -- denotation
> [4] http://www.wikihow.com/Differentiate-Between-a-Term-and-a-Word -- 
> difference between a word (IRI) and a term (HTTP URI as required by 
> Linked Data principles)
>

Correction:

The World Wide Web is driven by HTTP URIs that provide both Denotation 
and Connotation via implicit (e.g., hash based HTTP URIs) or explicit 
indirection (what you see re. 303 and/or 303 combined with "Link:" 
header responses, even more so in the latest HTTP specs). It just so 
happened that it was bootstrapped on the back of denotation of content 
locations (documents) via HTTP URI/URLs.

Should have been:



The World Wide Web is driven by HTTP URIs that provide both Denotation 
and Connotation via implicit (e.g., hash based HTTP URIs) or explicit 
indirection (what you see re. 303 and/or 303 combined with 
"Content-location:" re. HTTP response metadata, even more so in the 
latest HTTP specs). It just so happened that it was bootstrapped on the 
back of denotation of content locations (documents) via HTTP URI/URLs. 
Additional links:

[1] http://www.w3.org/2001/tag/2002/0826-archdoc -- search for "denotes"
[2] http://tools.ietf.org/html/rfc7231#section-3.1.4.2 -- Content-location .

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen