Scott Reynen wrote:
On Feb 20, 2007, at 6:56 PM, John Panzer wrote:
Scott Reynen wrote:
...
Here's the purpose of UID from vCard:
To specify a value that represents a globally unique
identifier corresponding to the individual or resource associated
with the vCard.
So if two hCards have the same UID, they must refer to the same
person, because otherwise it wouldn't be globally unique. And I
think that solves the problem Thom described above, unless I'm
missing why it needs to be specific to OpenID.
Nope, it solves it. OpenID URLs are just one example.
...
I'm thinking here of cases where the target may be an OpenID, but
not necessarily provide an hCard.
UIDs do not need to point to hCards. Nor do they need to be
OpenIDs. They can do both, but the only requirement is that they be
globally unique and correspond to the subject of the hCard. And that
minimal requirement seems to be just enough to solve this problem
without worrying about what, if anything, is on the other end of the
UID.
Thanks. (The thread in the archives was somewhat twisty; the summary is
helpful.) So, rel="url uid" it is.
I think this solves the problem of how to match one hCard up with
another using a convenient unique key well above the 80% level.
One minor point: URLs are unique but not truly persistent. Due to URL
reuse,when trawling through archives you can't assume that UID1 == UID2
means person 1 == person 2 unless both UIDs were minted at the same
time. I'd probably solve this heuristically if ever necessary, but: Is
it worth an implementor's warning somewhere?
Interestingly, the vcard people seemingly dealt with this issue, because
they edited [1] "persistent, globally unique identifier" prior to the
final RFC draft.
-John Panzer
[1] http://www.imc.org/pdi/vcard-21.txt
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
