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

I'll make a few quick comments and then go off to the proverbial hills
to think about this some more, as well as wait for additional
commentary. TimBL had a rather sensible idea that
the first step to "solving" httpRange-14 would be to think about the 
terminology, and Henry's suggestion to think about the possible space of 
answers in more depth is a good one as well.

I'm just going to note that Roy's example, Tim Bray, is a bit misleading.
There might for some lucky cases such as Tim Bray be an obvious URI
for that thing, such as: http://www.tbray.org/ongoing/misc/Tim. However,
think about Louis XVI? What is the obvious URI for Louis XVI?
www.infoplease.com/ce6/people/A0830398.html,
http://www.angelfire.com/va/frenchrev/LouisXVI.html
http://en.wikipedia.org/wiki/Louis_XVI_of_France

They all seem pretty good. Should we just pick one randomly?  And by using 
one of them to refer to the  historical Louis XVI, with no additional 
information outside the URI and the representation it currently receives, 
one does confuse the  representation and the resource. And most 
representations do not have one distinct and obvious resource. For 
example, is http://www.eyewitnesstohistory.com/louis.htm about Louis, his 
execution, or the eyewitness account of his execution? All of these are 
similar yet different. How can we help make a statement about Louis XVI
on the SemWeb less ambiguous?

One could pick one randomly, and make owl:sameAs statements perhaps
(or hope someone else)...yet these resources aren't really aren't equal
in terms of content - some of these URIs retrieve reps. that have more 
information about Louis XVI than others, and they disagree on some of the 
details of his life. What they have in common is they all give a "partial 
description" of a "non-information resource" Louis XVI, and that this 
resource qua resource (the Actual Louis XVI) that we wish to make a 
statement about, not any particular  representation of the resource, and 
with full realization that this resource may have  multiple URIs. Users
should be able to discriminate if they so choose on this point.

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

Which http URI? The URI of "ongoing" http://www.tbray.org/ongoing/ - then 
how do we know if we are talking about the blog, the blog on a date, the 
image? Confusing them all with one URI seems to make any inference 
difficult if not impossible.

Then the problem is creating new RDF vocabularies to tease these things 
out - which is exactly one way to try to "solve" http-14 once there is a 
consensus on what the problem is and the various categories of things on 
the Web. SKOS has been working on this obviously - yet until such work is
standardized, people will be unable to share such vocabularies using the 
SemWeb. Lastly, this *avoids* the problem, since the statements are made
also using often ambiguous URIs - look at dc:creator. This could lead to 
a infinite regress of URIs statements describing other URIs.

>> The question is not *are* abstractions being represented, the question 
is *how*.
> Why is that any of our business?

I would assume that standards were the W3C's business, especially when it 
comes to the crucial issue of identifying things and information over the 
Web, which is  the SemWeb's largest selling point.

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

Then one discovers the "meaning" of a resource by a combination of many 
things. Why are you against clarifying what those things are and how 
they should interoperate?
>
> Content negotiation on every resource is not a viable solution
> because it interferes with caches.

Funny you brought it up, since it seems like content-negotiation plays a 
big part in the AWWW and the entire conceptual apparatus of why we need
"resources," since even at one time t a resource could have mulitple
representation.

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

This is exactly the concrete type of solutions I'd like to see the TAG
discuss, and how they interrelate. A while ago I proposed something much 
simpler than the set of things Roy talked about [1] ...just using a 
RDDL-like file that can be translated into RDF that just consists of
bunch of links to other URIs that a particular user judges to be the same 
resource. I now feel this may be a bit old-fashioned of a way to deal
with it, so I'm going to look on ways of improving the problem, but I do
feel Roy is right - *links* are one way to definitely help solve 
httpRange-14.

[1] http://www.webpropernames.org/paper/#expanded

> ....Roy
>
>

 	Ta ta for now - I promise I won't respond for at least a week!

-- 
 				--harry

 	Harry Halpin
 	Informatics, University of Edinburgh
         http://www.ibiblio.org/hhalpin

Received on Saturday, 7 May 2005 16:05:39 UTC