I find it to be an interesting idea, though I strongly suggest that
such a sitemap should be optional, and user agents should crawl the
entire site when no such sitemap exists.
Historically, sitemaps serve several very specific purposes:
Provide links to orphan pages
Exclude sites which the author does not want indexed (as in robots.txt)
Provide an index page for users
It would seem to me that a sitemap would not allow significantly more
rapid discovery of microformats than simply crawling the site
normally, and looking for supported root classnames. you face the
problem of a sitemap becoming out of synch with your content, and
thus missing out on newer or forgotten content due to an out of date
TOC. To solve that problem you end up maintaining two versions of the
data, and you've eliminated one of the key benefits of microformats,
namely only having to maintain one source of data.
On the other hand, looking at it from a user centered, and search
engine point of view, having a sitemap is good practice anyway, and
if you're going to maintain one for the benefit of a search engine,
why not have a standardized "best practice" for marking one up? Such
an index could not only contain the links to all the pages on your
site, but also rel="nofollow" links for sites that you don't want
indexed, links to all the feeds on your site, and some kind of meta
data format which perhaps indicates whether a link contains
microformats. I suggest such data should not be relied upon, but
should instead inform a weighting mechanism such that pages indicated
as containing microformats are crawled first in the queue, allowing a
more responsive experience in any UA which implements this. Another
possible choice is to use such links to present a menu of options to
the user, to allow more discriminating selection of microformat content.
To this end, a good place to start would be to look to existing
sitemaps, including google's sitemap xml markup, and the markup
contained in various websites accross the net which contain sitemaps.
On Mar 24, 2006, at 1:16 PM, Phil Haack wrote:
People do read Microformat content directly which I understand. It
fits
with the "Human First" principle.
But references to the xmdp profiles are in the <head> element which
is NOT
human readable. So there is precedent for non-human readable
discoverability mechanism within Microformats.
At Mix06, Tantek pointed out that listing all the xmdp profiles
that a site
used on a homepage could get unwieldy.
I suppose if I wanted to help both people and an aggregator find
various
Microformats of interest, there could be a microformat for a site
index. My
homepage could include it or simply link to it using some other
microformat.
Thus for the human, there would be a simple link to follow <a
href="/siteindex/" rel="siteindex">Site Map</a>. Likewise, my
aggregator
would look for this if it didn't find the xmdp profile for a
sitemap on the
current page.
I think this might be useful so aggregators (and users) don't have
to crawl
an entire site.
Has there been any work done in this area? Is it a bad idea?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Scott
Reynen
Sent: Friday, March 24, 2006 11:50 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] Enumerating Microformats on a Page
Because feed auto-discovery links are in the content, not the headers
of HTTP responses, aggregators have to download the entire page, and
most aggregators search first for <link type="alternate" ...> tags,
and second for something like <a href="something.rss">RSS</a>. The
link tag makes more sense here because people don't read feeds
directly, so it doesn't make a lot of sense to provide human-readable
<a> links to feeds. But people *do* read microformat content
directly, so if it's related to the current page, it should be linked
from the current page, and any human or machine looking site-wide for
microformat content (or anything else) should follow links throughout
the site.
Peace,
Scott
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
