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

7 views
Skip to first unread message

David Janes

unread,
Jan 23, 2007, 1:22:01 PM1/23/07
to Microformats Discuss
Continuing the tradition of riffing off other threads to talk about
what's on my mind...

On 1/23/07, Ryan King <ry...@technorati.com> wrote:
>
> It's not a full CSS selector based search engine, but http://
> kitchen.technorati.com/contacts/search/tantek.
>

Wouldn't it be great if there was a well defined way of getting from
_an_ instance of a hCard to the _best_ (or canonical) hCard for that
person.

Just saying; I know that some work has been done on this.

Regards, etc...

--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
_______________________________________________
microformats-discuss mailing list
microforma...@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Tantek Çelik

unread,
Jan 23, 2007, 3:27:39 PM1/23/07
to microformats-discuss
On 1/23/07 10:22 AM, "David Janes" <david...@blogmatrix.com> wrote:

> Continuing the tradition of riffing off other threads to talk about
> what's on my mind...
>
> On 1/23/07, Ryan King <ry...@technorati.com> wrote:
>>
>> It's not a full CSS selector based search engine, but http://
>> kitchen.technorati.com/contacts/search/tantek.
>>
>
> Wouldn't it be great if there was a well defined way of getting from
> _an_ instance of a hCard to the _best_ (or canonical) hCard for that
> person.
>
> Just saying; I know that some work has been done on this.

David Janes, you're right, we need to solve this problem.

I did some research on examples in the wild and possible approaches here:

<http://microformats.org/wiki/hcard-brainstorming#hCard_to_hCard_relationshi
ps>

Please take a look and add your thoughts on the problem-space and/or
examples you have found in the wild for each type of "canonicalization"
(there are more than one).

Thanks,

Tantek

David Janes

unread,
Jan 23, 2007, 4:05:28 PM1/23/07
to Microformats Discuss
On 1/23/07, Tantek Çelik <tan...@cs.stanford.edu> wrote:
> David Janes, you're right, we need to solve this problem.
>
> I did some research on examples in the wild and possible approaches here:
>
> <http://microformats.org/wiki/hcard-brainstorming#hCard_to_hCard_relationshi
> ps>
>
> Please take a look and add your thoughts on the problem-space and/or
> examples you have found in the wild for each type of "canonicalization"
> (there are more than one).

Well, strangely enough I do have ideas in this area. I'm going to
outline them here and move them into the wiki tomorrow, in case
there's interesting discussion.

My starting assumptions are:

- no changes should be needed to a hCard that has a "url"
- hinting is allowed, but not needed
- we follow the OpenID model of indirection [1]

The idea works like this:

- a consumer sees a hcard, say

<address class="author vcard">
<a class="url fn" href="http://theryanking.com">Ryan</a>
</address>

- the consumer looks at "http://theryanking.com"

- if the consumer sees a <link> element like the following, it knows
there is a canonical hCard. The title must be the same as the "fn" (?)

<link rel="identity.hcard" title="Ryan"
href="http://theryanking.com/blog/contact/#vcard" />

- the consumer reads this page
("http://theryanking.com/blog/contact/") and finds the canonical hCard
at id "vcard"

Notes:
- if the non-canonical hCard url has a fragment and that points to a
hCard, assume we are done
- if there is no fragment in the non-canonical hCard url, a <link> is required
- if the link does not have a fragment, the first hCard on the page is
the one we use
- I've documented this here [2] (but discuss here please)
- we could add an extra class element, say "canonical" that could be
used in conjuction with the url to guarentee there is a canonical
hCard to be found; I'm not really sure if this is necessary though.

Regards, etc...
David

[1] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2006-09-12-0001/
[2] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2006-09-12-0003/

_______________________________________________

Tantek Çelik

unread,
Jan 23, 2007, 5:09:53 PM1/23/07
to microformats-discuss
On 1/23/07 1:05 PM, "David Janes" <david...@blogmatrix.com> wrote:

> On 1/23/07, Tantek Çelik <tan...@cs.stanford.edu> wrote:
>> David Janes, you're right, we need to solve this problem.
>>
>> I did some research on examples in the wild and possible approaches here:
>>
>> <http://microformats.org/wiki/hcard-brainstorming#hCard_to_hCard_relationshi
>> ps>
>>
>> Please take a look and add your thoughts on the problem-space and/or
>> examples you have found in the wild for each type of "canonicalization"
>> (there are more than one).
>
> Well, strangely enough I do have ideas in this area. I'm going to
> outline them here and move them into the wiki tomorrow, in case
> there's interesting discussion.
>
> My starting assumptions are:
>
> - no changes should be needed to a hCard that has a "url"
> - hinting is allowed, but not needed

I agree with those.


> - we follow the OpenID model of indirection [1]

I disagree because it involves invisible metadata.

We should avoid <link> and MUST avoid <meta> for that reason in
microformats.

> The idea works like this:

Document Examples in the Wild first of people linking to their and others'
hCards, and that will drive the scope of the solution.

Brainstorming will be much better AFTER we have documented examples in the
wild and can then reason using those examples rather than hypothetical
examples.

> - a consumer sees a hcard, say
>
> <address class="author vcard">
> <a class="url fn" href="http://theryanking.com">Ryan</a>
> </address>
>
> - the consumer looks at "http://theryanking.com"
>
> - if the consumer sees a <link> element like the following, it knows
> there is a canonical hCard. The title must be the same as the "fn" (?)
>
> <link rel="identity.hcard" title="Ryan"
> href="http://theryanking.com/blog/contact/#vcard" />

I'm ok with entertaining a new rel value as indicated on
<http://microformats.org/wiki/hcard-brainstorming#hCard_to_hCard_relationshi
ps> but not ok with requiring or requesting use of <link> for this.

Any such links should use <a href> and be visible.


> - the consumer reads this page
> ("http://theryanking.com/blog/contact/") and finds the canonical hCard
> at id "vcard"

This part I believe a reasonable end goal.


> Notes:
> - if the non-canonical hCard url has a fragment and that points to a
> hCard, assume we are done

I don't think that can be assumed, because it is a 3rd party link (most
likely). The 1st party may have changed the fragment at the destination
etc.


> - if there is no fragment in the non-canonical hCard url, a <link> is required

<link> should never be required, and should be avoided.


> - if the link does not have a fragment, the first hCard on the page is
> the one we use

That's a reasonable fallback, but before that, I'd even advocate looking for
the first <address> that is or contains an hCard on the page, since that's
following prescribed behavior from HTML4.


> - I've documented this here [2] (but discuss here please)
> - we could add an extra class element, say "canonical" that could be
> used in conjuction with the url to guarentee there is a canonical
> hCard to be found; I'm not really sure if this is necessary though.

I'm not sure that is necessary either, as the opinion of "canonicality" is
not from an item itself but rather from references to that item which tends
make it more like a relationship rather than just a class.

Thanks David Janes,

Tantek

Scott Reynen

unread,
Jan 23, 2007, 6:51:34 PM1/23/07
to Microformats Discuss
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? 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.
Any search engine is full of links back to canonical sources.
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?

Peace,
Scott

Tantek Çelik

unread,
Jan 23, 2007, 8:00:09 PM1/23/07
to microformats-discuss
On 1/23/07 3:51 PM, "Scott Reynen" <sc...@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.

Thanks,

Tantek

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

Joe Andrieu

unread,
Jan 23, 2007, 9:46:35 PM1/23/07
to Microformats Discuss
Tantek Ç elik wrote

I think we don't mean "canonical" here, and perhaps fixing that will
clarify a use case that distinguishes the opportunity.

Canonical means part of a canon, or of the form of the canon, especially
when used in the sense of converting a morphological entity into an
alternative form. 2007/06/05 and June 6, 2007 both represent the same
date, only one can be canonical for any given canon. We tend to like
ISO as a canon around here. Canonical forms are articularly useful when
sorting, comparing, or looking up things that could be presented in
alternative formats.

What I think is much more useful is /authoritative/ hCards. Meaning
that this is the author's truth for this reference. The authoritative
reference is the root source of the reference. It is close to
definitive, but definitive assumes objectivity, whereas authoritative
retains the subjectivity of the author.

