Re: Issue-57

On Thu, Jun 23, 2011 at 3:08 PM, Xiaoshu Wang <xiao@renci.org> wrote:
>
> The original purpose of httpRange-14, I guess, is to avoid ambiguity. But
> ambiguity can only be cleared with more ontological assertions.
> httpRange-14 has raised more confusion/debate. Except transferring
> ambiguity to a different term, what problem it has solved?

I can see you're getting hung up on unimportant points, so let me try again.

Let's make sure we're talking about the actual problem to be solved,
since it's easy to lose track in all the irrelevant ontological
hand-wringing. This is not a philosophical or ontological problem;
it's pure engineering.

Suppose the following holds:

    <http://example/z> xhv:license <http://example/l1>.

Suppose that I do a GET of 'http://example/z' and retrieve a "representation" R.

My interlocutor wants me to be able to infer that

    R xhv:license <http://example/l1>.

so that my remix tool knows what license terms apply when using the bits in R.

Anyone who likes web architecture (Tim's and the 2005 TAG's, not Roy's
or yours) would say that this inference is exactly what the
httpRange-14 resolution is meant for. If web architecture can be
assumed, then the inference is valid.

Anyone who doesn't, and rejects the resolution, says the inference is
not valid, so this won't work. If you cast about for an interpretation
of 'http://example/z' there might be more than one - the intended one
is an option, but if R *describes* some entity E satisfying

    E xhv:license <http://example/l2>.

where the license terms in l2 are quite different from those in l1,
then absent httpRange-14 E would also be a plausible interpretation of
'http://example/z' (consider the relation of _Bleak House_ the novel
to the page at 'http://en.wikipedia.org/wiki/Bleak_House' - these are
licensed quite differently). And there might be others.

That's the ambiguity that is being addressed - what is related by
xhv:license to l1, the representations coming from GET of
'http://example/z', or something else (E). It has nothing to do with
ontology.

So if you (or the agent you're talking to) don't agree to the
architecture, the statement about <http://example/z> is not an
effective way to communicate information about the representations R,
and you have to coordinate some other way to say it. If you start
looking for a different way to express this meaning, then I have
proven my point that the architecture is useful; you are just on the
road to showing it's unnecessary or undesirable, which is a different
question.

And if you are saying that the resolution is impractical and will
never get adequate uptake, then I have also proved my point, since
that would say that, if counterfactually agreed on, it would have some
value to someone.

Of course the httpRange-14 resolution as stated doesn't allow the
desired inference, since the rule doesn't tell you *which* information
resource is "identified", but that is a bug that I think we all now
recognize. What was really meant was that the URI "identifies" a
*particular* resource, namely the one whose associated
"representations" are retrieved (i.e. are 2xx responses) from that URI
- and I think this is pretty obvious, so obvious that no one thought
to say it at the time.

In order to do the inference above there is absolutely no need to do
ontology around "information resources". It really doesn't matter what
they are, and we may not even need the term at all - I didn't need it
in the above exposition. It's unfortunate that the foolish
"information resource" meme has tripped up so many of us (I know, I
was stuck on it too for a long time).

Jonathan

Received on Friday, 24 June 2011 02:17:02 UTC