[uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel="me self" to indicate anauthoritative hCard)]

[Ryan Cannon]

On Feb 10, 2007, at 2:56 PM, Joe Andrieu wrote:

> Forcing the religion of "uids
> should be urls" on the rest of the world is not why we are here.   
> Making it easy for authors to connect their web content and web
> apps with the semantic web is.  If someone else likes uids that  
> aren't urls, and the spec supports that, then why should we keep
> them from establishing authoritative hCards?
>
> ...
>
> How is via+via self more constraining?  You can do everything you  
> can with uid+url, but you don't have to use URLs for your UIDs.

+1

UID+URL *is* more constraining. Like rel-tag, you're forcing a lot of  
assumptions about the documents *surrounding* these URLs--links have  
to point somewhere after all.

My UID, if you will, is http://ryancannon.com/. I've established it  
across many different sites as the definitive link for "me". By  
forcing UID+URL to be used to establish an hCard's source, you're  
also forcing my most robust hCard must exist at that URL.

However, when I redesign my home page, if I want to move my contact  
information to ryancannon.com/contact my UID shouldn't change--it's  
still just the domain. However, with URL+UID, I'm screwed. With  
@rel=via, I can still have the option to point to my full hCard.

Also, Ryan, you have yet to address the fact that URL+UID changes the  
parsing rules of the hCard--not that I believe it is currently ideal.  
Is it responsible for the community to change the rules of a deployed  
specification willy-nilly? While the implementation in X2V may be  
trivial, it may not be in other applications in the wild--it's also  
not a good precedence to set for uFs in general.

For backwards-compatibility alone, @rel=via seems to me an optimal  
solution.

-- 
Ryan Cannon

Interactive Developer
MSI Student, School of Information
University of Michigan
http://RyanCannon.com