W3C home > Mailing lists > Public > www-tag@w3.org > February 2004

RE: HTTP Methods

From: <Patrick.Stickler@nokia.com>
Date: Sat, 28 Feb 2004 22:02:08 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B02A2E997@trebe006.europe.nokia.com>
To: <algermissen@acm.org>, <www-tag@w3.org>
Cc: <www-tag@w3.org>

-----Original Message-----
From:	www-tag-request@w3.org on behalf of ext Jan Algermissen
Sent:	Sat 2004-02-28 21:37
To:	www-tag@w3.org
Cc:	www-tag@w3.org
Subject:	Re: HTTP Methods



Patrick--

I am curious: since a lot of representations already contain
metadata about the resource they represent....are servers
expected to return that metadata for an MGET to the resource?

In other words...would servers be expected to return what's
usually in <meta> and <title> tags for an MGET on a URL that
refers to an HTML page?

            URIQA does not specify how resource descriptions are managed.
            If a server owner decides that extracting META tagged content
            from HTML instances is an optimal way to respond to an MGET
            request, fine. URIQA is completely agnostic about the implementational
            details (just as each server implementation decides for itself how to
            respond to any HTTP method).


I also wonder why an application that was interested in metadata
about a resource would not usually also want to look at
a representation of the resource itself (likely that there is
interesting information in there). 

             Because most representations are not meaningful to sofware agents.

             The (successful) results of an MGET request are explicitly defined
             and machine understandable per the RDF model theory.

             It is true that a representation can contain RDF, but that doesn't mean
             that any statement in that RDF describes the resource itself. The resource
             could in fact be an RDF description about some other resource! Thus,
             the distinction between description and arbitrary representation is crucial.

I really don't think that MGET
would in reality prevent two requests (one to the resource and one
to the metadata).

             Right. A description is a resource in its own right, and can be denoted
             by a distinct URI. So

             GET {URI1} 
             -> representation of resource denoted by URI1

             MGET {URI1}  
             -> description of resource denoted by URI1 (description denoted by URI2)

             GET {URI2}  
             ->  representation of resource denoted by URI2 
             (may be the same as for MGET {URI1}, or some other representation per conneg, etc.)

             MGET {URI2}  
             -> description of resource denoted by URI2 (description denoted by URI3)
              (i.e. description of description of resource denoted by URI1)

             etc.

             Cheers,

             Patrick

          

Jan


-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org
Received on Saturday, 28 February 2004 15:02:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:03 UTC