- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 9 Mar 2004 12:21:42 +0200
- To: "ext Dirk-Willem van Gulik" <dirkx@asemantics.com>
- Cc: www-rdf-interest@w3.org, "ext Seaborne, Andy" <andy.seaborne@hp.com>
On Mar 09, 2004, at 12:05, ext Dirk-Willem van Gulik wrote:
>
> --DS-2454287667696959386
>
>
> On Mar 9, 2004, at 10:37 AM, Patrick Stickler wrote:
>
>> URIQA imposes *no* modifications to existing HTTP clients. All
>> enhancments are
>>
> I must be missing something fundamental. HOW does the client, who
> needs data
> -about- the URL, i.e. the RDF, fetch that data ?
Note that the client is not asking for "data -about- the URL", but
about the resource denoted by the URI (URL).
A client has a URI, which denotes some resource. The client wants a
description of that resource. The client executes an MGET request
to the web authority of the URI, and (hopefully) gets back an
authoritative description of the resource denoted by that URI.
Thus, if the client wanted a representation of the resource denoted
by a URI http://example.com/foo, it would submit a request
GET /foo HTTP/1.1
Host: example.com
If that client wanted a description of the resource denoted by the
URI http://example.com/foo, it would submit a request
MGET /foo HTTP/1.1
Host: example.com
Note that the only difference is the method used, and specifying
the request method is part of the core HTTP client architecture.
If the URI in question contained a fragment identifier (and in
general, I advise against URIrefs with fragids for denoting
resources), then one can use the URIQA-uri: header to indicate
the full URI denoting the "secondary" resource in question.
But again, specifying additional headers is part of the core
HTTP client architecture.
This, URIQA imposes *no* modifications to existing HTTP clients
(insofar as architecure, APIs, SDKs, etc are concerned).
Patrick
--
Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com
Received on Tuesday, 9 March 2004 05:22:07 UTC