W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: What is a URL? And What is a URI

From: Patrick Durusau <patrick@durusau.net>
Date: Fri, 12 Nov 2010 13:31:54 -0500
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: Dave Reynolds <dave.e.reynolds@gmail.com>, "public-lod@w3.org" <public-lod@w3.org>
Message-ID: <1289586714.1525.170.camel@ratatosk.home.org>
Kingsley,

On Fri, 2010-11-12 at 10:12 -0500, Kingsley Idehen wrote:
> On 11/12/10 8:40 AM, Patrick Durusau wrote:
> > Kingsley,
> >
> > On Fri, 2010-11-12 at 07:58 -0500, Kingsley Idehen wrote:
> >> On 11/12/10 5:59 AM, Patrick Durusau wrote:
> > <snip>
> >
> >>>
> >>>
> >> Patrick / Dave,
> >>
> >> I am hoping as the responses come in we might pick up something. There
> >> is certainly some confusion out there.
> >>
> >> Note my comments yesterday re. URIs and Referents. I believe this
> >> association to be 1:1, but others may not necessarily see it so.
> >>
> > Isn't it that "...others may not necessarily see it so." that lies at
> > the heart of semantic ambiguity?
> 
> Yes!
> 
> We are perpetuating ambiguity by conflating realms, ultimately. The Web 
> of URLs != Web of URIs. They are mutually inclusive (symbiotic).
> 

Err, no, we are not "perpetuating ambiguity." Ambiguity isn't a choice,
it is an operating condition. 

> > Semantic ambiguity isn't going to go away. It is part and parcel of the
> > very act of communication.
> 
> This is why Context is King.
> 
> You can use Context to reduce ambiguity.
> 
> A good Comedian is a great Context flipper, for instance.
> 
> Ambiguity exists in the real-world too, we use Context to disambiguate 
> every second of our lives.
> 

Eh? True enough but context in the "real-world" (do computers exist in a
make believe world?) is as unbounded as the subjects we talk about.

It is the journal I am reading that is part of the "context" I am using
for a particular article or is it the author or is it the subject matter
or is it the sentence just before the one I am reading? 

All of those, at times some of those and at still other times, other
things will inform my context. 

> > It is true that is very limited circumstances with very few semantics,
> > such as TCP/IP, that is it possible to establish reliable communications
> > across multiple recipients. (Or it might be more correct to say
> > semantics of concern to such a small community that agreement is
> > possible. I will have to pull Stevens off the shelf to see.)
> >
> > As the amount of semantics increases (or the size of the community), so
> > does the potential for and therefore the amount of semantic ambiguity.
> > (I am sure someone has published that as some ratio but I don't recall
> > the reference.)
> 
> So if a community believes in self-describing data, where the data is 
> the conveyor of context, why shouldn't it be able express such believes 
> in its own best practice options? Basically, we can solve ambiguity in 
> the context of Linked Data oriented applications. Of course, that 
> doesn't apply to applications that don't grok Linked Data or buy into 
> the semantic fidelity expressed by the content of a structured data 
> bearing (carrying) resource e.g. one based on EAV model + HTTP URI based 
> Names.
> 

Not to be offensive but are you familiar with "begging the question?" 

You are assuming that "...we can solve ambiguity in the context of
Linked Data oriented applications."*

That is the *issue* at hand and cannot be assumed to be true, lest we
all run afoul of "begging the question" issues.

Hope you are having a great day!

Patrick

*Your "Linked Data Application* may supply context but that *is not*
interchangeable with other "Linked Data Applications." 

Nor does it reduce ambiguity.

Why?

For the same reason in both cases, there is no basis on which context
can be associated with identification. Remember, the URI is the
identifier. (full stop)

Fix it so that URI plus *specified* properties in RDF graph identify a
subject, then you have a chance to reduce (not eliminate) ambiguity. Not
as a matter of personal whimsy but as part of a standard that everyone
follows. 

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
Newcomb Number: 1
Received on Friday, 12 November 2010 18:32:43 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC