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

> Ryan King:
>>> The problem, IMO, with "uid url" is that the uid for a book, for
>>> example, is more likely an ISBN rather than a URL, so it wouldn't
>>> necessarily be a URI.  Allowing both an ISBN uid and a "via" link
>>> allows
>>> parsers that aware of ISBN to do smart things (such as link to
>>> Amazon if
>>> they wish) /or/ follow the "via" tag for the author's source
>>> reference.
>>
>> I'm not sure how this is relevant. We're talking about hCard here,
>> not a citation format.
>
> That's valid. I ended up being more general in that example than  
> necessary for the simple hCard solution.  (The via semantics could
> apply to any referring/authoritative microformat relationship.)
>
> However, the semantics remain an issue.
>
> url+uid presumes that the uid for the hCard /is/ a url.  I can  
> think of many situations where it isn't and the spec explicitly
> allows non-url uids.  For example, when my school or company lists  
> me in a directory.  The uid in that domain could appropriately be
> my student or employee id, not the url where the authoritative  
> record of my affiliation/status/contact information might be kept.

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.

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.

> For example, this URL could be marked up with an hCard with  
> "personID" as the UID
> http://www.search.caltech.edu/CIT_People_off_campus/action.lasso?- 
> database=CIT_People&-response=Detail_Person.html&-layout=all_field
> s&person_id=16987&-search
>
> Rather than the entire URL. In fact, the URL is probably not a  
> permalink, making the person_id potentially a much more stable id for
> the contact info on that page.  Of course, it all depends on the IT  
> department, but the real issue is that while using permalink
> URLs for uids is elegant, it is not always practical, hence the  
> "SHOULD" in the 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 King:
>> Also, the url+uid proposal only concerns the case where the url and
>> uid are the same (and, therefore, a URL).
>
>> From a different email Ryan also wrote:
>> Problem 1: Not tackling the simplest problem first.
>>
>> 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.

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

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

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.

> 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.
>
> Ryan King:
>> Problem 2: Not understanding the scope of XFN.
>
>> XFN links apply to entire pages, not parts of pages. This means that
>> using XFN links inside multiple hCards on the same page is not
>> possible. Therefore, while using XFN's identity consolidation to
>> consolidate hCards is useful (and can be used regardless of any other
>> mechanisms), it is not sufficient, as it does not allow for the case
>> of multiple hCards on a page, nor does it work for Organizations,
>> only people.
>
>
> @rel="via" is not an XFN link (it is from Atom[1]), but perhaps you  
> were still refering to @rel="self me". However, you bring up a
> good use case that I don't understand how url+uid solves.

Yeah, I was. Sorry, I mixed up the various proposals.

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


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

-ryan
--
Ryan King
ryan at technorati.com