RE: RDF query and Rules - my two cents

On Thursday, Nov 20, 2003, at 20:39 Europe/Helsinki, ext Danny Ayers 
wrote:

>
>> Well, what happens when that description is available in RDF/XML,
>> N3, N-Triples, XTM, HTML, etc.???
>>
>> Do we have a parallel set of mime types, such that for any mime type
>> x/y we have x/y-description?
>>
>> Or do we just forbid any other encoding than RDF/XML?
>>
>> I don't find either option the least bit appealing.
>
> 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.

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.

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.

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!

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

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.

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

>> Maybe the above comments, then, were useful to that end.
>
> I'm certainly clearer about the issues, so thanks for that.

You're most welcome.

Cheers,

Patrick

Received on Friday, 21 November 2003 04:05:36 UTC