Re: [uf-discuss] VIA or VIA SELF to indicate authoritativehCard[was:UID URL to indicate (relatively) moreauthoritativehCard(Was:Vote on this: rel=me self to indicateanauthoritative hCard)]
On Feb 14, 2007, at 5:34 PM, Joe Andrieu wrote: Ryan King wrote: On Feb 10, 2007, at 3:09 AM, Joe Andrieu wrote: Ryan King wrote: First off, I'm not saying we should constrain UID to be a URL, but in the case that it *is* a URL, we can apply these semantics. And if the uid is not an url, then authors can't assert authority, correct? I'm not even considering authority for now. We need to just deal with related hCards first. This thread started with discussion about canonical cards, which I recast as authoritative. Everyone else has been discussing that goal. Your commitment to a different mechanism for related hCards might have merit, but it isn't what this conversation started as. I'm well aware of this. Secondly, UID is supposed to be a globally unique identifier, so something like a student id wouldn't qualify. Now if you take those two points together, plus the fact that URLs have a build-in system for distributed, uniform allocation, I think UIDs *should* be URLs. I can't imagine using anything else besides a URL in any useful way. Sure. I understand why uids *should* be urls. But it is not required. Limiting authority to publishers who agree with the spec authors' shouldness is unkind. If uids had to be urls, your argument would be much more compelling. Once again, we should solve the simpler problem of related hCards before we worry about which of a set of related hCards is the most authoritative. Please clarify why a desire for a potentially simpler mechanism solves the problem of canonical or authoritative hCards? This is one of the core principles of microformats solve simpler problems first. [1] The desire that started this conversation was for a referring card to explicitly claim another as canonical. The conversation as evolved for that claim to mean more authoritative. I, for one, would also like to see a way for an hCard to state that itself is the most authoritative hCard it knows of, which would address a way for authors to indicate a canonical or authoritative hCard. If you would also like a mechanism that specifies a non- authoritative relationship, that, I think is a different conversation. 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). Also, I don't see what's unkind about building features that leverage a SHOULD in a spec. Compatibility for one. If you want a service to support all compliant hCards, then it should use the /requirements/ of the spec. If there is a way to enable new services, it should be able to work for all hCards that are compliant with the spec. If you prefer that hCard uids *must* be URLs, then lets talk about changing the spec. It is essentially passive-aggressive to build services that depend on *should* features instead of explicitly changing the spec. If the specs wrong, let's fix it. If it is right, then lets enable services that work for all compliant hCards. There's nothing wrong with building services that depend on parts of a spec that aren't required by a MUST. If people want to make use of the feature they are free to do so. However, in the particular case of hCard's UID, if we were to require URIs for the UID, we would render a large number of vCards unable to be rendered in hCard. That's not a good idea at this point. I am saying that we should use some terms from Atom in hCard to that publishers who have their own uid scheme can still assert authority in hCard. I understand, but unless we can first demonstrate that there's nothing in hCard that can help us, there's no reason to look outside it, even to something as well specified as Atom. I think the deeper problem is that you don't want to support the use case that started this conversation, namely canonical or authoritative hCards. I do want to support it. I really do. But we need to solve the simpler problem (with a simpler solution) first. Forcing the religion of uids should be urls on the rest of the world is not why we are here. I'm not sure why you call it religion. URLs are useful for very practical reasons- it's easy for many people to produce them in such a way that they won't clash and they have the advantage of being dereferencable. I refer to it as a religion, because it is a belief system you hold that URLs as UIDs is /always/ preferable. There are many domains, such as books, where the UID is not best served as a URL and I assert without online evidence that there are plenty of similar domains for individuals (SSN, passport #, driv. License #, etc.). I appreciate your personal disposition that UID as URL is the right way to do things, for your view of the world. But there are other
RE: [uf-discuss] VIA or VIA SELF to indicate authoritativehCard[was:UID URL to indicate (relatively) moreauthoritativehCard(Was:Vote on this: rel=me self to indicateanauthoritative hCard)]
Ryan King wrote: On Feb 10, 2007, at 3:09 AM, Joe Andrieu wrote: Ryan King wrote: First off, I'm not saying we should constrain UID to be a URL, but in the case that it *is* a URL, we can apply these semantics. And if the uid is not an url, then authors can't assert authority, correct? I'm not even considering authority for now. We need to just deal with related hCards first. This thread started with discussion about canonical cards, which I recast as authoritative. Everyone else has been discussing that goal. Your commitment to a different mechanism for related hCards might have merit, but it isn't what this conversation started as. Secondly, UID is supposed to be a globally unique identifier, so something like a student id wouldn't qualify. Now if you take those two points together, plus the fact that URLs have a build-in system for distributed, uniform allocation, I think UIDs *should* be URLs. I can't imagine using anything else besides a URL in any useful way. Sure. I understand why uids *should* be urls. But it is not required. Limiting authority to publishers who agree with the spec authors' shouldness is unkind. If uids had to be urls, your argument would be much more compelling. Once again, we should solve the simpler problem of related hCards before we worry about which of a set of related hCards is the most authoritative. Please clarify why a desire for a potentially simpler mechanism solves the problem of canonical or authoritative hCards? The desire that started this conversation was for a referring card to explicitly claim another as canonical. The conversation as evolved for that claim to mean more authoritative. I, for one, would also like to see a way for an hCard to state that itself is the most authoritative hCard it knows of, which would address a way for authors to indicate a canonical or authoritative hCard. If you would also like a mechanism that specifies a non-authoritative relationship, that, I think is a different conversation. Also, I don't see what's unkind about building features that leverage a SHOULD in a spec. Compatibility for one. If you want a service to support all compliant hCards, then it should use the /requirements/ of the spec. If there is a way to enable new services, it should be able to work for all hCards that are compliant with the spec. If you prefer that hCard uids *must* be URLs, then lets talk about changing the spec. It is essentially passive-aggressive to build services that depend on *should* features instead of explicitly changing the spec. If the specs wrong, let's fix it. If it is right, then lets enable services that work for all compliant hCards. I am saying that we should use some terms from Atom in hCard to that publishers who have their own uid scheme can still assert authority in hCard. I understand, but unless we can first demonstrate that there's nothing in hCard that can help us, there's no reason to look outside it, even to something as well specified as Atom. I think the deeper problem is that you don't want to support the use case that started this conversation, namely canonical or authoritative hCards. Forcing the religion of uids should be urls on the rest of the world is not why we are here. I'm not sure why you call it religion. URLs are useful for very practical reasons- it's easy for many people to produce them in such a way that they won't clash and they have the advantage of being dereferencable. I refer to it as a religion, because it is a belief system you hold that URLs as UIDs is /always/ preferable. There are many domains, such as books, where the UID is not best served as a URL and I assert without online evidence that there are plenty of similar domains for individuals (SSN, passport #, driv. License #, etc.). I appreciate your personal disposition that UID as URL is the right way to do things, for your view of the world. But there are other views of the world, and frankly, those who are building web services shouldn't be constrained to your particulare view. 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? Every specification reflects opinions of its editors as to the best way to do things. I think the best UIDs are URLs. If you don't want to make UIDs that aren't URLs, then you'll have to find another way to refer to people and organizations on the web. Heh. That's rich. I suppose if you want to play the I'm Ryan King and I write the spec, so I'm right card, you win. On the other hand, there are many of us here who would like to believe there is a community process involved and that anyone who is willing and able to make coherent, diplomatic arguments for their
