W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

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

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 18 Jul 2003 12:49:07 +0300
Message-ID: <003e01c34d11$dc2634a0$ce0ea20a@NOE.Nokia.com>
To: "ext Michael Mealling" <michael@neonym.net>
Cc: "ext Tim Bray" <tbray@textuality.com>, "Jonathan Borden" <jonathan@openhealth.org>, "pat hayes" <phayes@ihmc.us>, <www-tag@w3.org>, "Pat Hayes" <phayes@ai.uwf.edu>

----- Original Message -----
From: "ext Michael Mealling" <michael@neonym.net>

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

I don't see that layering is the optimal way to model this.

A WebResource ISA Resource in the same way that a dog ISA mammal.
A dog does not contain a mammal. Nor does a WebResource contain
a resource.

Also, a WebResource need not be a SemanticWebResource and visa versa.

Sets and intersections accurately capture this.

Layering need not utilize physical encapsulation. Layering can
be entirely conceptual.

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

Well, I've always been under the impression that the above
relate to protocols above, beside, or below the "Web", not part
of the Web itself and that the "World Wide Web" was specifically
defined according to the behavior of the HTTP protocol.

Maybe that view is now obsolete (or completely wrong). But
that's been my understanding.

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

I certainly don't presume that my definitions are perfect.
They were intended as useful milestones along the road to

Feel free to suggest a more accurate definition of the class
of resources which is the intersection of WebResources and
Representations. I think that is a very interesting class
to nail down.




Patrick Stickler
Nokia, Finland
Received on Friday, 18 July 2003 05:49:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:00 UTC