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

Re: Comments on /site-meta

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




2008/10/16 Mark Nottingham <mnot@mnot.net>:

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

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

Cheers,
Danny.

-- 
http://dannyayers.com
~
http://blogs.talis.com/nodalities/this_weeks_semantic_web/
Received on Thursday, 16 October 2008 20:23:55 GMT

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