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

Thu Feb 8 19:33:23 PST 2007

Ryan King wrote:
> On Feb 8, 2007, at 4:49 PM, Joe Andrieu wrote:
> > I'd like to reintroduce @rel="via" to the conversation[1]:
> >    5.  The value "via" signifies that the IRI in the value 
> of the href
> >        attribute identifies a resource that is the source of the
> >        information provided in the containing element.
> >
> > Why not just have a "via" point to "source" hCards and any hCard
> > that is
> > self-referential is  "authoritative"?
> 
> The simple answer is that we may already have a mechanism in hCard/ 
> vCard which is sufficient (ie, UID). We should only look to add  
> things if there is nothing already in the format which is sufficient.
> 
> >   That seems both easy for
> > publishers and relatively straightforward for parsers.  Keep 
> > dereferencing @rel="via" attributes until you find one that
> > dereferences
> > to itself with @rel="via self".  Once you get to one that 
> says "I'm my
> > own source," you've got a reasonable assertion of authority.
> 
> It appears to me that this is essentially the same algorithm as the  
> url+uid proposal, but with adding new terms.

The algorithm is the same, but the semantics are different.
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.

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.

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.

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.

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.

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

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.

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

To restate the algorithm of via+via self in the form you presented url+uid:
1. if no url with a @rel == "via", or if @rel="via self", you're done.
2. if there is a url with @rel == "via", and there is either a solitary hCard at that url or an hCard with the same uid as this
hCard, recurse with the new hCard.

The, @rel attributes would be appropriate for any anchor <a> tag, but could also be used as an adjunct in any url @class attribute,
e.g., @class="url via" or @class="url via self".

Obviously, the == above are not explicit equality, as order shouldn't matter, but it's clearer without a formal regexp or similar.

Ryan Cannon writes:
> One catch: if the value in the URI with @rel=self has to be 
> equivalent, then wouldn't the data embedded in the two hCards 
> have to be exactly the same?

   3.  The value "self" signifies that the IRI in the value of the href
       attribute identifies a resource equivalent to the containing
       element.

Equivalent does not mean congruent.  Equivalent value, for example, doesn't mean you get exactly the same thing, but a thin of
similar value. In this case, we would be asserting the semantic means the same contact entity represented by the hCard.

Ryan Cannon:
> Also, how would @rel="uid" be defined as an HTML linktype, in 
> a manner different than the ATOM definition for @rel="via" 
> (see my previous post)

That's interesting. Atom actually uses "id" rather than "uid".  I'm not sure the best way to deal with that.  Although perhaps
ignoring @rel altogether.  All of the examples I've worked through would work equally well with 
	<span class="url via self">http://joesurl.com/myhCard</span> or
	<a class="via self" href="http://joesurl.com/myhCard">My hCard</a>

Ryan Cannon:
> I suggest that to determine a uid field and authority, hCard 
> parsers look for @class="uid" (parsed as a string, per the 
> current spec not as a URL), that failing, the parsers may 
> optionally follow any links with @rel="via" and attempt to 
> extract a uid from the referenced hCard.

Ryan, this seems to ignore the case where there is a uid that is a url, but which is not the authoritative reference. Again, it
blurs semantics.  Actually, I'm not sure I understand what you mean.

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.

-j

[1] http://www.ietf.org/rfc/rfc4287.txt 

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