Re: RDF query and Rules - my two cents

On Wednesday, Nov 19, 2003, at 19:53 Europe/Helsinki, ext Aredridel 
wrote:

>
> On Wed, 2003-11-19 at 08:40, Danny Ayers wrote:
>>> Well, having a deployment platform that is sensitive to efficiency
>>> issues (i.e. mobile phones), I'd just as soon not leave such issues
>>> for "later work".
>>
>> Fair enough, but wouldn't this route lead straight to a binary 
>> serialization
>> of RDF?
>>> Use the existing web architecture, definitely. Trying to extend/bend
>>> the semantics of the existing verbs, no.
>>>
>>> If you're not familiar with URIQA, have a look at
>>> http://sw.nokia.com/uriqa/URIQA.html
>>> to see how I've been approaching this problem.
>>
>> If you can GET why is there a need for MGET?
>

Because with GET, you have to know the specific name of a specific
service interface on a particular server (whether the web authority
server or other).

With MGET, all you need is the URI. Nothing more. No registries. No
trying to figure out how the server is organized. No concerns about
which service, and which protocol of that service, etc. etc.

It makes the SW as simple as the web. On the web, if you have a URI
and want a representation, you just GET it.

On the SW, if you have a URI and want a description of the denoted
resource, you just MGET it.

*And* there is no ambiguity between the semantics of GET or MGET,
and if the server is not SW enabled, you get back a status code
indicating the MGET method is not understood/implemented rather
than possibly some other representation that is not the description,
yet might even be RDF/XML! This is why extra headers in the request
don't work well, because it ends up being a fragile hack that
often works, but when it fails, you can't always be sure that it
did. E.g. imagine if {URI} denotes an RDF/XML instance and you
want a description of that instance. If you used a header rather
than a distinct verb, e.g.

GET {URI} HTTP/1.1
URI-Resolution-Mode: description

and the server had no idea what the header URI-Resolution-Mode:
means (or the header gets lost in transit due to some misbehaving
proxy, etc.) the you'd likely get back RDF/XML yet have no clear
way to know if it was the description in RDF/XML or a representation
in RDF/XML.

In short, the SW needs a solid architecture, with clear points of
failure, not hacks that work for toy systems or tightly controlled
closed systems.

The only means I've been able to come up with to provide this are
a set of distinct verbs with explicit semantics that neither
impact the functionality of the current web architecture, nor
introduce ambiguities into web or SW behavior.

If someone things they have a better solution, please speak up.
But using the existing verbs with just adding headers does *not*
work (and even more serious issues than above arise with PUT and
DELETE, but I won't go into that here).

> Agreed.
>
> The biggest problem with MGET is:
>
> 	What do you do when you want metadata about metadata?
>
> MMGET? MMMGET? MMMMMGET?


This is not a problem. This has been covered countless times in
detail on this and other lists. Google for MGET and read up.

Still, in a nutshell...

A properly behaved web server (or SW server) will provide the distinct 
URI
denoting the representation/entity returned, and that can then be used
for subsequent MGETs. So

MGET {URI1} HTTP/1.1

returns a description of the resource denoted by {URI1}, which in its 
response
header specifies {URI2} which denotes the description returned. If you 
want
then a description of the description, you do

MGET {URI2} HTTP/1.1

which returns a description of the description denoted by {URI2}, which
in its response header specifies {URI3}, etc. etc. etc.

But not only is this not a problem, it's a pretty narrow corner use
case IMO. And, it's not a problem.

Regards,

Patrick

Received on Thursday, 20 November 2003 02:07:29 UTC