W3C home > Mailing lists > Public > www-talk@w3.org > September to October 2008

Comments on /site-meta

From: Danny Ayers <danny.ayers@gmail.com>
Date: Thu, 16 Oct 2008 10:39:46 +0000
Message-ID: <1f2ed5cd0810160339k23669363hc57b9d064c267101@mail.gmail.com>
To: www-talk@w3.org, "Mark Nottingham" <mnot@mnot.net>, eran@hueniverse.com




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].

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.

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].

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/
Received on Thursday, 16 October 2008 20:23:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:29 GMT