RE: Proposed issue: site metadata hook (slight variation)

> -----Original Message-----
> From: ext Jeffrey Winter [mailto:JeffreyWinter@crd.com]
> Sent: 12 February, 2003 16:13
> To: Stickler Patrick (NMP/Tampere); miles@milessabin.com; 
> www-tag@w3.org
> Subject: RE: Proposed issue: site metadata hook (slight variation)
> 
> 
> 
> > 1. Can HTTP/REST be redefined so that GET + Meta: can 
> return something
> >    other than a representation?
> 
>     I think you'd have a really hard time getting acceptance on that
> one.  

That is a pity, since if it could be done, then the Meta: approach
seems rather attractive.

But if not, then new methods seem at the moment the only reasonable
approach.

>     I'd still prefer to see something that made the request 
> through the
>     OPTIONS method, and since OPTIONS can take an entity body, more 
>     complex requests could be defined (for getting robots info etc.)
> 
>     If conventions are to be applied, it would seem more palatable to
>     apply them to the OPTIONS method since it is open for future 
>     extensions.
> 
>       Request:
> 
>         OPTIONS /some-namespace-uri HTTP/1.1
>         Host: whatever
> 
>       Response:
> 
>         HTTP/1.1 200 OK
> 	 Allows:  GET, PUT, POST
>         Meta-Location: /metadata    

But, again, this imposes two system calls to get descriptions
of resources *and* requires the explicit naming of those
bodies of knowledge, which is unnecessary.

Also, we need to be able to PUT and DELETE metadata, not just
GET it, so it seems to me that overloading OPTIONS to support
all that semantics is begging for headaches.

Either we have parallels such as

Web: GET        PUT        DELETE
SW:  GET+Meta:  PUT+Meta:  DELETE+Meta:

or 

Web: GET        PUT        DELETE
SW:  MGET       MPUT       MDELETE

But some sort of parallel such is this is needed, and
one which keeps distinct representations of the Web
from descriptions of the Semantic Web.


>     The meta-meta issue isn't a problem if OPTIONS returns a
> Meta-Location:
>     header to another resource. 

The meta-meta issue isn't a problem, period. For any of the
proposals put forth in this thread.

My hope is that the answer to this question can still be 'yes'...

> > 2. Can the Meta-Location: tag be optional, if the server 
> > owner does not care to name that body of knowledge explicitly?
> 
>    I would think it would have to be.  Fielding took issue with that
>    header always being there in a message to rest-discuss [2].  This
>    would really only be an issue if you tried to ride along with the
>    GET response though; OPTIONS response wouldn't be as frequent.

I'll take this as a vote for 'yes'.

> > 3. Can the Meta: tag be specified with no parameter to 
> > indicate a default RDF/XML encoded response?
>   
>     In my example above, I used an Accept header, do you 
> think that this
>     would be a better alternative?

Well, I think we need a constrained and specific trigger to
"switch" from web behavior involving representations to semantic
web behavior involving descriptions. The single Meta: tag seems
to be an efficient means to do this. But it's the switch I'm
after.

> > 4. Can that default RDF/XML response be, by formal definition, a 
> >    concise/bounded description consisting only of statements having
> >    the specified resource as subject, and recursively, for each
> >    blank node object, all statements with that blank node 
> as subject?
> > 
> >    [it would be *possible* to ask for and return a RDDL 
> instance that
> >     is a gross superset of or even disjunct with the body 
> of knowledge
> >     about the resource, but that would not be the default response]
> >
> > 5. Can the semantics of PUT and DELETE (at least) also be 
> modified to
> >    take the Meta: tag and thus allow the manipulation of knowledge
> >    on the server (permissions allowing, of course)?
> 
>     If the metadata is it's own resource, this shouldn't be a problem.
> Or
>     am I missing something here??

Yes. There's no need to explicitly name bodies of knowledge about
a resource in order to interact with them. They're like blank
nodes in RDF. One can MPUT or PUT+Meta: a body of knowledge to
a server, and that is added to the total body of knowledge known
by the server. It is in that way different from PUT in that it
does not completely replace it but merely adds to it. Likewise,
if one MDELETEs or MDELETE+Meta: a body of knowledge, only that
body of knowledge is removed from the server, not all knowledge
about the resource.

It is this special treatment of MPUT and MDELETE that IMO warranted
distinct methods from PUT and DELETE, since they deal with partial
modifications of the resource description. But maybe PUT+Meta: and
DELETE+Meta: can be defined to accomplish the same result.

It's important to note that when one does

   MPUT /some-resource-uri HTTP/1.1

one is not doing a PUT on the resource corresponding to the body
of knowledge known about the designated resource -- rather one is putting
(adding) knowledge about the designiated resource to the server. The 
above does not equate to either

   PUT /some-resource-uri' HTTP/1.1
or 
   PUT /some-resource-uri/MGET HTTP/1.1

The same for MDELETE or DELETE+Meta:

Cheers,

Patrick

Received on Wednesday, 12 February 2003 09:45:02 UTC