Re: Resolution for rdfms-fragments

Aaron Swartz wrote:
> 
> On 2001-12-06 9:20 PM, "Dan Connolly" <connolly@w3.org> wrote:
> 
> >>> Or give a use case that you think is insufficiently
> >>> specified? (i.e. not a foo/bar/baz example)
> >> I don't know what http://www.w3.org/1999/02/22-rdf-syntax-ns#value means.
> >
> > How does this relate to fragments?
> > Do you know what http://dm93.org/2002/frobnitz means?
> 
> Well, it's meaning is specified by the URI RFC, so yes, at least in the
> sense I meant here.

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.

> > Do you expec the RDF spec to tell you what it means?
> 
> No. That is the problem.

The problem is in your lack of expectations?
I don't think that's what you meant. Please clarify.
Ah... from reading more below, I see that you're saying
that the problem is that you don't expect
the RDF spec to tell you what URIs mean, but it
seems, to you, that the RDF spec is trying to say
what URIs mean. That's not the case, as I explain
above and below...


> >>> Or some piece of code that's acting funny,
> >>> or difficult to write or interoperate with?
[...]
> Let me try this again:
> 
> 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.

> All the tools I have to find out information about a HTTP URI don't work
> when fragments are invited.

For example?


> >> Similarly, systems
> >> like WebDAV or access control built on top of that don't support them.
> >
> > Again, yes, they do, vacuously. (i.e. by not doing anything).
> > Fragment support is all in the clients.
> 
> Exactly. I'm not sure about you, but I consider the Web in the network, not
> in the client.

The Web is a combination of clients, servers, networks, people,
and all sorts of stuff.

> >> Add on to that everyone with a tool that conforms to the URI RFC.
> > Where is the interoperability difficulty? All the RDF
> > software I know of gets along just fine with all
> > sorts of URI-RFC-happy software.
> 
> 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:

Searched the web for connolly ietf.   
                                     Results 1 - 10 of about 6,120.

Searched the web for connolly bunyip.   
                                       Results 1 - 10 of about 688.

(uri@bunyip.com is the mailing list used by the IETF WG
that developed the URI RFC)

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.

> >>  Finally,
> >> their mapping to Resources isn't well defined, or defined at all depending
> >> on your point of view.
> >
> > Their mapping to resources is just as defined as any other
> > sort of URI. Please re-read the model theory draft.
> 
> This is exactly why it's not well-defined. If any draft can define their
> mapping to Resources, then that's a lot of confusion, is it not?

That there is confusion is evident, but it is not a consequence
of conflicts between the URI spec and the RDF model theory.

The RDF model theory does *not* specify any particular interpretation
for URIs [except that it does, somewhat, constrain the interpretation
of, e.g. rdf:value w.r.t. rdf:Property; i.e. it does tell you
some stuff about the RDF vocabulary itself].
For URIs in general,
it specifies various inferences that are valid *no matter how*
you interpret URIs. It defers to the various other specs for
information about conventional/standard interpretations.

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

> It seems the W3C is ignoring the consensus on this issue that was reached at
> great expense by the IETF's Working Group. If you want to reconsider that
> consensus and put out an updated spec, I suppose that'd be acceptable, but
> simply sticking your nose up at the decision and going against what it says
> doesn't seem like reasonable behavior for a standards body the caliber of
> the W3C.

Which decision?
This looks like more baseless rhetoric.


> If we're dealing with URIs and URI-refs, I consider them to be defined by
> the URI RFC. It defines URIs quite well, but throws URI refs to the dogs, it
> seems. I've been over the details with you several times on IRC, but I
> suppose I can repeat myself if it's so necessary.

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

> Even for all your pleas to just see the Model Theory draft it simply dodges
> the question, saying that "It treats URIs as simple names". It also claims
> that it's dealing with URIs[RFC2396], when it plainly is not. I don't see
> how the Model Theory helps matters. It seems to only make matters worse.

I am not dodging the question on purpose, but I can't claim
to be answering it head on, because I'm still not sure
I understand it.

> >> Basically, RDF isn't compatible with the rest of the (non-W3C) Web.
> >
> > I see repeated claims of that; I see no justification, however.
> > This is called "argument by assertion." Two can play
> > at that game: yes, RDF is compatible with the
> > rest of the Web, W3C or otherwise.
> 
> As this point as been made to you a number of times in a number of different
> venues, trying to explain things as best as can, I can only conclude that
> you're playing "argument by not listening". Or as Sean B. Palmer says:
> "emigrating, joining a space program to a planetary body with no atmosphere,
> rocketing off, and then burying your head in the ground with your fingers in
> your ears and screaming 'nur nur nur, I'm not listening'". ;-)

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

Yes, the point has been claimed to me many times. No,
I don't see any justification.

> [ This is not meant to imply Sean B. Palmer's position on either side of the
> issue. ]
> 
> >> I guess another solution would be to just rename RDF to be Random
> >> Description Framework or something, and not claim that the things it
> >> described were Resources.
> > I still don't see the problem for which this "solution" is needed.
> 
> I'm not sure what else I can do to open your eyes.

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'm rather tempted to
> say, "Denial is more than just a river in Egypt" but I sense it's at the
> bounds of polite discourse.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 7 December 2001 00:14:09 UTC