W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2004


From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 15 Mar 2004 13:29:14 +0200
Message-Id: <FD3ED5B8-7673-11D8-A711-000A95EAFCEA@nokia.com>
Cc: www-rdf-interest@w3.org
To: "ext Phil Dawes" <pdawes@users.sourceforge.net>

On Mar 15, 2004, at 12:37, ext Phil Dawes wrote:

> Hi Patrick,
> Patrick Stickler writes:
>> Fair enough. The challenge, it seems, is to provide web server
>> implementations to "basic" users which allow them to define their own
>> descriptions independent of writing code -- yet at the same time
>> provide for the scalable management of resource descriptions by
>> very large information providers.
>> It may be that several approaches will have to compete, and
>> the best approach will become evident from real-world use.
>> To that end, I'm considering making the reference implementation
>> for URIQA a "hybrid" -- whereby both the new methods would be
>> supported, as well as the special header approach which would
>> be obtained by first issuing a HEAD request, and then the
>> explicitly identified description accessed using GET/PUT/etc.
>> Agents can then decide...
>> Patrick
> The other possible solution would be if e.g. PURL.org supported an
> MGET to GET mapping. Users could then define terms under the PURL
> namespace and have their terms mapped to GET requests (using a
> well-defined RULE) to their hosting provider.

This is certainly one possible "collective/cooperative" deployment
of the URIQA model. And in fact, it would reflect exactly how
it is done by the Nokia implementation, which simply redirects
MGET requests to a URIQA service query portal.

> Of course this would mean that people without access to MGET capable
> servers wouldn't be able to use their own domain names to mint terms,
> but it may provide the appropriate bootstrap to encourage hosting
> services to add MGET support in the medium term.



> Cheers,
> Phil


Patrick Stickler
Nokia, Finland
Received on Monday, 15 March 2004 06:29:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:48 UTC