RE: RDF query and Rules - my two cents

> > It would only be needed for the description in RDF, so that only means
> > around 3 extra mime types. This has to be weighed against
> > reconfiguring the
> > web.
> >
> I think this view is a bit too constrictive, and (forgive me) short
> sighted. We don't know what other encodings we may wish to be able
> to deploy 5 or 10 years from now.

The same applies for MGET etc.

> I am opposed to the purposeful introduction of ambiguity, blurring
> the distinction between encoding and semantics.
> Why not suffix dates to MIME types to indicate we only want
> representations modified after the specified date? How about
> language, etc. etc.

Because there isn't any pressing need for those. But to turn the argument
back, this would call for DGET and LGET methods...

> And even if one is able to figure out how to reliably parameterize
> GET requests, PUT and DELETE bring far greater problems into the
> mix.

I'm sure they do. But I believe you've done the bulk of this work already in
URIQA, in particular the parameterised queries for GET etc you have
(shadowing MGET etc).

> If we can work all this stuff out without new methods, so that things
> work with single system requests, I'm all for that -- but in my
> experience,
> it's one rat's nest after another...
> >> It's really just a variant of the URI-suffix approach. E.g. append
> >> _META or such to the end of any URI to get the URI that denotes its
> >> metadata description.
> >
> > Yes, as is MGET, except there the switch is shunted even further back
> > into
> > the machinery.
> But that's where it belongs!

That's a debatable point. The Concise Bounded Resource Description of a
resource could be seen as simply just another representation of that

> URIs are the domain of the application designer, not the architecture
> and architectural machinery should not mandate how URIs should be
> constructed.
> > I agree this looks on the surface a more elegant approach,
> > but if the current web can be used without breaking anything, then I
> > think
> > that should be the preferred approach.
> I agree. I agree. I agree. But over a *year* of work has proven to
> me (at least) that this cannot be done -- either at all, or at best
> not easily, without introducing many real or potential ambiguities
> or reinterpretations of the present web architecture.
> So if you want to see the SW implemented with minimal impact on the
> existing web, you should be happy to see new methods such as MGET,
> MPUT and MDELETE which keep segregated the implementation, deployment,
> interpretation, and behavior of web versus SW applications while
> *still* allowing both web and SW applications to share as maximal
> an intersection of infrastructure as possible.
> MGET, MPUT, and MDELETE have a very specialized, focused role relating
> to the *bootstrapping* needs of the SW, yet all other SW services can
> (and should) be deployed using the existing web methods, GET, PUT,
> etc.

I'd be interested to hear how you'd characterise those bootstrapping needs.

> > (I don't think anything gets broken
> > with the mimetype approach, the description can be considered just
> > another
> > representation of the identified resource).
> >
> >>> I'd be grateful for an example of how this is different with MGET, it
> >>> sounds
> >>> like there's something I'm not grokking here.
> >>>
> >>
> >> See above. I.e. a description can have multiple representations...
> >
> > Ok, so perhaps the mimetype approach isn't the best, but I still hold
> > out
> > hope for an approach that doesn't need lowish-level rewiring.
> >
> Great. Tell us how it's done. I've invested more than enough time
> towards
> such an approach and don't intend to spin my wheels indefinitely over
> it.
> I've got real systems and solutions to build and deploy.
> If someone else is able to figure it out, great, more power to them, but
> I'm getting pretty tired of folks saying "I don't like that" or "it
> would
> be better another way" and not giving folks "in the trenches" any
> benefit
> of the doubt when it comes to challenging the religious matras of REST
> without providing the code to back it up. Even those who challenge the
> status quo might be strong advocates of minimal and cautious change
> (I being one of them).

Ok, I have been questioning the need for the new verbs, but I can't do the
issue justice - I'd suggest this issue gets passed to a WG, with more hours
to focus on it.

> Not to take it out on you, personally, but the bottom line is, code
> talks
> (even psuedocode ;-)
> *Show* me a solution that doesn't introduce new verbs, that
> 1. works for GET, PUT, and DELETE operations
> 2. does not require any additional knowledge other than the URI alone
> 3. doesn't fall into the various semantic rat's nests that lurk about
> and I'll be impressed, and will (probably) willingly and happily
> support it.

If a client wants the description, it includes in the header:

Accept: application/rdf+xml-description

and does a HEAD, and if it sees

Content-Type: application/rdf+xml-description

it can carry on and GET the description, anything else is a failure.

If the client wants the full representation, it includes in the header:

Accept: application/rdf+xml

The description is the Concise Bounded Resource Description as described in
URIQA, in fact everything else follows URIQA, only with the alternate mime
type used along with existing verbs.

> In the meantime, I've got work to do...

I'm sorry if you got the impression I was trying to devalue the work you've
done, quite the opposite, I think it's very worthwhile. I'm still not sure
it's what's needed to bootstrap the Semantic Web, but I'm pretty sure it's
all that's needed to bootstrap a WG on a remote API for RDF.

I'd better get some work done too...


Received on Friday, 21 November 2003 05:23:00 UTC