[uf-discuss] Canonical hCards (was: Search on CSS element)

Tantek Ç elik tantek at cs.stanford.edu
Tue Jan 23 17:00:09 PST 2007

On 1/23/07 3:51 PM, "Scott Reynen" <scott at randomchaos.com> wrote:

> On Jan 23, 2007, at 4:09 PM, Tantek Çelik wrote:
>> Document Examples in the Wild first of people linking to their and
>> others'
>> hCards, and that will drive the scope of the solution.
> Does this need to be limited to hCard?

It doesn't *need* to be no, but in the interest of "solve a specific
problem" (principle #1 [1]), let's solve this for hCard first, with real
world hCard examples driving the design.

> I think identifying pointers
> to a canonical source of data is a broader problem, as copying and
> manipulating data between sites is a standard activity on the web.

Agreed.  However I find that the specific types of data may have specific
canonicalization semantics that we should be careful not to accidentally
overlook (we may choose to later overlook them explicitly in the interest of
creating a building block that can be used across formats, but that should
be an explicit decision, not an incidental one).

> Any search engine is full of links back to canonical sources.

Actually I find that most search engines are full of links back to
*multiple* sources of often the same thing without any semantic on
canonicality presented or implied.

> Trackbacks are links back to canonical sources.  Bloggers quoting
> each other typically link back to canonical sources.  Pingerati has
> three links back to canonical sources of what could be abbreviated
> hcards (fn only), and right under that is the same thing for events
> and reviews.  Can we expand the types of examples we're looking at?

None of those examples given are actually "canonical" sources, they're
merely citations and quotations of sources (for which we have existing HTML
semantics for: <cite> <q cite> <blockquote cite>.  The semantic of
canonicality is not necessarily implied, only that the content came from
somewhere else, not that that somewhere else is the best / most
representative (i.e. canonical) instance of that content.



[1] http://microformats.org/wiki/microformats#the_microformats_principles

More information about the microformats-discuss mailing list