On Feb 23, 2007, at 3:44 AM, Joe Andrieu wrote:
1. Referrees without UID match any referring hCard
If the referred to hCard has no UID, the algorithm assumes
"relatedness", but that seems dubious at best without a confirming
UID.
I agree, this seems almost the opposite of the intent of UID, as the
UID value is no longer doing any identifying, it's just pointing to
somewhere that identity relationships could be discovered.
2. Ambiguous relation when multiple hCards are present at URL
If the referred to URL has multiple hCards, each with no UID, there
is no way to disambiguate which one(s) should be "related."
This problem is solved by using IDs, which doesn't strike me as a
large burden. The related one would be the one at URL#related.
3. UIDs that are XRIs and not URLs
With the use of OpenID as UID, do we extend the field URL to
include XRIs?
Who is currently pointing to XRIs as UIDs on the web? Are they not
using the existing XRI URL bridge?
http://dev.inames.net/wiki/
Global_Registry_Services#Public_Proxy_Resolver
This looks like a hypothetical rather than a practical problem.
Also, it's covered under the next point, so not really a separate issue:
4. UIDs that are not URLs
I think it would be helpful to find some of these on the actual web.
Otherwise, this is also just a hypothetical, and we could go back and
forth about it forever.
Instead, I would like to propose that "source" be traversed to
discover synonymous hCards, relying on UIDs for association, without
requiring that source == UID prior to traversal.
That makes sense to me. Indeed, I think that was exactly what the
vCard spec intended for those properties. The only difference with
hCard is we have HTTP sources instead of LDAP sources, but vCard
isn't even defined as LDAP-specific, so no changing of the spec is
even necessary.
Because no one seems to be using UID as UID right now, I think it
would also make sense to look for an alternative means of specifying
a UID. As a tangent to Joe's proposal of UID+SOURCE for traversing
identity relationships, I'd like to propose that URL+ID+SOURCE ==
UID. That is, this would suggest a UID:
<a class="url source" href="http://theryanking.com/blog/contact/#vcard";>
This would only suggest a URL, not a SOURCE nor a UID:
<a class="url" href="http://theryanking.com/blog/contact/#vcard";>
And this would only suggest a URL and a SOURCE, but not a UID:
<a class="url source" href="http://theryanking.com/";>
If a UID is explicitly declared, that would take precedence over this
pattern.
Also, the same would be true for hCards with IDs but no UIDs nor
SOURCEs (so a URL and SOURCE of self can be logically assumed), e.g.:
<div id="vcard" class="vcard">
The UID for that would be the current URL with the ID on the end,
i.e. the same UID in the above examples.
My rationale here is this:
A) UID is an identifier unique to a single person
B) SOURCE is unique to a single person
C) ID is an identifier unique to a single page
D) URL relates a single person with a single page
So I think B+C+D combined carries the semantics of A, and formalizing
this would make Joe's proposal more easily adopted (i.e. by not
requiring UIDs to be specified by users -- if they specific a URL
with an ID, and their hCard is found there, that's their UID).
Previously, you objected:
SOURCE is already used by X2V to indicate the URL at which the
current hCard is available. I don't think we'd be able to override
that at this point.
I respect the work done by Brian Suda and others on X2V, but this
argument doesn't pass the smell test.
I agree, obviously.
And indeed, both of us are suggesting an incredibly minor change to
the extended semantics of a single field to support a particular
use case.
I'd argue that using source to identify a source and using UID to
identify a unique global identifier is not an incredibly minor
change; it's no change at all.
URL and SOURCE will still mean basically the same thing as always.
However, an additional implied semantic would enable
discovery of synonymous cards. This seems like an odd item to limit
based on existing XSLT files.
We don't need to imply the semantic of identity relationships at
all. The UID explicitly declares that relationship.
So, could you outline in a concise form the fundamental problems
you have with uid+source for related hCards?
Yes, please do.
Peace,
Scott
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
