[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]

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 views of the world, and frankly, those who are
> building web services shouldn't be constrained to your particulare  
> view.

I'm pretty sure you mean to insult me by saying that I'm being  
religious. Ad hominem attacks are not a good way to have a productive  
conversation.

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.

>>> 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.

Actual, I don't write the hCard spec and no I wouldn't want to play  
that card.

> 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  
> position will not only be heard, but will be afforded an
> opportunity to influence the spec when their positions have merit.
>
> Respectfully, claiming the right of "editor" and telling me I'll  
> have to find another way to do things because I'm not, is rude and
> counter productive.  I'm half-guessing and half-hoping that you  
> didn't actually mean that paragraph the way I read it.

I never claimed to be the editor of hCard. I'm not the editor. Please  
read the spec to see who the editors actually are. I have to convince  
the editors just like you do.

Once again, please don't make this personal. I disagree with you on  
technical matter for practical reason. I think we both have the same  
desired outcome

>> The difference is that we're defining two different kinds of
>> relationships. I want to define the relationship that two hCards
>> represent the same entity, whereas you want to define something more
>> specific.
>
> Correct. The conversation started with a request for "canonical"  
> hCards, where multiple hCards can refer to "more authoritative"
> hCards, making it easy for short, brief fn+via hCards that can be  
> dereferenced to provide more complete contact information without
> cluttering up the aesthetics or structure of the location of the  
> referring hCard.

I take it that your last comment is a statement about my counter- 
proposal. I think that's an unfair characterization of my proposal.  
In the majority of use cases, people will only need to add the class  
name 'uid' to implement it.

> If all you want to do is have "related" hCards, I recommend fixing  
> XFN so that it allows pointing to specific hCards rather than
> full pages.

First of all, related hCards is *not* "all I want to do. Just because  
I propose that we solve a simpler problem first doesn't mean that I'm  
opposed to moving on to the more difficult/complex problems afterward.

Also, "fixing" XFN as you describe is not desirable, because it would  
mean the introduction of untrustable data to the XFN ecosystem (via  
third-party assertions).

>> I have another objection to your proposal, as well. I don't think
>> even self-asserted authority is useful in this case- imagine this
>> scenario:
>>
>> 1. hCards A, B and C are related (represent the same entity)
>> 2. hCards A and B point at C as authoritative, C asserts the
>> same
>> 3. A and B were updated in 2007, C in 2005
>> 4. A and B agree on everything, C has different data.
>>
>> Now, as one writing a consuming application, what should I do about
>> this? A and B seem more timely, C seems out of date. It doesn't
>> matter that C thinks it's authoritative.
>
> If A & B are updated in 2007 and still point to C as authoritative,  
> then A & B have incorrect data.  That's simple.  Authors will
> sometimes be wrong.  At any given time, hCards may have out of date  
> or inaccurate information.  That accuracy includes both the data
> itself and any referential links the meta-data might use to specify  
> relationships to other hCards.  This is true regardless of
> whether or not we use "authoritative" links or "related" links.  In  
> your example, you seem to be relying on presumptions about A & B
> being more timely.  The timeliness of that data may also be wrong.   
> As a specific example, the timestamp on DNS entry updates is a
> particularly poor measure for the contract information for that  
> entry, as the update may have simply been to change a technical
> contact or renew the subscription.  I've just recently tried to use  
> erroneous contact information from an "up-to-date" DNS entry.
>
> The data can always be wrong.
>
> If you are writing a consuming application, I would encourage you  
> to trust the data as little as possible.

I think we've finally found something we can agree on. :D

>>> The general "relatedness" problem seems to be in the XFN domain and
>>> not really what we are trying to solve in this thread.
>>
>> There are several problems with relying solely on XFN for this, the
>> biggest one being that XFN applies to entire pages, not parts of
>> them. This means that you couldn't apply a rel=me link to
>> just an hCard.
>
> Then perhaps the better solution for the "relatedness" you are  
> looking for is modifying XFN rather shoehorning it into hCards.

That would cover some use cases, but not all. XFN will only work for  
people, not organizations. XFN is also only designed for people  
writing about their own relationships, which makes the data somewhat  
more trustworthy (at least we know person X *believes* they've met  
person Y, even if it's not true). Modifying XFN in the way you  
propose would be a huge change.

>>> Correct me if I'm wrong, but that means only when the uid is an url
>>> can an author assert authority, right?
>>
>> Once again, I think we need to model the relatedness relation first.
>
> That is clear. Why we should do so is not clear.  I'd appreciate  
> hearing a case for putting a throttle on "canonical" or
> "authoritative" hCards while we work through your proposal for  
> "related" hCards.

Because, as explained earlier in the thread, the relatedness relation  
can probably be used to derive the canonical-ness relationship.

> At the moment, the only "market demand" for "related" hCards is in  
> your email.

No it's not. This issues has come up numerous times before and  
several major hcard publishers (like eventful.com) have asked about  
it. Please read the list archives.

> So, it may be valid and useful, but it doesn't address the query  
> that started the thread.

I know that it doesn't address the query that started the thread. As  
I've stated many times, I think we should solve the simpler, easier  
problem first.

> What use case does "related" hCards solve and why should we halt  
> work on "authoritative" hCards while we solve it?

I've already explained both of these. Related hCards allow us to  
collate contact information by person or organization. We should  
defer work on authoritative hCards because, as mentioned above and in  
previous threads, authority can probably be built on top of  
relatedness, but we need to take this work one step at a time.

>>> Related?  The language you had used was "to indicate (relatively)
>>> more authoritative."
>>
>> IIRC, I said "(relatively) more authoritative" was a possible
>> addition to the existing semantics of UID.
>
> Actually, your language is still in the subject. The original  
> thread was for canonical hCards, with a request to vote on rel="me
> self".  You suggested uid+url to indicate a "(relatively) more  
> authoritative hCard."  You have now rounded the corner to state your
> goal as something completely separate from the initial thread:  
> "related" hCards.  In all respect, I really don't know what that
> means or why it would be useful.  However, I am open to hearing  
> from you on those points.

I thought my initial proposal was rather coherent and well connected  
to the previous conversation. We've only been focusing on the UID+URL  
aspect of it because I've gotten questions about it.

My goal is the same as yours. That's never changed. However, I think  
we have at least one intermediate step to take, which is to define  
hCards that are related in that they represent the same person or  
organization. On top of that relationship we can look at building  
authority mechanisms.

Additionally, URL+UID is already being used in the wild, requires  
minimal changes to publisher behavior, and doesn't require adding any  
fields to hCard (which would be incompatible with vCard).

-ryan

1. http://microformats.org/wiki/microformats#the_microformats_principles
--
Ryan King
ryan at technorati.com