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)]}

digital spaghetti digitalspaghetti at googlemail.com
Wed Jan 31 11:08:00 PST 2007


Just chiming in my two pence here:

Rather than something like @rel="me self", would a better idea not be
to look at including some kind of way of authenticating the source
such as a MicroID hash?

This has already been discussed on the MicroId list along the lines of this:

@rel="me microid-mailto+http:sha1:hash" (has being a full sha1 or
sha256 hash), then services like claimID can then look at the tag, and
convert back.  If your registered ClaimID email address and the URI of
the source match the hash in the rel tag, then the source is verified
as being you?

There are more details on the spec at http://microid.org/microid.html

Tane

On 1/31/07, Colin Barrett <timber at lava.net> wrote:
> On Jan 31, 2007, at 9:47 AM, Ben Ward wrote:
>
> > My understanding therefore, is that @rel=me indicates that it is the
> > same person. @rel=self indicates that it is the same hcard.
> > Therefore the absolute authoritative hcard we speak of may (I expect
> > will) contain other links with @rel=me but will not contain a link
> > with @rel=self.
>
> This is what I understood.
>
>  From here on, is a braindump:
>
> I'm still unsure of the original objection, which seems to be that
> @rel=me must be symmetric. XFN does not have the concept of one of
> those pages being more authoritative than the other, right? If we have
> the following page structure (bare minimum markup included for brevity):
>
> Document A:
> <a href="B" rel="me"></a>
>
> Document B:
> <a href="A" rel="me"></a>
>
> to XFN, both pages are equally "authoritative," in that they represent
> the same author. XFN doesn't seem to care much about which one is
> "more authoritative" than the other, just that they are referring to
> the same person, and that's fine.
>
> Adding @rel=self is a proposed way of breaking this loop, and letting
> one settle as the authority:
>
> Document A:
> <a href="A" rel="me self"></a>
>
> Docment B:
> <a href="A" rel="me"></a>
>
> I think that would be the use case (judging by what Chris Messina
> posted)?
>
> The problem there seems that A no longer tells us anything about
> wether or not it recognizes B as another, valid source of information.
> Simply adding another URL with @rel=me doesn't seem like it would work
> though -- then the following case could occur:
>
> Document A:
> <a href="A" rel="me self"></a>
> <a href="B" rel="me"></a>
>
> Document B:
> <a href="B" rel="me self"></a>
> <a href="A" rel="me"></a>
>
> In which both A and B claim authority, and both link to each other as
> "slaves", which leaves a parser in a strange situation -- now you
> don't just have two pages claiming to represent one person, but two
> pages claiming to be the authoritative source for one person. This
> doesn't seem like it would make a whole lot of sense.
>
> end braindump.
>
> Is this (one of) the issues being discussed? I'm basing a lot of this
> on Chris Messina's email to the thread, which was a bit unclear.
>
> If so, I wrote a second part to this (attempting to solve that
> problem), but decided to save it until I know wether or not I even
> have my assumptions in order.
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


More information about the microformats-discuss mailing list