Re: draft: Requirements for Any Theory of 'Information Resource'

I appreciate your comments. Sorry I got hotheaded and you're right
that I wasn't fair. It's important to me to have an open line to
someone who's not a member of the choir. I think one or both of us has
unsurfaced assumptions, and that those assumptions are the crux of the
argument. I think we're close to pay dirt so I hope you'll continue
this with me. I'm confident that there is something important to be
learned.

I too have spent years struggling to make RDF work in ways that
"fulfill its potential" and have consequence, which is why this
threatened invasion is so troubling to me. The frustration is not so
much the suggestion that the design needs to change; this can be
assessed through some rational process. My gripe is with the attitude
that it doesn't matter whether it does change.

I think I'm a technical conservative - I don't like to make
incompatible changes, because there may be some hidden dependency, and
I don't want to risk being held accountable for the failure of someone
else's system. I expect others to be the same way, and that
expectation has been dashed.

I think I've already mentioned the application that breaks without
httpRange-14; it's the CC license chooser. I'd be very surprised if
there weren't others, but I would also *not* be surprised if no one
came forward to promote or defend them - because it wouldn't occur to
many people to question the idea of using dereferenceable URIs to
refer to their {documents, IRs, ...}. I'm not dogmatic; I'm willing to
go back to my colleagues and say, hey this isn't going to work, we
need to retool to defend against this other use of those URIs, and I'm
willing to write tutorials that tell RDF users how to refer safely to
documents, but I'm going to need a much more solid story than the ones
I've heard so far, since the status quo design supports goals I care
about and applications that I'd *like* to write.

And I've given up on looking for a definition for 'information
resource', but I think we don't need one. A definition would help
interop in general but isn't needed for the particular use case I
think is most important (designating the subject of metadata and
citation). A set of axioms should suffice, allowing everyone to make
up their own definition, just as they do now. That's the whole idea
behind entailment - interpretation of non-operational terms shouldn't
matter as long as the axioms are respected.

In my writeup I'm going to flag the 'doesn't have momentum' axiom as
optional. It helps rule out nonsense, but isn't really needed for my
use case, and it interferes with two of the solutions I've catalogued,
the "chimera" interpretation (similar I think to your two-namespace
idea) and the "we don't need inference" interpretation.

I'll also add "change RDF semantics" to my list of options.

Maybe a phone call would work better - we've each got arguments with
ten or fifteen steps and these are hard to work through in email.

Jonathan

Received on Thursday, 17 February 2011 13:14:08 UTC