[httpRange-14] Re: fragment identifiers

[Roy refers here to the problem that httpRange-14 causes in EARL:-]
> That problem is simple to fix.  It is natural to want to make statements
> about resources and about representations of resources. [...] It is
> solved for HTTP/1.1.  Now we just need to find the corresponding
> syntax for it in RDF.

Let me explain how we currently model this (i.e. solved it) in EARL, which
is a pretty generic RDF application, and could be reused elsewhere.

Let's say that because the TAG has not yet come to a decision on this
issue, the URI http://example.org/tool/ identifies either a tool, or some
generic document that talks about that tool. (Digression: I know that you
will simply state that it is nonsensical to restrict the publisher to only
being able to identify timbl:Documents with HTTP URIs, and yet I also know
full well that TimBL will argue the contrary. The argument by assertion on
either side has not brought TAG to a resolution yet.) We have a proposed
indirection property--called earl:documentation--where if the value of the
property is a tool, then the subject is simply equivalent to the value,
whereas if the value of the property is a web document, then the subject is
a tool that is simply documented by the value.

This is--AFAIK--compatible with both points of view, although it does mean
introducing an unecessary extra triple into EARL applications in the event
that the "HTTP URIs can identify anything" POV is upheld. What would be
helpful to us is that, if this issue were to be resolved soon, we could
either tighten the meaning of the earl:documentation property, or remove it
altogether.

This issue has gone around in circles for long enough that it's clearly
become just a battle of wills. I think that the majority of consensus (from
what I can tell on the www-tag list and others) is behind HTTP URIs being
able to identify anything, but it's not a crushing majority. TimBL's latest
DesignIssue [1]--though sloppily worded in many places (as Aaron was so
quick to pounce upon)--does help to clarify his point of view, and gets us
one step closer to that vital algorithm for determining what a
timbl:Document is. If TimBL were to come up with a suitable formal
defintion for his document class, that would perhaps enable the issue to
progress a step forwards towards resolution (where "suitable" here means
grounded in current specifications where appropriate, strict enough that it
enables one to always tell for any given resource (where enough properties
about it are known) whether it is a document or not, and rigid enough so
that it leaves no room for speculation or false interpretation, especially
in areas concerning IPR of documents, and so on).

I have a feeling that the phrase "Anything vs. Document" is going to end up
achieving more legendary status amongst hacker circles than "Kirk vs.
Picard".

[1] http://www.w3.org/DesignIssues/HTTP-URI

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

Received on Monday, 29 July 2002 21:44:20 UTC