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

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.

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

Also, I don't see what's unkind about building features that leverage  
a SHOULD in a spec.

>>> Forcing publishers to synchronize uids with urls may make for a
>>> more elegant standard, but it doesn't meet the test of humans first,
>>> machines second.  Seems to me that authors should be able to
>>> indicate the source/reference/authoritative hCard without
>> having to
>>> use
>>> the source url as their uid.
>>
>> I understand that in many cases we'd like to refer to entities that
>> don't have a stable URL. I'm not sure this is the right place to
>> introduce another universal identification scheme.
>
> Ryan, I didn't suggest that we introduce new universal  
> identification scheme.

I'm sorry if I misunderstood you, but it seemed like you were trying  
to deal with the problem of referring to hCards without a stable URL  
by introducing a new scheme.


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

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

Remember, UID signifies the entity that the hCard represents and  
we're already observed and documented that, in practice, people use  
URLs to signify other people and companies. This is encoded in XFN  
and works well in practice.

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

>>>> Before solving the problem of 'canonical' or
>> 'authoritative' hCards,
>>>> we should solve the problem of 'hcards representing the
>> same person'.
>>>> Before you can have trust you need identity.
>>>
>>> Actually, I think "authoritative" is a simpler, special case of two
>>> hCards representing the same person.  Trying to solve the
>>> general problem of multiple hCards representing the same person is
>>> a mess. Consider:
>>>   school and work directories
>>>   conference bios
>>>   online papers and articles and blog comments
>>>   public records like DMV and the courts
>>>   youtube, flickr, yahoo, and google accounts
>>>
>>> In contrast, the if we can simply assert two claims, we have a
>>> useful relationship that I have already seen much use for:
>>>
>>> 1. This (refering) hCard is a "stub" or abbreviated version of this
>>> other "source" hCard.
>>> 2. This (authoritative) hCard is itself the most authoritative
>>> reference for this hCard.
>>
>> I don't get your point. Your arguement here assumes that we can
>> figure out when two hCards refer to each other as related, which is
>> the simpler problem I'd like to solve.
>
> I think we might be partially agreeing here in a way that isn't  
> very clear.  I'm saying that a general way to define relationships
> between hCards is a harder problem that (a) a specific relationship  
> between two hCards and (b) a unique relationship between an
> hCard and itself (that is, the assertion that this hCard is itself  
> authoritative).

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.

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.

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

> Am I misunderstanding what you are getting at?

I dunno. Maybe.

>>> So, let's look again at your proposal.
>>>
>>> Ryan King:
>>>> Also, the algorithm for finding the most authoritative hCard:
>>>>
>>>> 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
>>>
>>> This only works if you require that the uid be a URL.  The standard
>>> currently allows any
>>> String as uid, stating only that it "SHOULD" be a URL.  Publishers
>>> may want to use non-url UIDs as in the example above or they may
>>> want to use URL uids that are not intended to be authoritative.
>>
>> No, we don't have to require that the UID be a URL. The rule is only
>> activated when the url is a uid (and equal to one of the URL fields
>> of the hCard). People are still free to use non-URL UIDs, but they
>> just don't get the benefit of being connected on the WWW.
>
> 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.

