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 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/mi
croid.html
>
> Tane
>
> On 1/31/07, Colin Barrett <timberlava.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-discussmicroformats.org
> > http://microformats.org/mailman/listinfo/microforma
ts-discuss
> >
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss
>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|