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:

depending on conneg, the doc returned would contain something like:

<link rel="site-meta" href="http://example.com/site-meta" />


<rdf:Description rdf:about="http://example.com/">
   <x:siteMeta rdf:resource=""http://example.com/site-meta" />

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


[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/

Received on Thursday, 16 October 2008 20:23:32 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:30 UTC