Re: RDF query and Rules - my two cents

Patrick Stickler (NMP-MSW/Tampere) wrote:


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

I don't understand the distinction above between the name of a
service interface and a URI. What's the difference?


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

I think I would prefer a name other than MGET (maybe DESCRIBE) and
less talk about web and semantic web. Presumably if the method is 
actually useful, it's useful on both webs.

But still, I don't see the need for separate webs to begin with...


> *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,

I'd be concerned about this a point of architecture. Web resources
are ideally uniform.


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

So you say, but how is partitioning web resources into SW and W any
less of a hack?


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

If you're an agent capable of asking the question, why can't you
look in the RDF/XML to find out the answer? I thought this stuff was
descriptive.

Or why not a header? Below, I understand you're asking agents to do
that for M*GET resolution, but here objecting to using a header to
begin with as a fraile hack.


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

You've claimed this before, but you haven't really demonstrated it
doesn't work.


> 
>> 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.
> 
> [...]
> But not only is this not a problem, it's a pretty narrow corner use
> case IMO. And, it's not a problem.

Well, some might argue that the SW is a pretty narrow usecase for
creating a new verb on the web. WebDAV added new verbs, it didn't
work out so well in retrospect.

Bill de hÓra

Received on Thursday, 20 November 2003 04:49:07 UTC