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

Re: Comments on /site-meta

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 16 Oct 2008 21:50:33 +1100
Cc: www-talk@w3.org, eran@hueniverse.com
Message-Id: <C755507E-3884-4597-847A-F63528C4373B@mnot.net>
To: Danny Ayers <danny.ayers@gmail.com>

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/
Received on Thursday, 16 October 2008 10:51:14 GMT

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