>>> For example, a conference listing may have a bio page for an
>>> individual, use the URL of that bio page as the individual's uid
>>> with a
>>> conference-specific hCard, but support linking back to an
>>> authoritative hCard for that individual.  In fact, the uid on the
>>> conference page could be specific to the refering hCard's domain,
>>> with the authoritative hCard using a different uid.  My conference
>>> uid need not be my personal uid.  Remember, the uid refers to the
>>> hCard, not to the individual, because individuals do not have
>>> singular uids, we only have uids in specific contexts.
>>
>> Actually, you're wrong here. The vcard RFC states about UID:
>>
>> ""
>> To specify a value that represents a globally unique
>>     identifier corresponding to the individual or resource associated
>>     with the vCard.
>> """
>>
>> UIDs identify people and organizations, not their hCards.
>
>
> Ah.  Thank you for the correction.  That's a rather intriguing  
> twist.  Is there any ability to handle multiple UIDs for the same
> entity? (That's totally off-topic...)

I hope  this is the crux of our misunderstanding.

And, no, there's no way to handle multiple UIDs for a single entity.

>> Given that, in the world of microformats, we've already found that
>> people use URLs to identify people, which is one of the assumptions
>> underlying XFN.
>>
>>> uid+url doesn't allow these use cases because it overrides the
>>> semantics of uid and url to forge a new semantic that means
>>> "authoritative".
>>
>> No, it means 'related' or 'representing the same person/company', in
>> the same way that XFN's 'me' property does.
>
> 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.

> As for XFN's 'me', I am not a big fan of the semantics behind that.  
> I've mentioned before that "I am not my stuff."  I am not my
> blog. I am not my flicker account, etc.  But that is also off- 
> topic, here. How XFN represents relationships is a whole different
> ball of wax.

Indeed, this is a different topic. You may not be your stuff, but I  
only know you through your stuff. :D

> However, I don't think we gain anything by having a more vague  
> "related" rather than the explicit "authoritative."  Maybe I'm
> missing something about your point.  I see the one explicit  
> relationship as simpler.  I'm not understanding what you think is
> simpler about a general "relatedness".

Because the explicit relationship isn't helpful. As someone writing a  
consuming application, I don't care that an author thinks their hCard  
is definitive for a given entity, just tell me which ones are related  
and I'll figure out the right data.

>>> In contrast, the semantic meaning of "via" is clearer, more
>>> specific, and affords the same algorithm.  Forging "via self" into
>>> meaning "authoritative" seems much cleaner and a reasonable
>>> bootstrapping technique.  Isn't claiming authority the same as
>>> asserting
>>> that the source of this information is myself? "via self" as
>>> "authoritative" makes great semantic sense to me.
>
>>> @rel="via" and "via self" actually addresses the multiple
>>> authoritative hCards on a page problem. Simply have unique
>> UIDs (as
>>> you
>>> should) for different hCards on the same page (which have the same
>>> URL, hence url cannot equal the uid, except perhaps for one of
>>> the hCards). Unless I misunderstand, the url+uid proposal does not
>>> allow multiple, authoritative hCards on the same page.  via/via
>>> self can enable this by using the UID to find the appropriate
>>> authoritative hCard on the source URL.
>>
>> Yes, url+uid does allow multiple items on a page in the same
>> way that
>> your proposal does. Remember, the algorithm is the same, only the
>> semantics differ.
>
> So, you are indexing the URL into the page with an id to disambiguate?
>
> [this hypothetical example would be at http://www.joeandrieu.com/ 
> index.html]
>
>  <div id="joe" class="vcard">
>   <span class="fn" Joe Andrieu<span>
>   <span class="uid url">http://www.joeandrieu.com/index.html#joe</ 
> span></div>
>
>  <div id="jacqui" class="vcard">
>   <span class="fn" Jacqui Andrieu<span>
>   <span class="uid url">http://www.joeandrieu.com/ 
> index.html#jacqui</span></div>
>
> That does work (and wasn't what I had considered before).
>
>>> In summary, a uid is not necessarily the same as the source URL.
>>> Requiring that the uid=url to state authoritaty destroys semantic
>>> information and constrains publishers unnecessarily. via+via self
>>> retain it without constraining publishers, and can be used in @rel
>>> or @class attributes.
>>
>>
>> On the contrary, I think url+uid is less constraining. It just means
>> "this hcard represents the same person/organization as that other
>> one", which is the simpler and more useful problem we need to solve.
>
> 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.

I don't get this argument. What better UID is there than a URL? Also,  
people already use URLs to signify the enitity which the hCard  
represents.

> I do see the value in not adding to hCard. I've argued elsewhere  
> against the arbitrariness with which "places" became suitable
> entities for hCards.  However, overloading uid+url means that for  
> the case when uids are NOT urls, one cannot assert authority. And
> until the spec moves from *should* to *must*, the spec itself is,  
> IMO, justification enough for that use case.
>
> I don't quite understand why "via" is such a bad thing.  It's  
> adopted as part of Atom and seems to be what we are talking about.
> You might argue that "via self" is an odd construction, but  
> asserting that "self is the source" seems to me much more  
> indicative of
> authority than asserting that "this resolvable url is the unique  
> identifier".

It's not a bad thing and you can already use it without any blessing  
from the spec. I just think it's overkill, unnecessary and doesn't  
reflect existing practice and experience with hCard.

> On the whole, however, I think the only substantive difference  
> between the two is whether or not it is worth adding to hCard to
> support authors who want to use uids that are not urls.

If these hypothetical authors would speak up, we could consider their  
viewpoint, until then I don't actually see a use case for non-URL UIDs.

-ryan

--
Ryan King
ryan at technorati.com