Re: Resolution for rdfms-fragments

On 2001-12-06 11:14 PM, "Dan Connolly" <connolly@w3.org> wrote:

> In that sense the URI RFC also says
> what http://www.w3.org/1999/02/22-rdf-syntax-ns#value means.
> 
> i.e. it gives a sort of standard interpretation that meshes
> quite nicely with the interpretation structure in the RDF
> model theory draft.

You really think so? I have trouble reconciling what the URI RFC says:

[[[
   A fragment identifier is only meaningful when a URI reference is
   intended for retrieval and the result of that retrieval is a document
   for which the identified fragment is consistently defined.
]]] - RFC 2396 available at http://rfc2396.x42.com/

With RDF's usage. (I don't understand why you keep talking about the model
theory draft, as I pointed out it simply dodges the question.)
 
>> HTTP is a way to retrieve (supposedly authoritative) information about the
>> meaning of an HTTP URI. I can get back a redirect, establishing something of
>> an equivalence between URIs, I can get back RDF metadata on it, or I can get
>> back an Unauthorized refusal.
>> 
>> HTTP cannot give me any of this information on a URI with a fragment in it.
> Sure it can; that is: you can get, via HTTP, documents that use such
> URIs; documents which tell you about the meaning of such symbols.

But this information is only useful in the context of such retrievals. I
suppose I could take the data I get back, and the portion of that data which
is relevant, and quote it or something, or create a new resource to describe
the data I got back, but the URI spec clearly states that this information
doesn't work outside of this context.

I quote:

[[[
   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.
]]]
 
>> All the tools I have to find out information about a HTTP URI don't work
>> when fragments are invited.
> For example?

I just told you, but to repeat:

Status codes, redirections, access control, HTTP OPTIONS header, WebDAV's
PROPFIND stuff, etc.

>> Well there appears to be a (rather sad) schism between the IETF and W3C
>> worlds. I suspect your stuff sits on the W3C side of the fence, which is why
>> it works. On the other side, my stuff chokes.
>> 
>> I'm hoping we can start patching up the divide. I'm approaching it from this
>> side, since RDF's deployed base is trivial in comparison to HTTP servers.
> 
> Baseless rhetoric.
> 
> The Director of W3C is a co-author on the relevant RFC.
> 
> I am as much on the IETF side as anyone else on the planet.
> supporting evidence, per google:
> [...]

Well, then I'm sure you'd be happy to go along with the text of the RFC in
that case, right? Why do you and TimBL continue to put out information that
flatly contradicts it? This is the issue that really has me confused.

As you say, TimBL is a co-author of the RFC, but his writings seem to
contradict it. Side-by-side comparison:

TimBL: "Formally, the URI *does* include the fragment ID" (emphasis in the
original) 
 - http://www.w3.org/DesignIssues/Fragment

URI RFC: "However, 'the URI' that results from such a reference includes
only the absolute URI after the fragment  identifier (if any) is removed and
after any relative URI is resolved to its absolute form"
 - http://rfc2396.x42.com/

This is not the only time that Tim's personal writings have been
inconsistent with the specs that bear his name, but I'll stop here.

> If you want to justify a claim of lack of interoperability,
> just point out two pieces of software that
> conform to the relevant specs and yet fail to interoperate, please.

The core incompatibity here seems to be of beliefs and semantics, not of
code. But in terms of code, I think I've provided a long list above of
options for finding out more about resources I depend on, that just don't
apply to URIs with fragments in them.

I don't have a lot of experience with web tools, so I'm sure others can
bring up more examples than I (Roy Fielding, perhaps), but here's one: my
Microsoft Entourage v.X doesn't work with URI with fragments.

>> I mean, if
>> the W3C can do it, why can't I? My Frobnitz draft says all fragments resolve
>> to the literal string "cheese".
> 
> The RDF spec and the URI spec are orthogonal and don't form
> this sort of conflict.

The RDF claims it describes Resources, no? It calls itself a Resource
Description Framework. The URI spec seems to go out of its way to say that
URIs with fragmentIDs in them are _not_ Resources, yet RDF describes them.
Perhaps we should rename RDF the Resource and Other Thing Framework for
'Laborating (ROTFL). ;-)

To drive home this point, I quote from the URI RFC again:

[[[
   [...] A URI reference may be absolute or relative,
   and may have additional information attached in the form of a
   fragment identifier.  However, "the URI" that results from such a
   reference includes only the absolute URI after the fragment
   identifier (if any) is removed and after any relative URI is resolved
   to its absolute form.
]]] 

> Unless the working group is to be convinced by your
> reference to these several IRC chats, it seems necessary.

I've provided extensive quotes in this message to make my point. I hope it's
helpful to other working group members.

> I am only trying to understand the issue in precise terms.

Well, I hope I can clarify.
 
> I understood a bit more now than before I read your message,
> and I think I have explained a bit more how the specs
> don't conflict. Perhaps we are making progress.

I think we are.

-- 
[ "Aaron Swartz" ; <mailto:me@aaronsw.com> ; <http://www.aaronsw.com/> ]

Received on Friday, 7 December 2001 00:46:08 UTC