[uf-discuss] "related" hcards [was VIA or VIA SELF to indicateauthoritativehCard[was:UID URL to indicate (relatively)moreauthoritativehCard...]]

[Scott Reynen]

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