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 <[EMAIL PROTECTED]> 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@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
