Re: RDF query and Rules - my two cents

On Thursday, Nov 20, 2003, at 16:30 Europe/Helsinki, ext Bill de hÓra 
wrote:

>  Essentially the counter is that such agents and servers would do 
> better to bend to the existing infrastructure than vice versa.
>

Bend, yes, but not break. I consider the kind of overloading that is 
needed
for SW functionality to be unacceptable -- and even then, it still 
doesn't
work as it fails to capture that essential distinction between 
representations
and descriptions (such that when a representation *is* a description, 
nasty
stuff happens).

>> But REST is about representations. The SW can be very RESTful yet
>> still have special needs, and hence extensions, that are out of
>> scope for REST.
>
> Nonetheless, I'd be interested in what the REST folks think about such 
> limitations with respect to descriptions.
>

Well, I've been discussing these issues for quite a long time in
this and other forums, so they've certainly had plenty of time
to offer their comments...

>
>
>> Then it doesn't. If the server doesn't understand the WebDAV
>> methods, then you can't interact with it in that fashion. If
>> it doesn't understand the SW methods, then you can't interact
>> with it in that fashion.
>> That's how extensions work, right?
>
> Put it this way; if it's that simple, why do we worry about having a 
> minimal and uniform interface constraint for the web?
>

To minimize implementational burden and variability in behavior.

For scalability, portability, and interoperability a minimalist view
is optimal -- and I hold such a minimalist view. But when the minimum
isn't enough, you need to expand it. Ideally, that can be done in a
clearly modular fashion so that the core remains consistent, and the
extensions are applied where needed.

I see the URIQA (and WebDAV) extensions as the right way to keep that
core to an absolute minimum while still being able to address *real*
needs that are not met by that core in an optimal manner.

Ideally, web and SW applications will be defined in terms of the core
architecture, or, failing that, in terms of as few extensions as 
possible,
so as to maximize their portability and utility.

>
>>> I did miss it. Links?
>>>
>> It was discussed in length on this list around the beginning of
>> the year. I could dig out the code from my drawer of backups, though
>> I think that the use cases I've outlined are sufficient for 
>> demonstrating
>> the flaws in that approach.
>
> I can dig that out, thanks. But some questions:
>
>  - was there any suggestion of an RFC for the new method?

No. I've been planning to. Honestly, I've simply been too busy with
my "day job" to publish formally on this, but I've published several
web pages and participated in numerous discussion forums presenting
these ideas and solutions. A more formal publication, is, I agree,
needed and rightly expected.

>
>  - has this specfic issue been raised with the TAG?

It has. I'd have to dig out the links...

>
>  - do any pertinent W3C IG's have a position on this?
>

Good question. I'll let them speak for themselves.

>
>> And if I or others who share these views fail to convince the
>> web community, then we SW folks can simply deploy our extended servers
>> and those who don't care about that "narrow usecase" can just ignore 
>> us.
>
> Well sure, do what you want.
>

I continue to be very busy doing just that ;-)

Cheers,

Patrick

Received on Friday, 21 November 2003 03:38:23 UTC