- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 9 Mar 2004 13:26:23 +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:45, ext Dirk-Willem van Gulik wrote: > > --DS-5024760632041367167 > > > On Mar 9, 2004, at 11:39 AM, Patrick Stickler wrote: > >> On Mar 09, 2004, at 12:31, ext Dirk-Willem van Gulik wrote: >>> On Mar 9, 2004, at 11:21 AM, Patrick Stickler wrote: >>>> On Mar 09, 2004, at 12:05, ext Dirk-Willem van Gulik wrote: >>>>> 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 ? >>> .. >>>> 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. >>> >>> Ok -- so the client MUST be modified in that case - i.e. on needs >>> to add code to do 'MGET' instead of 'GET' if the client wanted a >>> description of the resource denoted by the URL. >> >> I think we are talking about different levels of "modification". >> > Sure - I just wanted to get things 'right' - as I mention in the > summary > document similar 'changes' which really amount to looking for > a header or fishing out some URL for the other options. > > One of the big advantages of the MGET change is that there > no change of semantics; totally orthogonal way of signalling > that you want metadata while -everything- else is kept the same; > just an extra 'if' and 'MGET' in your code which formulates > the HTTP request next to the 'GET' you already have. Right. And one can use standard web techniques such as for conneg, authentication, etc. (though there does seem to be some work still to be done regarding proxies and caches to optimize use of URIQA). Another nice advantage, and one that I plan to implement soon, is that one need not update every web server in a network subdomain to natively support URIQA, but one can create/update a proxy server to monitor for URIQA requests and redirect them to a centralized knowledge portal, via which descriptions of resources with URIs grounded in that domain can be accessed. This is really just a generalization from the server level to the proxy level of the way things are done in the present URIQA implementation used within Nokia. Cheers, Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Tuesday, 9 March 2004 06:29:17 UTC