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

[Ryan King]

On Feb 23, 2007, at 1:44 AM, Joe Andrieu wrote:

> Ryan King wrote:
>> I understand this. I agree that this is a desirable goal. I would
>> personally like to see it happen. However, the simpler
>> problem of two
>> hcards representing the same person (or organization) should be
>> solved first, because it is a simpler problem, with a simpler
>> solution (which may not require adding any properties to hCard).
>
> If all you want to do is have two hCards represent the same entity,  
> why not just use the same UID?
>
> I think I understand that it is to traverse the network to discover  
> multiple, "synonymous" hCards for the same entity? That what you
> want is not just synonymity, but discoverable synonymity. Is that  
> correct?

Yes. The nice thing about URLs is that you can dereference them and  
consume the resource returned.

> RFC2426 [1] (the vCard spec incorporated by reference into hCard)  
> specifies the URL type use as:
>    To specify a uniform resource locator associated with
>    the object that the vCard refers to.
>
> Your algorithm was:
>> 1. if no uid or uid == the uid from the previous
>>    iteration/recursion => you're done
>>
>> 2. if url == uid and there's an hCard at that url,
>>    recurse with the new hCard
>
> In that case, what you are saying is that if the UID is the same as  
> the URL, one should expect to be able to assume a common
> relationship between this hCard and any hCard with either no UID or  
> a matching UID at the URL for this hCard.
>
> Here's what seems to fail in this usage:
> 1. Referrees without UID match any referring hCard
> 2. Ambiguous relation when multiple hCards are present at URL
> 3. UIDs that are XRIs and not URLs
> 4. UIDs that are not URLs, generally.
>
> 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. It is a bit dubious. This might be something that's left to  
consuming applications to decide.

> 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."
>
> So... Refering card:
> <span class="vcard">
> <span class="fn">Mr. Andrieu</span>
> <span class="uid url">http://www.andrieu.net</span>
> </span>
>
> While on Andrieu.net we might have multiple hCards
> <span class="vcard">
> <span class="fn">Joe Andrieu</span>
> </span>
> <span class="vcard">
> <span class="fn">Julia Andrieu</span>
> </span>
> <span class="vcard">
> <span class="fn">Mike Andrieu</span>
> </span>
> <span class="vcard">
> <span class="fn">Maureen Andrieu</span>
> </span>
>
> Who is "Mr. Andrieu"?
>
> This is even more likely to occur when we accept the dynamic nature  
> of the web and the inevitable consistency errors of
> less-than-perfect data maintenance.  It seems to me that relating  
> only cards with common UIDs makes a lot of sense.

One option here would be to only take hCards in an <address>. Of  
course that doesn't apply in your example, but it would work in some  
real world examples (like http://theryanking.com/blog/).

> 3. UIDs that are XRIs and not URLs
>
> With the use of OpenID as UID, do we extend the field URL to  
> include XRIs?  This may or may not make sense, but stuffing an XRI  
> into
> a URL/URI is out of spec unless the spec changes to allow it. XRIs  
> are designed to replace URIs, but plenty of consuming
> applications break today if you try that.
>
> 4. UIDs that are not URLs
> I stand by the argument that UIDs that are not URLs should be  
> viable in any mainstream use of any microformat. Your bias towards
> URLs as UIDs shouldn't limit people's use of UIDs with alternate  
> formats, such as XRIs.  If we feel strongly about such a bias, as a
> community, we should change the hCard spec to require UIDs as  
> URLs.   XRIs as UIDs is just /one/ example where I think the evidence
> is overwhelmingly clear that there is technical acceptance and  
> solid reasoning for UIDs that are not URLs.  Now, we could change the
> definition of "URL" to include "XRIs", but I think we are better  
> off accepting that we cannot predict the future, nor should we
> presume that URLs are the only good UID unless we are willing to  
> make that a requirement in the spec. And frankly, that would put
> our definition of URL at odds with RFC for URLs.[2]  The spec uses  
> "should" for good reason. It is because of that *should* that XRI
> UIDs are 100% compliant with hCard /today/ without redefining the  
> spec. That's a good thing. Making URL UIDs a requirement for
> discovering synonymous hCards seems arbitrarily limiting with  
> minimal payoff.
>
> Items 1 & 2 could be trivially addressed by simply modifying your  
> algorithm to require that the UID of the /referred to/ hCard match
> the UID of the referring hCard for anything to work. So they aren't  
> major issues. (And it is clear that in the brevity of your
> algorithm, you didn't say termination assumed "relatedness", so 1&2  
> aren't all that important.)
>
> However, non-URL UIDs, as exemplified by XRIs as UIDs is a  
> fundamental problem that you have not satisfactorily addressed  
> other than
> by asserting
>> What better UID is there than a URL?
>
> You also stated:
>> Indeed, in vcard UID is just a string, but my proposal is that we
>> make it by default a URL. It's a simple change (which may already be
>> implemented in X2V).

You're right, I think UIDs should be URIs, but they don't have to be.  
I think the hCard spec should specify that UIDs be parsed as URLs,  
but that doesn't mean you *must* use a URI. For example, this would  
work just fine:

<span class='uid'>this is not a URI</span>

Just don't put the XRI in an a at href, img at src, object at data or area at href.

> Your disposition is clearly yours, not what the spec reflects, and  
> you have yet to make a solid case for it, much less secured
> community support for changing to that default.  I referred to your  
> disposition as a religious belief not to insult you, but to
> clarify that is an assertion of your presumptive belief.  From your  
> arguments, I have nothing but your faith in URLs as UIDs, no
> evidentiary arguments have been presented.  If the core of your  
> argument is that UIDs are supposed to be URLs, that is a completely
> different proposal than both this thread and the originating thread  
> (canonical hCards) is talking about.
>
> You later stated:
>> Also I'm not saying that UID-as-URI is the "right" way to do things.
>> I'm just saying that it's the most useful way to do things."
>
> For many applications, XRIs are arguably more useful. In fact, I  
> think XRIs answer your initial question adequately. They are a
> better UID than a URL.  Your simple assertion of your opinion is a  
> statement of belief, rather than a compelling argument.  My
> assertion that XRIs are better is also a statement of belief.  
> However, there are a lot of other smart people that also disagree on
> this topic (in both directions). Debating it here would be off- 
> topic to say the least.  However, the acceptance of the viability of
> XRI by a significant community is itself sufficient challenge to  
> your blanket assertion of the "most usefulness" of URLs as UIDs.
> Other UID schemes can be just as useful, perhaps more so.

XRIs may be theoretically more useful, but URIs work today in  
existing implementations. Microformats in general are built upon  
already-deployed technologies. That's why URIs (especially  
dereferencable ones) are useful.