This sense of subjectivity is where hCards can play a huge role. An
authoritative hCard is, in effect, making a claim that it /is/ the
authoritative source for this data. It is not objective truth, simply a
claim by the author.

A few two major things happen when you do this:
1. You enable an hCard author to semantically declare this hCard as
"definitive"
2. You could provide a link from a refering hCard to the authoritative
hCard for discovery of additional information that isn't appropriate for
the design or context of the "refering" hCard.

If an authoritative hCard URL is also a permalink, it could then become
a single point of updates and changes that can suitably propagate out to
the world, a la Linked In.

Furthermore, if the authoritative representation is dated in some way,
one might be able to discern between out of date and current claims to
authority on a topic. (However, I definitely don't regard assertions
about chronological superiority as valid means to disambiguate such
claims; this is definitly a "hypothetical").

And to skip a bunch of other hypotheticals out there, I think it also
doesn't really matter if there are multiple "authoritative" hCards out
there. What's useful is allowing someone to distinguish a claim to
authority for an hCard (say on my website) that is knowably distinct
from simple refering hCards (say on http://projectvrm.org where I am a
contributor; examples follow.) False or duplicate claims to authority
are red herrings. The real value is to say "this isn't authoritive; and
btw, you might go look over there."

So, I think there are two different uses here that actually require two
different solutions.
(1) to be able to indicate a claim that an hCard is authoritative.
(2) to be able to link a "brief" hCard to a source that was considered
authoritative (or even just /more/ authoritative) at the time the brief
hCard was created, in order to provide potentially more up-to-date
and/or more detailed information.

For instance, I currently present my information on my business website
as the authoritative "business" hCard for me and as a result of this
conversation, I've linked to that from Project VRM using hCard
semantics.

(1) my "authoritative" hCard
http://www.switchbook.com

<div class="contact vcard">For inquiries:<br/>
<div class="fn">Joe Andrieu</div>
<a class="email"
href="mailto:j...@switchbook.com">j...@switchbook.com</a><br/></a>
<div class="tel">+1 (805) 705-8651</div>
<a class="url org" href="http://www.switchbook.com"><span
class="switch">Switch</span>Book Software</a>
<div class="adr">
<span class="street-address">2032-A Chapala St.</span>, <span
class="locality">Santa Barbara</span>, <span class="region">CA</span>
<span class="postal-code">93105</span>
</div>
<br/>You may also want to check out my <a
href="http://blog.joeandrieu.com/">blog</a>.
</div>

(2) a reference to it where a full hCard is impractical:
http://cyber.law.harvard.edu/projectvrm/Blogs#Blog_posts_on_VRM

It is in a wiki:

