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

[Benjamin West]

There is quite a lot of interest in this topic.  With all the voices,
it's becoming quite difficult to keep track of what we're talking
about, and who thinks what.

I've added this issue to the hcard-issues page.

<http://microformats.org/wiki/hcard-issues#Canonical.2FAuthoritative_Hcard>

I would greatly appreciate everyone filling out the details of this
issue, as well as adding their opinion on this page.  Hopefully the
discussion will be easier to track.

There seems to be enough interest to sustain this issue in a real-time
chat on IRC.  I invite all of you to continue discussion on the wiki
and IRC so that more people can participate without getting hopelessly
lost.

Thanks,
Ben West

On 1/31/07, digital spaghetti <digitalspaghetti at googlemail.com> wrote:
> 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
> >
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>