Re: Documents, Cars, Hills, and Valleys

> I would like to see some practical examples of
> what real world problems are caused by the two
> points of view.

I think that people like to avoid talking about the pratical side of
this argument, simply because there aren't many practical examples
going around. It's a weakness, and so people aren't willing to discuss
it.

But there are problems. In the Evaluation And Report Language [1],
we're basically quite stumped as to what things are being evaluated.
For example, we might have the following Webpage that talks about a
tool:-

   http://example.org/myTool

Now, when you make an evaluation about that page, if you don't know
whether it represents a tool, or some documentation about that tool,
then how can you be sure what someone is evaluating? They might start
saying that "it" is very accessible, for example that it passes all of
the Web Content Accessibility Guidelines (the W3C content
accessibility rec.) - but what is passing that, is it the page, or the
documentation within the tool itself? Of course, you might be able to
guess from the test. If you say that something's wheels are all
properly balanced, then you can be pretty sure that it's a car. So the
domain of some tests are quite obvious, but we have to account for
those times when the domain is not obvious, and when the thing that
the URI represents is unambigous. Note that Al Gilman has talked in
more detail about the test domain idea [2].

Now, I've already bored people with EARL's "fix" for the problem
(adding a layer of indirection). We could remove the indirection if we
could know for certain that HTTP URIs identify "documents", since we
could be fairly sure that the URI above represents some online
documentation about the tool, and not the tool itself. If, however,
the range of HTTP can be anything, then we're simply not sure. In that
case, we have to go back to one of:-

* Using the indirection predicates
* Using the test case domain idea
* Possibly looking at the headers for Resource-Type headers:-
http://www.ietf.org/internet-drafts/draft-palmer-resrep-type-00
http://infomesh.net/2002/draft-palmer-resrep-type.txt

So that's one potential way in which the range-of-HTTP issue affects
users. In fact, there are a few more issues that are raised by the
slightly larger hash vs. slash discussion. Here are some that I've
been able to find:-

Aaron Swartz: [[[
I want to create an HTTP proxy which I can host. Users who use this as
their main HTTP proxy will see an RDF-annotated view of the Web, by
typing URIs into their browser like normal. However, they'll get back
a pretty version of all RDF assertions using that URI as its subject.
Unfortunately, since RDF allows fragments as subjects there's no way
for them to specify a fragment in their query, since the Web browser
doesn't send it along (by design according to TimBL, see previous
message). Thus they're not able to access all that information without
big kludges in my software.
]]] - http://www.w3.org/2002/02/mid/B891F4F4.20BF5%25me@aaronsw.com

Sean B. Palmer: [[[
Many people believe that fragments must be persistent; in the case of
XPointer, that means that your XML document had better not change one
iota. So, if you want to use XPointer, you have to do so on a resource
that has a single fixed XML
representation. That's absurd.
]]] -
http://www.w3.org/2002/02/mid/009101c1e08a$3825e200$0c560150@localhost
- http://lists.w3.org/Archives/Public/www-annotation/2002JanJun/0147

Tim Berners-Lee: [[[
From the outputter's point of view, when there is a hash, it takes the
URI on the left and just looks it up in the prefix dictionary.  When
there is no hash, it doen't know where to make the break - you are
allowed in principle to break half-way through a word.  I *suppose*
one could just have "/" as another option, but the optimum would be, I
assumed, to search for the longest match. Which would be slower, but
the serializer doen't need to be fast.
]]] -
http://www.w3.org/2002/02/mid/000101c1756a$b49aedc0$eb13940a@CREST
- http://lists.w3.org/Archives/Public/www-archive/2001Nov/0070

On the thread itself, I think that Miles Sabin is certainly onto
something: this has never been a problem before because people haven't
(and still don't) need to pin down the semantics of their hyperlinks.
They can say "fred made a good quote on x", or they can say "this is a
great new product: x", or they can go in between "here's a great new
page about x". But now we're building a Semantic Web, we have to be
stricter about what HTTP URIs identify, and that goes against how
they've been used for ten years. Actually, it quite hillarious
watching the argument, since both sides are trying to impose views
against the general intuition of the majority of Web users.

[1] http://www.w3.org/2001/03/earl/
[2] http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2002Mar/0007

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Thursday, 11 April 2002 07:26:56 UTC