<span class="contact vcard"><span class="fn">Joe
Andrieu</span><nowiki>[</nowiki><span class="url
org">[http://www.switchbook.com/ @]</span></span><nowiki>]</nowiki>

Which generates:
<span class="contact vcard"><span class="fn">Joe Andrieu</span>[<span
class="url org"><a href="http://www.switchbook.com/" class="external
text" title="http://www.switchbook.com/"
rel="nofollow">@</a></span></span>]

And looks pretty much how I want:
Joe Andrieu [@]


With the @ sign the link to the "authoritative" hCard.

If we presume for the moment that http://www.switchbook.com is the
authoritative reference for my hCard in this context, then, I /think/
that addresses use case #2, above, correct? The URL class in the hcard
point to a "more authoritative" hCard, where I have far more information
than fit in the reference at Project VRM.


However, we still have no official way for me to indicate in the hCard
at http://www.switchbook.com that it is an authoritative reference.

Unless we use the self-referencing URL trick to indicate
"authoritative", in which case the current example solves both (1) and
(2). In effect, citing oneself as the "more authoritative" hCard means
that /this/ hCard is the most authoritative available (at the time of
creating the hCard, to the best knowledge of the author, etc.).


Working through this leads me to think that an hCard that exists at its
self-referenced URI should be considered "authoritative."

-j

p.s. I'd appreciate feedback on any errors in the above microformats.

--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651

David Janes

unread,
Jan 24, 2007, 5:36:02 AM1/24/07
to Microformats Discuss
(0)
I agreee with Joe that "canonical" is the wrong word. "authorative" is
better. "best" is too vague.

On 1/23/07, Tantek Çelik <tan...@cs.stanford.edu> wrote:
> On 1/23/07 1:05 PM, "David Janes" <david...@blogmatrix.com> wrote:
>
> > On 1/23/07, Tantek Çelik <tan...@cs.stanford.edu> wrote:
> >> Please take a look and add your thoughts on the problem-space and/or
> >> examples you have found in the wild for each type of "canonicalization"
> >> (there are more than one).
>

> Brainstorming will be much better AFTER we have documented examples in the
> wild and can then reason using those examples rather than hypothetical
> examples.

(1)

OK, I'm not going to get in a pissing match over this but you did ask
what's my _thoughts_ on this.

In any case, can we do this in a non-prescriptive manner - are we not
entering new terroritory here? We know

(a) people want this problem solved
(b) people are not solving this problem because they're waiting for
some to tell them how

Let me ask this: is there a _single_ example out there of what we want to do?

(2)

I disagree with you on the LINK matter, because I think

(a) it's not, strictly speaking, part of the microformat; it's a
description of behaviours to do with a microformat
(b) if they get it wrong, it is unlikely to introduce incorrect data
(i.e. graceful failure)
(c) "home page" (i.e. url) as a directory of sorts using LINK is a
well-understood (OpenID) and well-used (RSS/Atom) concept

However, I'm not going to getting in a fight over this either. No LINKs.

(3)

Do you (Tantek + all) agree with the following "architecture", or it
least think it's worth pursuing further:

(a) hCards without additional markup; "url" is used to lookup a URL
(b) at the URL we can either find:
(b.i) the authorative hCard; OR
(b.ii) a pointer to authorative URL with the authorative hCard
(c) it's easy to find the authorative hCard on the authorative URL

I'm sure we have the technology to to (b.ii), I just don't know if
anyone has done it. Anyone?

The reason I'm asking is I'm more willing to plug work into this, but
not if you've already decided that this approach will not work.

Regards, etc...
David

_______________________________________________

Brian Suda

unread,
Jan 24, 2007, 6:18:41 AM1/24/07
to Microformats Discuss
On 1/24/07, David Janes <david...@blogmatrix.com> wrote:
> Do you (Tantek + all) agree with the following "architecture", or it
> least think it's worth pursuing further:
>
> (a) hCards without additional markup; "url" is used to lookup a URL
> (b) at the URL we can either find:
> (b.i) the authorative hCard; OR
> (b.ii) a pointer to authorative URL with the authorative hCard
> (c) it's easy to find the authorative hCard on the authorative URL
>
> I'm sure we have the technology to to (b.ii), I just don't know if
> anyone has done it. Anyone?

I believe that http://rubhub.com/main/ acts in a similar manner. When
it finds XFN values it continues to crawl those URLs.

In a similar vein, an hCard spider could find hCards in a page with a
URL. They could then follow that URL to the person's page. Then
inspect for hCards. If none are found, it could simply follow all
rel-me links. Since rel-me is published by the author of the page,
[it is a safe asssumption?] that the subsequent requested pages are
also controled by the author. Then hCards could be looked for on those
pages as well. The problem arrises when multiple hCards are
encountered on a page - which is the authorative hCard? This issue is
not a problem with the spider, but with the mechanism to say "THIS
hCard is the one you want" (you suggested an anchor link #vcard), but
using some hueristics, it might be possible to match the URL of the
ORIGINAL hCard that started this spidering, and any hCards found in
the rel-me crawl. If the URLs match, then you could (with some degree
of certainly) collapse the values into a more robust hCard.


For example, if i leave a comment on XYZ blog. It cites me as the
author and uses and hCard.
<p class="vcard">posted by: <a class="fn url"
href="http://suda.co.uk/">Brian Suda</a></p>

So the spider will find my URL in XYZ blog and begin to spider
suda.co.uk for any rel-me links. It finds some onthe homepage to my
contact page and to my publications page. On the publications page it
finds several hCards for various events, organizations, etc. Each of
those is compared to the original from XYZ blog. The FN's don't match,
the URLs don't match - so with a high degree of probablity they are
NOT me. Then the spider visits my contact page. It finds another hCard
(we'll say 2). It compares the first one and the FN's and URLs don't
match. It compares the second one, and the URLs match, the FNs match -
with a high degree of certainly they are the same person and the data
can be merged.

By doing this, we introduce NO new technology or mark-up to find
authoritative data. We are using already existing microformats (XFN),
the data is visible using @rel instead of <link> it allows for the
market to compete and build better spiders.

We also have the lesser used UID to uniquely identify hCards. As we
talked about long ago, UID and URL should be the same thing, if we can
futher develop that idea then comparing and collapsing on URL/UID will
give us an even higher degree of certainty.

> The reason I'm asking is I'm more willing to plug work into this, but
> not if you've already decided that this approach will not work.

--- i think it will work just fine, but i also thing we have all the
tools needed right now.

People 'say' they want this feature, but i don't think they have
explored the possible solutions available currently. If we are going
to try to tell folks to add something like <link rel="id.hcard"..../>
why not just rel-me? that gets us several things at once and solves
this same issue for hCards as hCalendar as hResumes ...

The downside is that i would say for things like X2V or other
hCard->vCard services they should NOT spider links. This would be more
for a social network app that caches the data rather than generating
vCards on the fly.

I think this happily solves the 80/20 percent of all use-cases right
now. I'm also sure smarter people than me can take this to the next
step, implement something like this, and do an even better job of
getting quality data out.

-brian


--
brian suda
http://suda.co.uk

Jeremy Keith

unread,
Jan 24, 2007, 6:43:45 AM1/24/07
to Microformats Discuss
I'd like to bring up a real world example here.

Tantek wrote:
> I'd even advocate looking for
> the first <address> that is or contains an hCard on the page, since
> that's
> following prescribed behavior from HTML4.

On every page of my site (http://adactio.com/), I have an hCard that
uses the address element:

<address class="vcard">
<a href="http://adactio.com/" class="url org">Adactio</a>
is the online home of
<a href="mailto:jer...@adactio.com" class="email fn">Jeremy Keith</a>, a
<span class="title">web developer</span>
living and working in
<span class="adr">
<span class="locality">Brighton</span>,
<span class="country-name">England</span>
</span>.
</address>

I believe this is the correct use of the address element. Whichever
page of the site you find yourself on, the address element contains
the contact details of the site owner: me.

On my contact page, I have a longer hCard:

<div class="vcard">
<h3>Contact Details</h3>
<a class="fn url" href="http://adactio.com/">
<span class="given-name">Jeremy</span>
<span class="family-name">Keith</span>
</a>
<div class="adr">
<span class="street-address">Flat 7, <br />57/58 Brunswick Road</
span><br />
<span class="locality">Hove</span>
<a class="postal-code" href="http://maps.google.co.uk/maps?q=bn3+1dh"
title="map">BN3 1DH</a><br />
<span class="country-name">England</span>
</div>
<p><abbr title="Telephone">Tel</abbr>/<abbr title="Telefax">Fax</
abbr>: <a class="tel" href="callto:+44-1273-771485">+44 1273 771485</
a></p>
<p class="tel"><span class="type">Mobile</span>: <a class="value"
href="callto:+44-7792-069292">+44 7792 069292</a></p>
</div>

Here, I'm not using the address element (though I could) but this
longer hCard should probably be considered the authoritative one (or
it should be merged with any other hCard data collected).

I *could* use rel="me" on the first hCard (the one that appears on
every page) to point to the contact page:

<a class="url" href="http://adactio.com/contact/" rel="me">

But that feels a little uncomfortable: usually, I would point
rel="me" to the front page of my site (and that's exactly what I have
done with hCards in other places like http://bulletproofajax.com/ )

So although I have a single location for an authoritative hCard, none
of my "lesser" hCards are connected to the authoritative version.

David suggested:


> - if there is no fragment in the non-canonical hCard url, a <link>
> is required

To which, Tantek replied:


> <link> should never be required, and should be avoided.

And I tend to agree.

I have a feeling that the answer lies with rel="me".

In my case, if I were to update just the address element that appears
on the home page with a link of rel="me" pointing to my contact page,
then all roads would (eventually) lead to my authoritative hCard:

* Every page of adactio.com has an hCard with a "url" value pointing
to the front page,
* All of my hCards on other sites (e.g. the Bulletproof Ajax site,
blog comments etc.) points to the front page of adactio.com, again
using the "url" value,
* The front page of my site points to my authoritative hCard using
rel="me".

Brian described the behaviour of spidering tools and wrote:
> By doing this, we introduce NO new technology or mark-up to find
> authoritative data. We are using already existing microformats (XFN),
> the data is visible using @rel instead of <link> it allows for the
> market to compete and build better spiders.

I agree. And I think I'll go and update the front page of my site
right now. :-)

But Brian also raised another point:


> The problem arrises when multiple hCards are
> encountered on a page - which is the authorative hCard?

This is the case with http://adactio.com/contact/
As well as the "global" hCard (in the address element), the page also
contains the authoritative one.

So what I may need to do is expand the href I use in a rel="me" link
to point not just to my contact page, but specifically to a page
fragment:

<a class="url" href="http://adactio.com/contact/#vcard" rel="me">

As long as I uniquely identify my authoritative hCard with that
unique identifier (id="vcard") then, at least in theory, a spider
should be able to tell which hCard is authoritative even if more than
one hCard is on the page.

Note that I'm not suggesting a *specific* value like "vcard" for the
fragment identifier, just that the fragment identifier corresponds to
the rel="me" url. So I could just as easily use:

<a class="url" href="http://adactio.com/contact/#foobar" rel="me">

...as long as I then markup my authoritative hCard within id="foobar".

Anyway...

I started this email just to throw a real-world example out there,
but talking through it has helped me clarify what I think I need to do.

Before I finally shut up, I wanted to make sure that this link gets
mentioned at least once in this discussion:

http://gmpg.org/xfn/and/#idconsolidation

Bye,

Jeremy

--
Jeremy Keith

a d a c t i o

http://adactio.com/

David Janes

unread,
Jan 24, 2007, 6:50:44 AM1/24/07
to Microformats Discuss
On 1/24/07, Brian Suda <brian...@gmail.com> wrote:
> On 1/24/07, David Janes <david...@blogmatrix.com> wrote:
> > Do you (Tantek + all) agree with the following "architecture", or it
> > least think it's worth pursuing further:
> >
> > (a) hCards without additional markup; "url" is used to lookup a URL
> > (b) at the URL we can either find:
> > (b.i) the authorative hCard; OR
> > (b.ii) a pointer to authorative URL with the authorative hCard
> > (c) it's easy to find the authorative hCard on the authorative URL
> >
> > I'm sure we have the technology to to (b.ii), I just don't know if
> > anyone has done it. Anyone?
>
> In a similar vein, an hCard spider could find hCards in a page with a
> URL. They could then follow that URL to the person's page. Then
> inspect for hCards. If none are found, it could simply follow all
> rel-me links. Since rel-me is published by the author of the page,
> [it is a safe asssumption?] that the subsequent requested pages are
> also controled by the author. Then hCards could be looked for on those
> pages as well. The problem arrises when multiple hCards are
> encountered on a page - which is the authorative hCard? This issue is
> not a problem with the spider, but with the mechanism to say "THIS
> hCard is the one you want" (you suggested an anchor link #vcard), but
> using some hueristics, it might be possible to match the URL of the
> ORIGINAL hCard that started this spidering, and any hCards found in
> the rel-me crawl. If the URLs match, then you could (with some degree
> of certainly) collapse the values into a more robust hCard.

Note that the '#vcard' is from Ryan's website, which I was using as my
working example. I love the rel-me bit, I'm a little less happy with
the "crawl many pages and see if we find something" (if I understand
you correctly) and I wonder if it can be improved

Let me just write out the problem again, based on a real world example

(a) Start Source Page (e.g. http://microformats.org/)

<address class="author vcard">
<a class="url fn" href="http://theryanking.com">Ryan</a>
</address>

(b) URL Page (http://theryanking.com):

... something happens ...

Note that Ryan already has a pointer on this page to his contact page:

<a href="http://theryanking.com/blog/contact/" title="contact">contact</a></li>

(c)
Authorative URL Page (http://theryanking.com/blog/contact/#vcard):

<div class="vcard" id="vcard">
... authorative hCard ...
</div>

So the issue is with the "something happens" bit. Here are a few suggestions

(I) Brian's solution (I think)

- look for "rel-me"
- check each page, matching on FN and/or URL

So we would change Brian's page:
<a href="http://theryanking.com/blog/contact/" title="contact"
rel="me">contact</a></li>

This issue here is FN on the source page may be a shorthand "Ryan" but
on the canonical page it may be

(II) Explicitly mark the authorative link with a unique class

<a href="http://theryanking.com/blog/contact/" rel="me
[hcard-authorative]">contact</a>

[hcard-authorative] is a placeholder, and obviously requires inventing
something new

(III) Modified Brian solution: require explicit ID for hcard

<a href="http://theryanking.com/blog/contact/#vcard" title="contact"
rel="me">contact</a></li>

That is, the spider will only attempt to look at rel-me URIs with a
fragment. The benefit is _explicitness_ and less open-ended work for
the spider. Requiring a fragment may introduce britleness?

Regards, etc...

Scott Reynen

unread,
Jan 24, 2007, 9:31:14 AM1/24/07
to Microformats Discuss
On Jan 23, 2007, at 8:46 PM, Joe Andrieu wrote:

> Tantek Ç elik wrote


>> 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.
>
> I think we don't mean "canonical" here, and perhaps fixing that will
> clarify a use case that distinguishes the opportunity.
>

> What I think is much more useful is /authoritative/ hCards. Meaning
> that this is the author's truth for this reference. The authoritative
> reference is the root source of the reference. It is close to
> definitive, but definitive assumes objectivity, whereas authoritative
> retains the subjectivity of the author.

I agree. Only one person knows the canonical source for a given
hCard (and even then it may change, e.g. in hCards used as OpenIDs).
Everyone else can at best point to the best authority they know.

> Working through this leads me to think that an hCard that exists at
> its
> self-referenced URI should be considered "authoritative."

My concern about this is that many publishers (myself included) try
to avoid linking a page to itself due to usability concerns, e.g. "I
just clicked on that link and didn't go anywhere. This site is broken."

Peace,
Scott

Ara Pehlivanian

unread,
Jan 24, 2007, 9:51:38 AM1/24/07
to Microformats Discuss
> My concern about this is that many publishers (myself included) try
> to avoid linking a page to itself due to usability concerns, e.g. "I
> just clicked on that link and didn't go anywhere. This site is broken."

Just a shot in the dark here, but couldn't the <a class="url" ...> be
assumed to be pointing to the hCard owner's site where it could be
further assumed that the authoritative hCard would reside? What's
more, if the href in the <a class="url"...> contained an id for the
actual hCard in question then you'd be pointing directly to the
correct hCard (in case the page contains multiple ones, for
work/home/etc...)

An example would be: <a class="url"
href="http://mydomain.com/contact.html#myInfo"...>

In the case of the authoritative hCard itself it could simply point to
it's own id like so: href="#myInfo", though I can see what you mean
about it giving the impression that the link is broken. But it isn't
illegal code. As a matter of fact, the authoritative hCard should
probably contain a full url with id included for accessibility's sake
(otherwise if the hCard is ever exported it won't have a url, just an
id).

Just my 2 cents,
A.

Joe Andrieu

unread,
Jan 24, 2007, 10:35:00 AM1/24/07
to Microformats Discuss
Scott Reynen wrote:
> On Jan 23, 2007, at 8:46 PM, Joe Andrieu wrote:
> > Working through this leads me to think that an hCard that exists at
> > its
> > self-referenced URI should be considered "authoritative."
>
> My concern about this is that many publishers (myself included) try
> to avoid linking a page to itself due to usability concerns, e.g. "I
> just clicked on that link and didn't go anywhere. This site
> is broken."


Scott,

That makes sense. But if I am on the page that is hosting my hCard, how
do I indicate that this URL is the URI for the hCard?

Wouldn't you just use a <span
class="url">http://www.switchbook.com</span> instead of an <a>?

That would still get picked up by the parsers as self-referential,
wouldn't it?

-j

_______________________________________________

Scott Reynen

unread,
Jan 24, 2007, 10:53:45 AM1/24/07
to Microformats Discuss
On Jan 24, 2007, at 9:35 AM, Joe Andrieu wrote:

> Wouldn't you just use a <span
> class="url">http://www.switchbook.com</span> instead of an <a>?
>
> That would still get picked up by the parsers as self-referential,
> wouldn't it?

Yes it would. I hadn't considered the possibility of using
class="url" outside <a>. That makes sense to me.

Peace,
Scott

Ara Pehlivanian

unread,
Jan 24, 2007, 11:04:06 AM1/24/07
to Microformats Discuss
> Yes it would. I hadn't considered the possibility of using
> class="url" outside <a>. That makes sense to me.

I think <cite class="url">http://www.site.com</cite> would work
nicely, semantically speaking. No?

A.

Andy Mabbett

unread,
Jan 24, 2007, 2:36:00 PM1/24/07
to Microformats Discuss
In message <003401c73f61$de549050$69fa030a@andrieuhome>, Joe Andrieu
<j...@andrieu.net> writes

>A few two major things happen when you do this:
>1. You enable an hCard author to semantically declare this hCard as
>"definitive"
>2. You could provide a link from a refering hCard to the authoritative
>hCard for discovery of additional information that isn't appropriate
>for the design or context of the "refering" hCard.

Of course, it could be argued that the latter constitutes invisible
meta-data...


If example.com/Fred has:

<span class="vcard">
<span class="fn">Fred<\span>
<img class="logo">Fred-avatar.png</img>
</span>

then compare, on another site:

<span class="vcard">
<a class="fn url" href="http://example.com/Fred">Fred<\a>
</span>

with:

<a class="pavatar"
href="http://example.com/Fred-avatar.png">Fred's avatr<\a>

--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>

Welcome to the 21-day week!

Andy Mabbett

unread,
Jan 24, 2007, 2:20:01 PM1/24/07
to Microformats Discuss
In message <643AED4B-29CA-4488...@adactio.com>, Jeremy
Keith <jer...@adactio.com> writes

>I have a feeling that the answer lies with rel="me".

It has a certain elegance, but is rel="me" appropriate for the hCards of
organisations?

It certainly wouldn't help on pages with more than one "short" hCard,
link to a second page with the same people's full hCards, or for third
party details where the author (the "me") isn't the subject.

Welcome to the 21-day week!

Andy Mabbett

unread,
Jan 24, 2007, 2:25:04 PM1/24/07
to Microformats Discuss
In message
<21e523c20701240350g3d7...@mail.gmail.com>, David
Janes <david...@blogmatrix.com> writes

><address class="author vcard">
><a class="url fn" href="http://theryanking.com">Ryan</a>
></address>


Making that:

<address class="author vcard">
<a class="url" href="http://theryanking.com">
<abbr class="fn" title="Ryan King">Ryan</abbr>
</a>
</address>

not only resolves your 'mismatched-fn' concern, but is also more
semantically meaningful.

Welcome to the 21-day week!

Andy Mabbett

unread,
Jan 24, 2007, 2:09:00 PM1/24/07
to Microformats Discuss
In message
<21e523c20701240236n134...@mail.gmail.com>, David
Janes <david...@blogmatrix.com> writes

>Let me ask this: is there a _single_ example out there of what we want to do?

There is an hCard (one of several) on:

<http://www.rspb-walsall.org.uk/links.htm>

for the West Midland Bird Club, with just "fn org url". The target of
the url property:

<http://www.westmidlandbirdclub.com/>

has a more complete ("canonical", if you will) hCard for the Club, with
postal contact details.

Welcome to the 21-day week!

Chris Casciano

unread,
Jan 24, 2007, 5:26:38 PM1/24/07
to Microformats Discuss

On Jan 23, 2007, at 1:22 PM, David Janes wrote:

> Continuing the tradition of riffing off other threads to talk about
> what's on my mind...
>
> On 1/23/07, Ryan King <ry...@technorati.com> wrote:
>>
>> It's not a full CSS selector based search engine, but http://
>> kitchen.technorati.com/contacts/search/tantek.
>>
>
> Wouldn't it be great if there was a well defined way of getting from
> _an_ instance of a hCard to the _best_ (or canonical) hCard for that
> person.
>
> Just saying; I know that some work has been done on this.
>
> Regards, etc...


Not to double back on a few days worth of replies, but while I
understand the desire to eliminate noise from search results [or
elevate more complete results] I'm not sure how I feel about two things:

(a) that this isn't an issue simply to be solved by consuming
applications. E.g. "search for detailed contact data" "return only
results with email address" "match on Name 'Chris' and url contains
'placenamehere.com', or some non-hcard solutions be them XFN,
claimID, other avenues for tying these bits together.

(b) I think with any solution we need to be careful on the definition
and reliance on these flags, and more generally the notion that
there /is/ a best out there for any given individual. Just one case
would be a person who might have their contact info on a business
context, a context related to their position in a different
organization, and then yet another in a more personal context [blog,
resume on monster.com, etc]. While all are probably more informative
then a simple fn-only card from a reply on a random blog post on the
net, what is 'best' is based on context and the data will most likely
not be consolidated into one place.


P.S. the technorati search is currently giving me no results for any
contact searches I try, I'll follow up with the proper parties offlist.

--
[ Chris Casciano ]
[ ch...@placenamehere.com ] [ http://placenamehere.com ]

Andy Mabbett

unread,
Jan 24, 2007, 5:46:58 PM1/24/07
to Microformats Discuss
In message <712C9B6D-8DD2-4CC8...@placenamehere.com>,
Chris Casciano <ch...@placenamehere.com> writes

>(b) I think with any solution we need to be careful on the definition
>and reliance on these flags, and more generally the notion that there
>/is/ a best out there for any given individual.

Perhaps what ought to be marked up is the "parent" hCard of known
"child" hCards?

Welcome to the 21-day week!

John Allsopp

unread,
Jan 24, 2007, 9:13:37 PM1/24/07
to Microformats Discuss
Jeremy Keith wrote in relation to denoting an "authoritative" hCard
from another

> I have a feeling that the answer lies with rel="me".

Might I suggest, reusing how permalinks work in hAtom and hReview
(particularly hReview)?

rel=bookmark is defined in the HTML 4 spec as
"Refers to a bookmark. A bookmark is a link to a key entry point
within an extended document" [1]

Nothing there suggests that the bookmark is in any way authoritative,
but an authoritative hCard would fall under "a key entry point within
an extended document". So, we are half way there.

Then, if we look at, hReview we find there is already a similar
solution. An hReview may point to its "permalink" (surely the
authoritative version? Ryan your thoughts on the analogy?) using
rel="bookmark self". The self part is required along with bookmark to
"indicate that the hyperlink is a permalink for the review itself" [2]

So, suggestion is use

rel="bookmark self" to denote that the resource pointed to by the
link (<a href) is the authoriatative version of the hCard (and indeed
this might be a generalizable pattern? - the authoritative version of
a microformat may be indicated by the use of a link to that
microformat, with a rel value which includes "self" and "bookmark")

Thoughts?

Thanks

john

1.http://www.w3.org/TR/html4/types.html#type-links
2.http://microformats.org/wiki/hreview#Field_details

John Allsopp

--
style master :: css editor :: http://westciv.com/style_master
about me :: http://johnfallsopp.com
Web Directions North, Vancouver Feb 6-10 :: http://
north.webdirections.org

Ben Ward

unread,
Jan 29, 2007, 4:57:56 PM1/29/07
to Microformats Discuss
On 24 Jan 2007, at 14:51, Ara Pehlivanian wrote:
> Just a shot in the dark here, but couldn't the <a class="url" ...> be
> assumed to be pointing to the hCard owner's site where it could be
> further assumed that the authoritative hCard would reside? What's
> more, if the href in the <a class="url"...> contained an id for the
> actual hCard in question then you'd be pointing directly to the
> correct hCard (in case the page contains multiple ones, for
> work/home/etc...)
>
> An example would be: <a class="url"
> href="http://mydomain.com/contact.html#myInfo"...>

Whilst the use of fragment URLs is definitely correct as regards
focusing on specific hCards on a page, you cannot imply authority
based just on class=url — it's valid and legal that an hCard can have
multiple URLs, so which would be authoritative?. On my own site, I
link to my /about page, my Flickr account, Delicious bookmarks and so
on, all with class="url" and rel="me".

For my money, John Allsopp's idea to reuse rel="bookmark self" [1]
makes most sense. As well as being gorgeously consistent with other
existing microformats, it's also a completely graceful addition to
existing hCards.

The only concern I can see to check is if this would conflict with
and break the parsing of hAtom/hReview that already use those rel
values in combination?

It would take the guesswork out of parsing, whilst publishing useful
information. Additionally, what do people think to situations where
an hCard contains a A/@REL="bookmark self" but not @class=url? The
use case being when I don't regard my /about page as being a relevant
URL for inclusion in my hCard parsing, but do wish to have it
followed and parsed as the authoritative version.

Ben

[1]: http://microformats.org/discuss/mail/microformats-discuss/2007-
January/008309.html

John Allsopp

unread,
Jan 29, 2007, 8:50:41 PM1/29/07
to Microformats Discuss
Ben,

> For my money, John Allsopp's idea to reuse rel="bookmark self" [1]
> makes most sense. As well as being gorgeously consistent with other
> existing microformats, it's also a completely graceful addition to
> existing hCards.

thanks ;-)

There's a lot of goodness to reuse from other ufs, for sure.

> The only concern I can see to check is if this would conflict with
> and break the parsing of hAtom/hReview that already use those rel
> values in combination?

When rel-license is inside an hReview, it is taken to be associated
with the review, rather than the larger fragment it would otherwise
be associated with (e.g. post or page)

I wonder whether that makes sense more generally - things apply at
the finest level of granularity at which it mkes sense - so
rel="bookmark self" applies to the microformatted content it is most
directly descended from.
Are there reasons people think this is a bad idea?
An analogy again is categories in hAtom

You can have either feed categories or entry categories. Both are
encoded using rel-tag. The difference is that entry categories are
inside the hentry element, while feed categories are in the hFeed
element (but not in the hEntry element). The point is that hEntry
elements descend from hFeed elements, so all entry categories are
inside an hFeed element.

Indeed, Brian Suda, Michael Kaply, or someone else who does a bit of
parsing might weigh in on whether or not this is an implicit
assumption they make more generally with their parsers, or whether it
might become an explicit convention - to try and formulate it (badly)

"where a feature of microformats may apply to more than one element
in a descendent tree, it is associated with the element which most
directly contains it ."

> It would take the guesswork out of parsing, whilst publishing
> useful information. Additionally, what do people think to
> situations where an hCard contains a A/@REL="bookmark self" but not
> @class=url? The use case being when I don't regard my /about page
> as being a relevant URL for inclusion in my hCard parsing, but do
> wish to have it followed and parsed as the authoritative version.

Not sure whether this is straying into the 20% part of the problem
space? Just my initial response, with little real thought ;-)

john

Derrick Lyndon Pallas

unread,
Jan 30, 2007, 12:02:50 AM1/30/07
to Microformats Discuss
John Allsopp wrote:
>
> I wonder whether that makes sense more generally - things apply at the
> finest level of granularity at which it mkes sense - so rel="bookmark
> self" applies to the microformatted content it is most directly
> descended from.
> Are there reasons people think this is a bad idea?
>
> "where a feature of microformats may apply to more than one element in
> a descendent tree, it is associated with the element which most
> directly contains it ."

Personally, I think this is a bad idea; I was actually talking with Ben
West at work today about this very issue. For the sake of argument, say
hFoo --- which I decide to implement --- can contain rel-tag without
marking it in any other way. Now a new format, hBar, comes along and it
may contain rel-tag without marking it in any way; maybe I don't know
about hBar, don't care about hBar, or don't want to implement hBar. What
if my hFoo contains an hBar? In that case,

<div class="hFoo">
<span class="hBar">
<a href="http://examples.com/tag/myTag" rel="tag">Text</a>
</span>
</div>

causes a problem (given the suggestion above) because the rel-tag should
only apply to hBar but without the hFoo parser knowing about hBar (which
may be unreasonable) it will grab the rel-tag as well. A better solution
is what hCard does; from what I understand, using rel-tag with category
still requires you to say @class="category". This, incidentally, can
cause a name-space problem: it means that to keep hBar and hFoo
unambiguous, one needs to define slightly different rel-tag properties
for each.

There are two simple solutions: make features only apply to the element
in which they exist (which makes them non-features) or let features
apply to any format that can grok the feature, ignoring containers.
There are three complex solutions: use name-spaces for disambiguation,
use other naming triks to figure out which feature apply to which
container (this could get messy quickly), or require parsers for one
format to know about all other top level containers (which seems bad for
compatibility).

~D

Chris Messina

unread,
Jan 30, 2007, 2:50:11 PM1/30/07
to Microformats Discuss
Well, I certainly am coming to the party late.

I actually started a post on this topic over a week ago -- and
absentmindedly hadn't checked on this list first before posting and
therefore published without the benefit of this discussion (I can hear
Tantek chiding me) but nonetheless, as the first half of a two-part
piece of transcending social networks (I have to write up the second
half still) I wrote this:

Scoping XFN and identifying authoritative hcards
<http://factoryjoe.com/blog/2007/01/29/scoping-xfn-and-identifying-definitive-hcards/>

I pretty much came up with a very similar proposal for handling this
issue, though from the standpoint of XFN-links, and I think that
John's suggestion is very good, though instead of using "bookmark
self" might suggest "me self" for identifying the One True Hcard:

<div class="vcard" id="vcard">
<address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
url" rel="me self">Chris Messina</a></address>
<div class="org">Citizen Agency</a>
...
</div>

That way, any hcard that links to me at
http://factoryjoe.com/blog/hcard/#hcard will find a self-referencing
hcard which serves as the proverbial "end of the road". I prefer "self
me" because of the potential conflict of embedding this kind of hcard
in other formats, as has been suggested could be an issue...

The use of the <address> tag is also important, as it signifies with
additional certainty that the author of the page own the hcards --
making it doubly authoritative.

Thus if you can find an object at "address a[rel~=self].url", there's
good chance you've got something pretty solid.

Thoughts? (I've also updated my post to reflect John's suggestion)

Chris


--
Chris Messina
Citizen Provocateur &
Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is: [ ] bloggable [X] ask first [ ] private

John Allsopp

unread,
Jan 30, 2007, 5:28:49 PM1/30/07
to Microformats Discuss
Chris,

(all the following simply thoughts in the spirit of brainstorming,
rather than any particular argument in favour of my original suggestion)

> I pretty much came up with a very similar proposal for handling this
> issue, though from the standpoint of XFN-links, and I think that
> John's suggestion is very good, though instead of using "bookmark
> self" might suggest "me self" for identifying the One True Hcard:
>
> <div class="vcard" id="vcard">
> <address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
> url" rel="me self">Chris Messina</a></address>
> <div class="org">Citizen Agency</a>
> ...
> </div>

I wonder whether hAtom had predated XFN, self instead of me would
have been chosen for the identity value?

The "definition" of the self attribute value in Atom is "self: the
feed itself". The term "the" seems to indicate "definitiveness". So,
I was initially going to argue that "self me" was tautological, but
in fact, in this sense it is not, and indeed, the addition of
bookmark is probably tautological.

So, I'd probably +1 this suggestion, and perhaps also suggest that
for hReview simply a rel value of "self" be required for the
permalink, for consistency.

> The use of the <address> tag is also important, as it signifies with
> additional certainty that the author of the page own the hcards --
> making it doubly authoritative.

Thats true. But just to note (as I am sure you know) that as address
is an inline element, this enforces certain contraints on its
descendents - they al have to be inline elements.

> Thus if you can find an object at "address a[rel~=self].url", there's
> good chance you've got something pretty solid.
>
> Thoughts? (I've also updated my post to reflect John's suggestion)

I suggest the correct use of self is definitive, so address, while
perhaps advisable, doesn't need to be required.

j

Ben Ward

unread,
Jan 30, 2007, 7:06:58 PM1/30/07
to Microformats Discuss
> Chris Messina:

>> <div class="vcard" id="vcard">
>> <address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
>> url" rel="me self">Chris Messina</a></address>
>> <div class="org">Citizen Agency</a>
>> ...
>> </div>
>>

John Allsopp:


> The "definition" of the self attribute value in Atom is "self: the
> feed itself". The term "the" seems to indicate "definitiveness".
> So, I was initially going to argue that "self me" was tautological,
> but in fact, in this sense it is not, and indeed, the addition of
> bookmark is probably tautological.
>

> So, I'd probably +1 this suggestion, […]

+1 from me as well.

Can we gauge wider support for this addition? Any problems from anyone?

Ben

Steve Ivy

unread,
Jan 30, 2007, 7:32:17 PM1/30/07
to Microformats Discuss
+1 from me.


--
Steve Ivy
http://redmonk.net

Joe Andrieu

unread,
Jan 30, 2007, 7:59:34 PM1/30/07
to Microformats Discuss
Ben Ward wrote: (Subject: Vote on this: rel="me self" to indicate an
authoritative hCard {was:Re: [uf-discuss] Authoritative
hCards [was RE: Canonical hCards(was: Search on CSS element)]}


> > Chris Messina:
> >> <div class="vcard" id="vcard">
> >> <address><a
> href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
> >> url" rel="me self">Chris Messina</a></address> <div
> >> class="org">Citizen Agency</a> ...
> >> </div>
>
> +1 from me as well.
>
> Can we gauge wider support for this addition? Any problems
> from anyone?

+1 from me. It addresses the issues I brought up quite nicely.

-j

_______________________________________________

Tara Hunt

unread,
Jan 30, 2007, 8:58:24 PM1/30/07
to Microformats Discuss
+1 from me, too

--
Sincerely,

Tara
-----------------------
tara 'miss rogue' hunt
agent provocateur
Citizen Agency (www.citizenagency.com)
blog: www.horsepigcow.com
phone: 415-694-1951
fax: 415-727-5335

Frances Berriman

unread,
Jan 31, 2007, 6:46:38 AM1/31/07
to Microformats Discuss
On 31/01/07, Ben Ward <li...@ben-ward.co.uk> wrote:
> > Chris Messina:
> >> <div class="vcard" id="vcard">
> >> <address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
> >> url" rel="me self">Chris Messina</a></address>
> >> <div class="org">Citizen Agency</a>
> >> ...
> >> </div>
> >>
>
> John Allsopp:
> > The "definition" of the self attribute value in Atom is "self: the
> > feed itself". The term "the" seems to indicate "definitiveness".
> > So, I was initially going to argue that "self me" was tautological,
> > but in fact, in this sense it is not, and indeed, the addition of
> > bookmark is probably tautological.
> >
> > So, I'd probably +1 this suggestion, […]
>
> +1 from me as well.
>
> Can we gauge wider support for this addition? Any problems from anyone?

+1

--
Frances Berriman
http://fberriman.com

Colin Barrett

unread,
Jan 31, 2007, 7:08:57 AM1/31/07
to Microformats Discuss
On Jan 31, 2007, at 3:46 AM, Frances Berriman wrote:

> On 31/01/07, Ben Ward <li...@ben-ward.co.uk> wrote:
>> > Chris Messina:
>> >> <div class="vcard" id="vcard">
>> >> <address><a href="http://factoryjoe.com/blog/hcard/#hcard"
>> class="fn
>> >> url" rel="me self">Chris Messina</a></address>
>> >> <div class="org">Citizen Agency</a>
>> >> ...
>> >> </div>
>> >>
>>
>> John Allsopp:
>> > The "definition" of the self attribute value in Atom is "self: the
>> > feed itself". The term "the" seems to indicate "definitiveness".
>> > So, I was initially going to argue that "self me" was tautological,
>> > but in fact, in this sense it is not, and indeed, the addition of
>> > bookmark is probably tautological.
>> >
>> > So, I'd probably +1 this suggestion, […]
>>
>> +1 from me as well.
>>
>> Can we gauge wider support for this addition? Any problems from
>> anyone?
>
> +1

Can I get a clearer idea of what exactly is people are +1-ing? I +1
@rel="self me", but am not willing to give my vote yet on using
<address>, as it's not entirely clear if we're talking about mandating
it, recommending it, etc. FWIW I'm not entirely convinced it's
necessary to have it.

-Colin

Ben Ward

unread,
Jan 31, 2007, 7:34:20 AM1/31/07
to Microformats Discuss
On 31 Jan 2007, at 12:08, Colin Barrett wrote:
> Can I get a clearer idea of what exactly is people are +1-ing? I +1
> @rel="self me", but am not willing to give my vote yet on using
> <address>, as it's not entirely clear if we're talking about
> mandating it, recommending it, etc. FWIW I'm not entirely convinced
> it's necessary to have it.

Apologies, I perhaps should have created a fresh example rather than
re-use Chris' original effort.

We are voting only on the use of @rel="me self" to reference an
authoritative hCard that parsers should follow.

e.g.

<div class="vcard">
<a class="fn url" href="http://ben-ward.co.uk/about" rel="me
self">Ben Ward</a>
</div>

Colin Barrett

unread,
Jan 31, 2007, 8:59:04 AM1/31/07
to Microformats Discuss
On Jan 31, 2007, at 4:34 AM, Ben Ward wrote:

> On 31 Jan 2007, at 12:08, Colin Barrett wrote:
>> Can I get a clearer idea of what exactly is people are +1-ing? I +1
>> @rel="self me", but am not willing to give my vote yet on using
>> <address>, as it's not entirely clear if we're talking about
>> mandating it, recommending it, etc. FWIW I'm not entirely convinced
>> it's necessary to have it.
>
> Apologies, I perhaps should have created a fresh example rather than
> re-use Chris' original effort.
>
> We are voting only on the use of @rel="me self" to reference an
> authoritative hCard that parsers should follow.
>
> e.g.
>
> <div class="vcard">
> <a class="fn url" href="http://ben-ward.co.uk/about" rel="me
> self">Ben Ward</a>
> </div>

Then +1 from me.

-Colin

Ara Pehlivanian

unread,
Jan 31, 2007, 9:15:31 AM1/31/07
to Microformats Discuss
+1

David Janes

unread,
Jan 31, 2007, 9:37:58 AM1/31/07
to Microformats Discuss
On 1/31/07, Ben Ward <li...@ben-ward.co.uk> wrote:
> We are voting only on the use of @rel="me self" to reference an
> authoritative hCard that parsers should follow.
>
> e.g.
>
> <div class="vcard">
> <a class="fn url" href="http://ben-ward.co.uk/about" rel="me
> self">Ben Ward</a>
> </div>

Just to be 100% pedantically clear:

(Part I)

If Ben puts this on his home page, parsers look at
"http://ben-ward.co.uk/" will know to look for an authoritative hCard
because of these two things:

1. there's a vcard
2. it has a "url" link with rel="me self"

(Part II -- implication)

If Ben places a vcard on a random page with
url="http://ben-ward.co.uk/", a consumer can optionally look there to
find an authoritative hCard.

The 80-20 rule covers the case where we would want to have more than
one authoritative hCard per page (i.e. it's not that common)

(Part III - rel-self)

We're getting the definition of rel-self from here [1]: "self: the
feed itself". It's a small stretch, but I just did some searching for
counter-examples (i.e. where rel-self doesn't point to the best URI
for a feed) and came up empty.

(Part IV -- the word authoritative)

I can't think of a better word. See definition 2 here [2]

So +1

Regards, etc...

[1] http://atomenabled.org/developers/syndication/#link
[2] http://www.answers.com/authoritative&r=67

--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com

Ara Pehlivanian

unread,
Jan 31, 2007, 9:49:02 AM1/31/07
to Microformats Discuss
> If Ben places a vcard on a random page with
> url="http://ben-ward.co.uk/", a consumer can optionally look there to
> find an authoritative hCard.

Just to stir the pot a little, and maybe it's a good idea to consider
authenticity in the whole discussion of authoritative cards. What
guarantees that when someone creates an hCard and puts rel="me self"
that they are giving the correct URL and that it isn't someone
impersonating you?

Would this be the place for a correlating hash to be included in the
hCard that the authoritative one has (which only the owner can
modify)?

Just a thought.
A.

Ben Ward

unread,
Jan 31, 2007, 10:07:44 AM1/31/07
to Microformats Discuss
On 31 Jan 2007, at 14:49, Ara Pehlivanian wrote:
> Just to stir the pot a little, and maybe it's a good idea to consider
> authenticity in the whole discussion of authoritative cards. What
> guarantees that when someone creates an hCard and puts rel="me self"
> that they are giving the correct URL and that it isn't someone
> impersonating you?

The authoritative version of the hCard is only going to be relative
to the published hCard itself. The situation doesn't change. Someone
could already write an inaccurate hCard for me on their website. They
could write a more thorough version and link from one to the other
with rel="me self". This addition doesn't affect the authenticity.

Authenticity falls out of scope of hCard alone. Layer in some OpenID
and you can have start to imply some authenticity. (e.g. Parse an
hCard at the OpenID url and follow rel="me self" to another domain.)

If you mean, someone at ‘BenWardSmellsAwful.com’ (don't register
that, please) writing an hCard and linking to ben-ward.co.uk/about
with rel="self me", the relationship is such that the Fake Ben's
hcard is discarded in favour of my real one. This does not allow
someone to describe ‘this hCard here is the authoritative version of
that one over there’. The direction of parsing disallows fakes.

Ben

David Janes

unread,
Jan 31, 2007, 10:18:03 AM1/31/07
to Microformats Discuss
On 1/31/07, Ben Ward <li...@ben-ward.co.uk> wrote:

> The authoritative version of the hCard is only going to be relative
> to the published hCard itself. The situation doesn't change. Someone
> could already write an inaccurate hCard for me on their website. They
> could write a more thorough version and link from one to the other
> with rel="me self". This addition doesn't affect the authenticity.
>
> Authenticity falls out of scope of hCard alone. Layer in some OpenID
> and you can have start to imply some authenticity. (e.g. Parse an
> hCard at the OpenID url and follow rel="me self" to another domain.)
>
> If you mean, someone at 'BenWardSmellsAwful.com' (don't register
> that, please) writing an hCard and linking to ben-ward.co.uk/about
> with rel="self me", the relationship is such that the Fake Ben's
> hcard is discarded in favour of my real one. This does not allow
> someone to describe 'this hCard here is the authoritative version of
> that one over there'. The direction of parsing disallows fakes.

Open ID spells this out up front: authentication is not trust [1].
It's similar for us; you/your consumer has to decide whether it trusts
a URI (BenWardSmellsAwful.com) making a authorative-hcard claim about
a hCard (ben-ward.co.uk/about), which you'll also have to make your
own decision about!

The nice thing is all the information is there for you to examine in
the open. Beyond that, the trust issue is difficult, to say the least,
and probably not solvable by microformats ... or big companies, or big
government :-)

Regards, etc...

[1] http://openid.net/about.bml

Ara Pehlivanian

unread,
Jan 31, 2007, 10:50:22 AM1/31/07
to Microformats Discuss
> If you mean, someone at 'BenWardSmellsAwful.com' (don't register
> that, please) writing an hCard and linking to ben-ward.co.uk/about
> with rel="self me", the relationship is such that the Fake Ben's
> hcard is discarded in favour of my real one. This does not allow
> someone to describe 'this hCard here is the authoritative version of
> that one over there'. The direction of parsing disallows fakes.

Yes, but what if someone registers ben-ward.net and puts up a fake
card on that site. Then he goes and publishes a partial hCard on
myspace and points to ben-ward.net/about with rel="self me". He's
effectively hijacked your identity and/or caused confusion and there's
no real way to verify who's who or who's telling the truth. It may not
be such a big deal now, but if microformats are to grow and begin to
be integrated into who knows what apps in the future, there may be a
need to authenticate the validity of the authoritative hCard.

Now I understand that it's not up to the microformat to actually do
any authentication. But I think it makes a lot of sense to build a
mechanism into it that allows you to include a piece of verifiable
data (such as a hash or some other token) that could then be checked
against an authentication service or a file in the root of your own
domain (à-la Google Analytics).

I don't have any immediate ideas on how best to semantically do this,
but the concern popped into my head rather early on and I felt that
maybe now would be the time to bring it up.

Cheers,
A.

Joe Andrieu

unread,
Jan 31, 2007, 10:52:18 AM1/31/07
to Microformats Discuss
Ara Pehlivanian wrote:
> Just to stir the pot a little, and maybe it's a good idea to
> consider authenticity in the whole discussion of
> authoritative cards. What guarantees that when someone
> creates an hCard and puts rel="me self" that they are giving
> the correct URL and that it isn't someone impersonating you?
>
> Would this be the place for a correlating hash to be included
> in the hCard that the authoritative one has (which only the
> owner can modify)?

Ara,

The concept behind an "authoritative" hCard rather than "definitive" or
"canonical" one was that "authoritative" would explicitly be a /claim/
by the author of the hCard regarding its authority in describing the
subject of the hCard, i.e., use /this/ hCard as the one true source of
this individual's contact information.

The possibility for someone to impersonate another is a problem much
greater than the semantic html we use. Authentication and validation of
assertions ends up outside the scope of microformats, IMO. The
infrastructure simply isn't in place to guarantee /any/ semantic
information found online.

Note also, the possibility for "authoritative" hCards to simply fall out
of date is a huge problem. I for one, no longer have access to my
college account, but for years an old home page of mine would show up at
Google with suitably humorous results when colleagues and clients
discovered it. It is easy to see how any hCard that I would have marked
as "authoritative" on that page could still be out in the wild, despite
it no longer being accurate and independent of my inability to correct
it.

So, the inaccuracy of an hCard is its own challenge, whether from
impersonation, poor maintenance, or simply typos. But I think we can
create value by agreeing on a mechanism for expressing the concept of an
authoritative hCard. Services will simply have to accept that
"authoritative" is a claim and could be invalid for any number of
reasons.

-j

David Janes

unread,
Jan 31, 2007, 11:07:00 AM1/31/07
to Microformats Discuss
On 1/31/07, Ara Pehlivanian <ara.peh...@gmail.com> wrote:
> Yes, but what if someone registers ben-ward.net and puts up a fake
> card on that site. Then he goes and publishes a partial hCard on
> myspace and points to ben-ward.net/about with rel="self me". He's
> effectively hijacked your identity and/or caused confusion and there's
> no real way to verify who's who or who's telling the truth. It may not
> be such a big deal now, but if microformats are to grow and begin to
> be integrated into who knows what apps in the future, there may be a
> need to authenticate the validity of the authoritative hCard.
>
> Now I understand that it's not up to the microformat to actually do
> any authentication. But I think it makes a lot of sense to build a
> mechanism into it that allows you to include a piece of verifiable
> data (such as a hash or some other token) that could then be checked
> against an authentication service or a file in the root of your own
> domain (à-la Google Analytics).

How if there's another Ben Ward? Sorry, lot's of people have thought
about this problem in lots of different realms (as I mentioned,
OpenID) and it's intractable.

_______________________________________________

Scott Reynen

unread,
Jan 31, 2007, 11:15:47 AM1/31/07
to Microformats Discuss
On Jan 31, 2007, at 9:18 AM, David Janes wrote:

> Open ID spells this out up front: authentication is not trust [1].

Nonetheless, people are trying to build trust systems on top of Open ID:

http://simonwillison.net/2007/Jan/22/whitelisting/

This is another topic entirely, but it occurs to me that adding
something like rel="trust" to the linked names in moderated comments
would remove the need for a separate whitelist.

Peace,
Scott

Ara Pehlivanian

unread,
Jan 31, 2007, 11:20:33 AM1/31/07
to Microformats Discuss
On 1/31/07, David Janes <david...@blogmatrix.com> wrote:
> How if there's another Ben Ward? Sorry, lot's of people have thought
> about this problem in lots of different realms (as I mentioned,
> OpenID) and it's intractable.

I guess there's no way to manage the partial hCards as they could
point anywhere and someone with the same name could easily be confused
with a potential identity hijacker. So yeah, that doesn't work.

As for authentication, I'm not sure it even matters come to think of
it. If anything, the site/page on which the authoritative hCard is
found is what needs to be authenticated rather than the piece of
markup itself.

In the end I think that the context is what lends credence to the
authenticity of the authoritative hCard and not the hCard itself.

A.

David Janes

unread,
Jan 31, 2007, 11:32:08 AM1/31/07
to Microformats Discuss
On 1/31/07, Scott Reynen <sc...@randomchaos.com> wrote:
> On Jan 31, 2007, at 9:18 AM, David Janes wrote:
>
> > Open ID spells this out up front: authentication is not trust [1].
>
> Nonetheless, people are trying to build trust systems on top of Open ID:
>
> http://simonwillison.net/2007/Jan/22/whitelisting/
>
> This is another topic entirely, but it occurs to me that adding
> something like rel="trust" to the linked names in moderated comments
> would remove the need for a separate whitelist.
>
> Peace,
> Scott

(1)
Note that this just backs up the problem one step. I.e. we had

URI-A claims (via "rel me self") that URI-B is it's authoriative hCard

now we have (via a whitelist) additionally:

URI-C claims URI-A is who he says he is.

Whitelist additions to XFN may be an interested topic to explore!

(2)
It occurs to me that one form of hijacking can be prevented

URI-A: "ben-ward.co.uk": links to "ben-ward.co.uk/about"
URI-B: "ben-ward.co.uk/about". Ben's authorative hCard
URI-X: "BenWardSucks.com": links to "ben-ward.co.uk/about"

Now, if URI-B uses "url" to point back to URI-A, i.e. Ben's home page,
then we have validatation that URI-A is making a claim that URI-B is
agreeing with. On the other hand, URI-X is making an unsubstantiated
claim.

War,
David

Ben Ward

unread,
Jan 31, 2007, 12:03:08 PM1/31/07
to Microformats Discuss
On 31 Jan 2007, at 15:50, Ara Pehlivanian wrote:
> Yes, but what if someone registers ben-ward.net and puts up a fake
> card on that site. Then he goes and publishes a partial hCard on
> myspace and points to ben-ward.net/about with rel="self me". He's
> effectively hijacked your identity and/or caused confusion and there's
> no real way to verify who's who or who's telling the truth.

That's still no different to life without rel="me self".

I happen to own the domains <ben-ward.co.uk> and <ben-ward.com>. Note
hyphens. I do not own <benward.com> , <benward.co.uk> nor any other
variant.

Domains do not prove identity. What I can do is make my entire
‘online identy’ parsable by linking between my domains and my social
network profiles using rel="me". That doesn't tell you anything more
about me as a person than the fact that <flickr/photos/benward>, <ben-
ward.co.uk> and <myspace.com/benwardcouk> are part of the same
personal network of sites.

The owner of Ben-Ward.net could have his own personal network of
sites too, but they would not be linked to from my own authoritative
hCard at ben-ward.co.uk/about. Nothing stops him add rel="me" to his
hcard pointing to my site, but that takes us well out of scope of
hcard, and is still a different issue — not something introduced by
@rel="me self"

Ben

Ben Ward

unread,
Jan 31, 2007, 12:14:50 PM1/31/07
to Microformats Discuss

On 31 Jan 2007, at 17:03, Ben Ward wrote:
> The owner of Ben-Ward.net could have his own personal network of
> sites too, but they would not be linked to from my own
> authoritative hCard at ben-ward.co.uk/about. Nothing stops him add
> rel="me" to his hcard pointing to my site, but that takes us well
> out of scope of hcard, and is still a different issue — not
> something introduced by @rel="me self"

Actually I'm wrong here. The XFN spec points out that @rel=me must be
symmetric, so the owner of ben-ward.net could *not* validly link to
ben-ward.co.uk with @rel=me unless I linked back likewise.

“me: A link to yourself at a different URL. Exclusive of all other
XFN values. *Required symmetric*.”

Benjamin West

unread,
Jan 31, 2007, 12:55:18 PM1/31/07
to Microformats Discuss
I'm trying to catch up, but I'm finding it a bit difficult. The
problem with rel="me" is that it's merely an alternative version, and
not authoritative or canonical, right? Why is rel="me self" desirable
though? Were there any other alternatives considered?

Thanks,
Ben West

On 1/31/07, David Janes <david...@blogmatrix.com> wrote:

Andy Mabbett

unread,
Jan 31, 2007, 9:40:34 AM1/31/07