Re: making progress on httpRange-14 -- yet another suggestion

On May 6, 2005, at 5:19 PM, Harry Halpin wrote:
> First, yes - information resources can be ambiguous on some level.
> I think many people would argue that they are representations encoded
> as bits (information resources) are *less ambiguous* than URIs that
> I belive represent Tim Bray, but when I go to that URI I get either
> his blog or a 404 error.

I am having trouble parsing those sentences.  Representations are
usually encoded as bits, which doesn't say anything about how
the resource is implemented.  "ongoing" is encoded as HTML and
at least one RSS, neither of which says anything about what
"ongoing" is really about (the content as written over time).
It will still be "ongoing" when Tim adds an Atom 1.0 feed.

The only way that an observer is going to know what "ongoing"
actually identifies is if additional information is given,
such as additional assertions, english descriptions, rumors
obtained from other sources, etc.  A computer cannot simply
perform a GET and assume that what it got back is wholly
descriptive of the resource -- it almost never is for websites,
so why should that be any different for non-information resources?

> If I want to share the information resource, then I just tell my 
> friend the URI, and if he has any questions about it, he HTTP GETs a 
> representation of it. The question I believe is what to do when 
> there's no obvious representation of the resource at hand.

All you did was share a reference to the resource.  You can do that
just as easily with people by giving a contextually sufficient name
(e.g, "Tim Bray" is sufficiently unique for this forum) or any URI
with an N:1 mapping to that resource
   (e.g., "http://www.tbray.org/ongoing/misc/Tim")
provided that the statement you make clarifies whether you are
referring to Tim, Tim's page, Tim's image on that page, or perhaps
even a google advert placed on Tim's page.  The same disambiguation
is needed for references to "http://www.tbray.org/ongoing" when
people make statements about the blog, the HTML page version of
the blog, the blog as it appeared on 20040630T1900, the random
image selected for one day of the blog, etc.  Each of those things
are individual resources that could have their own URI, but
people are going to use the "http" URI to refer to them because
that is the most useful and permanent link that they know.

> The key sentence you said is that:
>> on the Web.  Those people are wrong -- there are millions of
>> abstractions represented on the Web right now and they aren't
>> going to go away just to make it easier for computers to do AI.
> That's the point: these *abstractions* are being *represented*. The 
> question is not *are* they being represented, the question is *how*.

Why is that any of our business?

> Right now there are virtually little to no guidelines in this area.
> If I have a SemWeb ontology and I want to refer to "Tim Bray" qua 
> person,
> I can pick a http:// URI and just do make my statements about that URI.
> However, should I take his photo and put it at that URI? Leave that URI
> empty and get a 404 error? Or should I using content-negotiation serve
> RDF? Or should I just point that URI to his blog? And how does someone
> or a machine besides me, perhaps someone with less statements about 
> that URI in RDF,  know what the heck that URI means? This are not 
> insufficient solutions, but actual questions the TAG could answer.

The same way it finds out what any URI means.  You cannot discover
meaning by performing a GET on a URI.  You need to be able to read
what the provider promises, assume via its context, gather from
its use by other link authors, or (if you are very lucky) read
what the owner asserts about the URI in RDF, N3, OWL, etc.
That is true of any resource.  People who simply perform a GET
on a resource don't discover its meaning -- they only discover
a snapshot in time.  The most important characteristic of a
resource is its future behavior.

> Getting to the heart of this would allow people to do *exactly* what
> you describe:
>> My personal favorite is to make the relations specific about
>> whether they refer to the resource or a set of representations,
>> which is something that can be done in a definitional sense
>> without changing any of the technology [though it would help a
>> great deal if the technology supported temporally-qualified
>> assertions]. That way, people and machines don't need to
>> create ambiguous assertions in the first place.
>
> That is what some people are advocating, and only some are advocating 
> changing a URI scheme or adding hashes. Personally, my
> favorite is to settle for a standard XHTML human readable 
> representation (ala RDDL) for the non-information resource, and then 
> use content negotiation to serve RDF/XML. This not only makes the 
> relations specific, but does so in a human and machine-readable 
> manner. I don't see how
> this breaks http, and perhaps you could convice me that this does.

Content negotiation on every resource is not a viable solution
because it interferes with caches.  All you need is a link from
any given resource to the resource that describes it.  A simple
hypertext relationship, like any other, that can be defined
either internally (HTTP header fields) or externally (linkbases,
metadata stores, RDF worlds, etc.).  The resource that describes
it can be represented by any appropriate data format of its own,
and it too may have link(s) to other resources that describe it.

....Roy

Received on Saturday, 7 May 2005 01:43:56 UTC