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? 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. 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. 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). 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. 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. 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. 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. 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. 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. 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? [1] http://www.faqs.org/rfcs/rfc2426.html [2] http://www.ietf.org/rfc/rfc1738.txt -j -- Joe Andrieu [EMAIL PROTECTED] +1 (805) 705-8651 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
