RE: Valid representations, canonical representations, and what the SW needs from the Web...

> -----Original Message-----
> From: ext Paul Prescod [mailto:paul@prescod.net]
> Sent: 04 February, 2003 00:37
> To: Jeff Bone
> Cc: Sandro Hawke; www-tag@w3.org
> Subject: Re: Valid representations, canonical 
> representations, and what
> the SW needs from the Web...
> 
> 
> 
> Jeff Bone wrote:
> > 
> > Almost totally agreed w/ Paul on this, but two minor nits 
> --- tangential 
> > but food for thought.
> > 
> > On Monday, Feb 3, 2003, at 15:55 US/Central, Paul Prescod wrote:
> > 
> >> Those billions of pages are not semantic-web processable or we 
> >> wouldn't be arguing about how to build the semantic web. 
> They are the 
> >> things talked ABOUT by the semantic web, not the nodes in the web.
> >> Because the are 100% semantically ambiguous I would say 
> that they are 
> >> totally valueless as part of the web.
> > 
> > Paul, you might be overstating the case just a bit.  If 
> *could be* that 
> > services e.g. Google could perform a useful function in mining and 
> > making (minimal) semantic information about the existing 
> (non-semantic) 
> > Web available in a machine-usable fashion.  I.e., to some 
> extent your 
> > comment about the existing Web being the subject of the 
> semantic Web 
> > belies your comments about the value of the existing Web.
> 
> Fair enough. But if the new application is Web-smart (as Google is), 
> then there would probably be URIs of the form:
> 
> http://www.semgoogle.com/about=http://www.prescod.net
> 
> *That* would be the URI for the semantically meaningful 
> information from 
> "http://www.prescod.net". And even so, it would be totally ambiguous 
> whether it is information about a web page, a person, a company, etc.

Or far better, 

GET  http://www.prescod.net gives you a representation of a resource
MGET http://www.prescod.net gives you knowledge of a resource

And it is what is provided by MGET that tells you what the resource
is, and even what to expect from GET and how to optimize GET to
your needs.

And the knowledge mined from http://www.prescod.net with MGET
by Google and managed by www.semgoogle.com is the same as that
accessible by MGET http://www.prescod.net (though possibly dated)
and syndicated with knowledge about many, many other resources.

> >>  Plus, not that URIs are not expensive. They are cheap. Making new 
> >> ones is easy. We need to make new ones to have a home for 
> the RDF data 
> >> anyhow. So what.
> > 
> > 
> > I wonder about this.  Google knows about ~ 3B "pages."
> 
> Pages are expensive. URIs are cheap. Wasting 3B URIs is not a tragedy 
> because I can generate 3B new ones with a ten line Python 
> script. I can 
> _even_ give them HTTP representations in roughly ten more 
> lines of code 
> (including five lines of RDF cruft;)).

Creating new URIs is cheap. Managing all the relationships between
the resources denoted by those URIs is far more expensive, and 
often exponentially so.

The issue of this debate has never been whether a URI denotes
a resource. But how is that URI interpreted in a Web context
versus SW context, and how the Web architecture can serve the
needs of both interpretations.

To date, the primary suggestions have centered around treating
knowledge about resources as representations of those resources,
which I consider to be the crux of the problem.

Once you keep knowlege and representations disjunct, and realize
that the Web cares about representations and the SW about knowledge,
and both needs can be provided by the same essential architecture
as it (almost) stands (HTTP) but requiring adjustments to maintain that
crucial distinction between representation and knowledge (GET vs.
MGET, etc.) then all is well, and both the Web and SW can agree
about resources and URIs and that URIs denote resources, etc.
and the Web can concern itself with representations without troubling
about knowledge and the SW can concern itself with knowledge
without troubling about representations, and URIs tie the two
together quite nicely, consistently, and without conflict or
ambiguity.

Problem solved.

Patrick

--
Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com

Received on Tuesday, 4 February 2003 06:22:38 UTC