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

[Joe Andrieu]

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?

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

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

> >> 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 general "relatedness" problem seems to be in the XFN domain and not really what we are trying to solve in this thread.

Am I misunderstanding what you are getting at?

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

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


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

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.

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

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.

I see the relationship of authority as valuable for other microformats as well, especially hCalendar/vEvent, hResume, and hCite.
(Hence my use of ISBN earlier in the conversation.)  Because I see it as a larger pattern, I'm less inclined to arbitrarily limit
ourselves to hCard's existing semantics. via+via self could be applied anywhere that a brief or transitory microformat could be
linked to a verbose, authoritative microformat.  That re-usability is, IMHO, well worth a slight modification to incorporate two
Atom terms into hCard.

(Although, I acknowledge that uid+url may also be a suitable pattern across uFs. Again, it is all about the *should* of uids as
urls, whereas "via" *must* be an URL, well, an IRI which is mappable to URI for resolution.)

Cheers,

-j

--
Joe Andrieu
joe at andrieu.net
+1 (805) 705-8651