Hi Danny,
On 16/10/2008, at 9:39 PM, Danny Ayers wrote:
re. http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-00.txt
Regarding the general approach I'm not convinced that "pre-empting an
authority's URI namespace" is a "necessary evil". I'm sure you are
aware of the primary argument against using well-known names in this
way [1].
Yep, that's referenced in the draft :) I'd note that the W3C has
included at least one well-known location in a Recommendation, for
lack of any better mechanism.
A possible alternative would be to include a link in the root
namespace document pointing to the site-meta document.
i.e. client GETs:
http://example.com/
depending on conneg, the doc returned would contain something like:
<link rel="site-meta" href="http://example.com/site-meta"; />
or
<rdf:Description rdf:about="http://example.com/";>
<x:siteMeta rdf:resource=""http://example.com/site-meta"; />
</rdf:Description>
- thus the URI of the metadata document could be decided by the
publisher. While this approach does add a step of indirection, I
believe it would offer greater flexibility in also allowing sub-path
hierarchies of the site to refer to their own, more local, metadata.
Two problems;
1) If the site has a normal representation there (i.e., a home page),
it could be big, which would be an impediment to clients getting the
metadata quickly (or at all, in the case of resource-constrained use
cases). Remember, conneg can't be used to get something fundamentally
different; it needs to be a representation of the *same* resource.
2) The step of indirection is a deal-killer for some users.
Personally, I'm very tempted by using one or more response *headers*
on the root resource, so you can HEAD for them, but this still
requires more requests than the embedded-in-site-meta approach, and
some people balk at that. Given that the whole idea here is to make
this a slam-dunk solution for the problem (so as to avoid creating any
*other* new well-known locations), it has to have as few points of
friction as possible.
Regarding the document format, it seems reasonable enough, though I
can't help thinking it might be advantageous to define it as an
extension to the Sitemap Protocol [2], along the lines of the
Semantic Web Crawling extension [3].
I'm not a big fan of sitemaps; it's not very flexible, and can only
define metadata for one URI at a time. Frankly, if I were to
implicitly promote an existing format, it'd be Atom (I was tempted to
do this, but came down on the side of creating something simpler; Dave
Orchard always said that the most successful XML vocabularies had 4 or
less elements...) or something like URISpace (but a little less
tortured).
What' I'm *really* wondering at this point is if XML itself is too
complex -- i.e., should this be a line-oriented format? One pre-draft
reviewer already suggested as much.
Cheers,
Cheers,
Danny.
[1] http://www.w3.org/2001/tag/issues.html#siteData-36
[2] https://www.google.com/webmasters/tools/docs/en/protocol.html
[3] http://sw.deri.org/2007/07/sitemapextension/
--
http://dannyayers.com
~
http://blogs.talis.com/nodalities/this_weeks_semantic_web/
--
Mark Nottingham http://www.mnot.net/
