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

[Joe Andrieu]

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.

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

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.


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

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

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

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

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.

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

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.

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

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

At the moment, the only "market demand" for "related" hCards is in your email.  So, it may be valid and useful, but it doesn't
address the query that started the thread.

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

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

Either there is no difference in the relationship in our proposals or your proposal has /less/ information. If your semantics can be
interpreted as "url" points to a more authoritative version of this hCard, then our proposals are identical in discoverability of
authority.  If somehow you mean that "url" points to another hCard that is neither more nor less authoritative, then it is less
explicit.

An explicit relationship (the way we are discussing here) is a vector, with both a link and a direction. "Relatedness" is not; it
only is a link.  Wether or not we discover the authoritative hCard through network traversal or self-assertion, the ability for
authors to assert relative authority can only help a consuming application, by providing more specific semantic data for evaluation.

I would love to see an algorithm that can discover authority in a set defined by non-directed relationships (uid+url) /more/
accurately than you can discover from a set with optionally directed relationships.  I think the more useful interpretation of
uid+url is that it is also directed, i.e., more authoritative, which leaves the primary distinction between uid+url and via as the
requirement that uid==url for the most authoritative hCards in the chain.

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

The argument is simple: via encompasses all of the functionality of uid+url, without requiring the constraint that uids==urls. It
allows it, but doesn't require it.  Same set of capability. One less constraint. That is less constraining.

Mine is a completely separate argument from your assertive hypothetical question "What better UID is there than a URL?"  I am not
arguing that there are better UIDs than URLs.  I /am/ arguing that there /are/ other UIDs, such as social security numbers, credit
card numbers, etc.  They exist. That is a fact, and is allowed for in the spec.  Whether or not they are good is, IMO, a personal
opinion, or at best a judgment best left to the domain of those building particular webservices.  If /I/ want to offer a webservice
that uses something other than a URL for a UID, why should your opinion prevent me from doing so when the spec allows it?  It
shouldn't. And it also shouldn't prevent me from providing authoritative hCards for users of my webservice.

To clarify, even if you are correct, and URLs are the most awesome mechanism for UIDs, via is still less constraining that url+uid.

Even if some people currently use URLs as UIDs, not everyone does. In fact, most of my URLs in my contact database refer to the
company website, and are not UIDs.  My entire point is that the spec allows non-URL UIDs. As a result, there will be webservices
that are fully compliant that use UIDs that are not URLs.  It seems a pretty straightforward policy to put people before parsers and
allow these compliant webservices/publishers/authors to specify a more authoritative hCard.

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

Ok. That I understand. I spoke briefly with Kevin Marks about this at the Internet Identity Workshop, although he may not recall it
in the terms I'll use here.  

This is cowpathism:

	People don't do it yet, so we can't talk about it.

The fact of this particular catch-22 is that people don't do it because there isn't a coherent mechanism to do it.

However, people do link from one presentation of themselves to alternative presentations of themselves all the time.  However, we
don't have a clear semantic embodiment that clarifies the meaning of that relationship.  When I show up on a conference or workshop
or project web page as an attendee or contribitor or presenter, /sometimes/ it links back to my blog or my home page or my company
page.  The cowpath that could exist would be one where that link has hCards on both ends with a specific directed relationship that
says "that one over there is more authoritative."

Hence, the initial request for a way to have "canonical" hCards.

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

This conversation started with a request for canonical hCards.  Perhaps the posts on this thread would meet your definition of
"hypothetical authors".  I posted an example that remains live, linking a few blog listings (with hCards) at
http://cyber.law.harvard.edu/projectvrm/Blogs back to my corporate hCard.  That makes me a real author.

To respond with your own terminology, I don't actually see a use case for non-directed "related" hCards. However, the above presents
a common use case for expressing "more authoritative" relationships between hCards representing the same entity.  In fact, you could
use "via" or "source" or even "url+uid" for this use case.  The only issue, for me, with url+uid, is it forces publishers to use
URLs as UIDs even when they could be compliant with alternate UIDs. Or when they want to have URLs that aren't their source. For
instance, I would prefer to use my blog as my URL in personal hCards. That blog does not host my "authoritative" hCard, nor will it.

Also, I would like to clarify a shift in my stance.  After thinking about it more, I'm not sure "via self" gains us anything.  "via"
that points to the URL that resolves to the current hCard serves the same purpose, and arguably prevents over-zealous cut & paste
work from replicating an assertion about authority that would be erroneous.  As I mentioned, I also think "source" is a fine
alternative to "via", both seem to have similar semantics.

If "source" means where this particular hCard was harvested, then that seems to mean "more authoritative" to me.  In fact, if the
consuming application extracts the hCard from a web page and finds a "source" field that is resolvable, it /could/ de-reference to
get the more authoritative version. Then, the extracted "authoritive" hCard is "sourced" from the de-referenced hCard address and
everything works.  Alternatively, it could ignore the source, and use the URL of the first hCard as source, allowing any subsequent
consumer to go to the first hCard, discover its source, and begin the dereferencing trail to the most auhoritative hCard in the
chain.

The obvious pathological problem is cyclicly linked hCards.  Nothing can prevent that at the uF level. It's just something
applications will have to handle.

Cheers,

-j

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