Re: "On the Web" vs "On the Semantic Web" (was Re: resources and URIs)

On Thu, 2003-07-17 at 05:43, Patrick Stickler wrote:
> Jonathan Borden wrote:
> 
> > > > If we are going to concern the "SW" at least as it is incarnated in
> current
> > > activities and specific software products (i.e. RDF and OWL related
> > > software), then you may certainly be a part of the Web without a URI.
> Hence
> > > the statement is not correct in the SW context -- I'm not entirely
> convinced
> > > that it is correct in the 'current Web' context e.g.
> 
> To which Tim Bray responded:
> 
> > This might be a nice clear clean differentiating principle, because I'm
> > pretty convinced that at the moment, something that doesn't have a URI
> > isn't part of the Web.
> 
> I think Tim's distinction is valid. A resource not denoted by a URI is
> not "on the web".
> 
> The Web and the Semantic Web are (IMO) two distinct things which
> intersect via a common set of URIs with (presumed) consistent
> denotations.

I think that using set language here might be a mistake. Using
'layering' language is IMHO, much more indicative of what's being
attempted. I'm not sure if its the case here but I know that most
engineers that deal with the lower layers of the network (layers 7 and
down) understand that for the most part, layers assume data
encapsulation: i.e. an ethernet packet's payload is formatted as an IP
packet, an IP packet's payload is formatted as a TCP packet, a TCP
packet's payload is formatted as a segment of an SMTP stream, etc.

In my 'layered' view, the SW is a layer above the web, and as such a SW
'resource' contains at its heart, a Web resource. You _could_ think of
it this way: it's the same object with multiple interfaces, the
Uri-Resource view found in 2396 being the equivalent of an IUnknown
interface (just without the ability to query for  the other
interfaces)'. As you go up the layers you end up with more available
interfaces to pick from....

> Here's how I've been viewing the relationship between the Web
> and Semantic Web:
> 
> The Web is a network of linked representations of resources, where
> those representations are accessible via URIs. Thus it is quite correct,
> I think, to say that a resource that is not denoted by a URI is not "on
> the web". In fact, I think an even tighter claim can be made -- that a
> resource that is not denoted by a URI that is meaningful to the HTTP
> protocol and does not intentionally** resolve to at least one representation
> is not "on the web".
> 
> ** barring practical technical problems such as system being offline,
>      routing updates/problems, etc. etc. i.e. the authority for the URI
>      intends that the URI will reliably resolve to a representation.
> 
> Thus, a URI that consistently and expectedly always produces a 404 error
> does not denote a resource that is "on the web", even if the URI is used
> in some non-web fashion to actually denote some resource.
> 
> And here's an important point, that addresses concerns expressed by
> Pat and Jonathan:  a resource that is "on the web" is not (necessarily)
> itself part of that physically realized network of interlinked
> representations
> managed by web servers. Nor is every representation necessarily
> "on the web" (if it is not unambiguously denoted by its own URI).
> 
> Being "on the web" simply means that the resource in question is
> denoted by a URI which can be resolved via HTTP to a representation.
> And that representation may contain references to other resources
> which may resolve to other representations, etc.

So the web is defined as only those things that are available via one
particular protocol and one scheme? Way to limiting and short sighted.
Are Resources identified by these URI schemes part of the web: ldap:,
urn:, mailto:, go:, cid:? They're used in many deployed systems that
rather large communities consider to be very much connected to the
'web'.

> The only resources which are both "on the web" and part of that physical
> network of representations are representations which are denoted by URIs
> which resolve to a bit-equal copy of themselves.

bit-equality has never been sufficient... network quality of service,
security, signatures, out of band payments, authority, etc, all have
extremely important impacts on whether or not two objects can be
considered 'equal' or not. Entire industries will take you to court over
your assertion that the mp3 I paid for and the one that you didn't pay
for are the same object.

-MM

Received on Thursday, 17 July 2003 13:22:25 UTC