- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 10 Mar 2004 18:00:55 -0500
- To: Dirk-Willem van Gulik <dirkx@asemantics.com>
- Cc: www-rdf-interest@w3.org, Patrick Stickler <patrick.stickler@nokia.com>, David Powell <djpowell@djpowell.net>
> > I think the extra round-trip is worth the cost, and advocate a
> > "Metadata-Location" header for information resources, and also a "303
>
> this is very much why we so much like DDDS;
>
> -> go in one step from URI -> Resource OR metadata.
>
> -> One can exist without the other OR vice versa.
>
> -> They can have totally disjoint accessor methods or
> protocols; or multiple; i.e. HTTP for the resource and
> z39.50, soap/lsid or http for the metadata.
That makes it sound pretty nice. In fact, it suggests a
strategy: publish your metadata-location via both
(1) an HTTP Metadata-Location header (by adding a line to your
.htaccess or equivalent), *and*
(2) via DDDS (by adding a line to your zone file, or some such)
also,
(3) if the resource itself is represented in RDF, HTML, JPEG, or
another metadata friendly format, you can/should include at
least the metadata-location (and maybe some other metadata) in
the representation itself.
If you do both (1) and (2), clients can use either HTTP or DNS. If
clients try DNS first, they can probably save a few bytes; if they
fall back to HTTP, they haven't lost much.
(Of course your location *might* involved a ".meta" appended to the
name, but I would never assume such a thing. :-)
Do you have an everything-worked-out tutorial on how to use DDDS like
this? (I read some of the DDDS RFC's long ago. I'm looking for
something rather different here.)
-- sandro
Received on Wednesday, 10 March 2004 18:00:40 UTC