Re: Comments on /site-meta

2008/10/16 Mark Nottingham <>:

Hi Mark,

>> 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="" />
>> or
>> <rdf:Description rdf:about="">
>>  <x:siteMeta rdf:resource=""" />
>> </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

Fair point.

> (or at all, in the case of resource-constrained use cases).

I don't get that - do you have an example of such a use case?

> Remember, conneg can't be used to get something fundamentally different; it
> needs to be a representation of the *same* resource.

Yep, but I don't think that's particularly relevant - usual conneg
rules apply, but representations of the root namespace resource MAY
contain a link to the metadata doc.

> 2) The step of indirection is a deal-killer for some users.

For example..?

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

That does seem neater, I guess link header could be in the frame for
that. Not slam-dunk though.

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.

Do you happen to know if robot.txt has any extension points (or could
be viably revised)? (Got a presentation to prep last minute or I'd go
look :-)

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

Ok, fair enough.

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

That sounds reasonable, though it would be good if an agent could make
some sense of the doc without prior knowledge - which is a point, the
current proposed format doesn't have an XML namespace, which pre-empts
any chance of follow-your-nose discovery (a la GRDDL).



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