> Because of that, I strongly feel that requiring UID=URL as the only  
> vehicle for discovering synonymous hCards is a huge mistake.
> More importantly, requiring that UIDs be URLs is a proposal/debate  
> in, and of itself.  It is currently sidetracking this discussion
> of how we might relate (potentially authoritative) hCards to each  
> other.

I'm not saying UIDs must be URLs, I'm saying that they should be  
parsed as such, which included fallback to non-url values.

> 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.
>
> [my apologies if my shifting position seems to undermine my case. I  
> have learned much discussing this topic and can see why
> "via"/"via self" has problems and find "source" to be both in the  
> vCard spec and suitable for the usage.)
>
> Again from the vCard RFC:
>>  If the SOURCE type is present, then its value provides information
>>  how to find the source for the vCard.
>
> That seems like what we are looking for.  It is not required to be  
> a URL, but it can be. If a consuming application does not know
> how to resolve the source, then it has no way to continue the path  
> of discovery. That's both reasonable and expected.
>
> 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.
>
> First, I think "the URL at which the current hCard is available" is  
> exactly what we mean.  If a consuming application sets the
> source of the contact to where it found it, we have the "authority"  
> or "relatedness" we are talking about. If the consuming
> application is savvy enough, it can follow any "source" it might  
> find on the page to discover additional information from other,
> synonymous hCards.

I agree.

> Second, I have a hard time believing that modifying the X2V XSLTs  
> to handle the clarified semantic is an unsolvable problem
> /technically/.  It may be hard for political reasons I don't  
> understand, but that is a different issue and I would argue that
> shaping specifications based on politics is bad technology  
> development.

I didn't mean to suggest that it was a unsolvable technical problem,  
but merely a problem of figuring out what the application should do  
and make sure any changes don't break existing content.

> Third, on principle, it seems incredibly arbitrary to make a case  
> for the spec based on any particular implementation.  Just because
> the <blink> and <marquee> tags were implemented in Netscape and IE,  
> respectively, didn't mean that HTML should adopt those
> "innovations." Nor should HTML have been limited to table-based  
> layout just because no browsers had CSS before there was CSS.  The
> spec should evolve to provide the most coherent, consistent, and  
> usable foundation for the most compelling applications, it should
> not arbitrarily be limited based on existing technology.

X2V can be changed. I'm not suggesting that we *don't* change things  
because existing applications deal with them a certain way, but we  
need to be very careful not to break existing applications. Perhaps  
no one depends on the SOURCE returned by X2V. In that case, we can  
change it rather freely, but, if people depend on it we need to be  
careful.

> 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. 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.
>
> So, I think uid+url could address problems 1&2 with a modified  
> algorithm (or perhaps just a clarified one: your algorithm terminated
> on no uid, but you didn't say if that implied relatedness).  
> However, it does not seem capable of addressing non-URL UIDs such as
> XRIs, which are acceptable forms of OpenIDs, which are now being  
> supported as widely by both AOL and Microsoft, two gorrillas who
> are making their own cowpaths in this area. As discussed elsewhere  
> OpenIDs /are/ UIDs.

I understand that Microsoft and AOL will be supporting XRIs, however  
we build microformats based on existing practice on the web. If their  
support leads to people using XRIs, then it will be useful for us to  
support.

(also, yes, we need to clarify my algorithm. I'm not sure what the  
answer should be yet, let me think about it.)

> In contrast, uid+source, without a requirement that source==uid  
> addresses all of the above shortcomings of uid+url, including all of
> the use cases that uid+url supports, with no new fields added to  
> hCard.
>
> So, could you outline in a concise form the fundamental problems  
> you have with uid+source for related hCards?

I don't see any problems other than figuring out what consuming  
applications who convert to vCard should do with SOURCE.

-ryan
--
Ryan King
ryan at technorati.com