Re: VIA or VIA SELF to indicate authoritativehCard[was:UID URL to indicate (relatively)

On Feb 14, 2007, at 5:34 PM, Joe Andrieu wrote:

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

I'm well aware of this.

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

This is one of the core principles of microformats
"solve simpler  
problems first." [1]

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

I understand this. I agree that this is a desirable goal. I
would  
personally like to see it happen. However, the simpler
problem of two  
hcards representing the same person (or organization) should
be  
solved first, because it is a simpler problem, with a
simpler  
solution (which may not require adding any properties to
hCard).

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

There's nothing wrong with building services that depend on
parts of  
a spec that aren't required by a MUST. If people want to
make use of  
the feature they are free to do so. However, in the
particular case  
of hCard's UID, if we were to require URIs for the UID, we
would  
render a large number of vCards unable to be rendered in
hCard.  
That's not a good idea at this point.

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

I do want to support it. I really do. But we need to solve
the  
simpler problem (with a simpler solution) first.

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

I'm pretty sure you mean to insult me by saying that I'm
being  
religious. Ad hominem attacks are not a good way to have a
productive  
conversation.

Also I'm not saying that UID-as-URI is the "right"
way to do things.  
I'm just saying that it's the most useful way to do things.

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

Actual, I don't write the hCard spec and no I wouldn't want
to play  
that card.

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

I never claimed to be the editor of hCard. I'm not the
editor. Please  
read the spec to see who the editors actually are. I have to
convince  
the editors just like you do.

Once again, please don't make this personal. I disagree with
you on  
technical matter for practical reason. I think we both have
the same  
desired outcome

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

I take it that your last comment is a statement about my
counter- 
proposal. I think that's an unfair characterization of my
proposal.  
In the majority of use cases, people will only need to add
the class  
name 'uid' to implement it.

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

First of all, related hCards is *not* "all I want to
do. Just because  
I propose that we solve a simpler problem first doesn't mean
that I'm  
opposed to moving on to the more difficult/complex problems
afterward.

Also, "fixing" XFN as you describe is not
desirable, because it would  
mean the introduction of untrustable data to the XFN
ecosystem (via  
third-party assertions).

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

I think we've finally found something we can agree on. 

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

That would cover some use cases, but not all. XFN will only
work for  
people, not organizations. XFN is also only designed for
people  
writing about their own relationships, which makes the data
somewhat  
more trustworthy (at least we know person X *believes*
they've met  
person Y, even if it's not true). Modifying XFN in the way
you  
propose would be a huge change.

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

Because, as explained earlier in the thread, the relatedness
relation  
can probably be used to derive the canonical-ness
relationship.

> At the moment, the only "market demand" for
"related" hCards is in  
> your email.

No it's not. This issues has come up numerous times before
and  
several major hcard publishers (like eventful.com) have
asked about  
it. Please read the list archives.

> So, it may be valid and useful, but it doesn't address
the query  
> that started the thread.

I know that it doesn't address the query that started the
thread. As  
I've stated many times, I think we should solve the simpler,
easier  
problem first.

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

I've already explained both of these. Related hCards allow
us to  
collate contact information by person or organization. We
should  
defer work on authoritative hCards because, as mentioned
above and in  
previous threads, authority can probably be built on top of 

relatedness, but we need to take this work one step at a
time.

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

I thought my initial proposal was rather coherent and well
connected  
to the previous conversation. We've only been focusing on
the UID+URL  
aspect of it because I've gotten questions about it.

My goal is the same as yours. That's never changed. However,
I think  
we have at least one intermediate step to take, which is to
define  
hCards that are related in that they represent the same
person or  
organization. On top of that relationship we can look at
building  
authority mechanisms.

Additionally, URL+UID is already being used in the wild,
requires  
minimal changes to publisher behavior, and doesn't require
adding any  
fields to hCard (which would be incompatible with vCard).

-ryan

1. http://microformats.org/wiki/microformats#t
he_microformats_principles
--
Ryan King
ryantechnorati.com



_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Feb 20, 2007, at 1:05 PM, Ryan King wrote:

> However, the simpler problem of two hcards representing
the same  
> person (or organization) should be solved first,
because it is a  
> simpler problem, with a simpler solution (which may not
require  
> adding any properties to hCard).

The implication I've always taken from the "simpler
problem first"  
principle is that this makes the more complex problems
easier to  
solve.  But this is only true if the simpler problem
actually helps  
solve the more complex problem.  Related hCards is also a
simpler  
problem than book citations, but we don't half that
discussion  
because solving the simpler problem has no descernable
impact on the  
more complex problem.  I think what's confusing those of us 

interested in the more complex problem of authoritative
hCards is how  
solving related hCards would actually help solve that
problem.

And maybe that's because what you're describing is actually
more  
specific that "related hCards" implies.  It seems
here you're just  
talking about a single relationship: identity.  My brother's
hCard is  
related to mine, but those aren't two hCards representing
the same  
person.  If representing the same person is your primary use
case, I  
don't think "related hCards" communicates this
very clearly.   
Similarly, "canonical" didn't communicate the
concept of  
"authoritativeness" very clearly, because it
suggested much more than  
we needed.  I'm not sure what would be a better word to
communicate  
identity relationships, but I think that would clear up a
lot of  
confusion if the above is the full scope of the problem
you're trying  
to solve.  If, however, you are trying to also come up with
a way for  
me to indicate that my brother's hCard is related to mine, I
don't  
see how that will move the authoritative hCard problem
forward at  
all, and it seems to unnecessarily complicate the issue. 
Identity is  
a simpler problem than relationships in general, right?  And
it's  
also a clear building block toward authoritative hCards.  So
what  
about focusing on that simple problem instead of a more
general  
"related hCards"?

Peace,
Scott

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Ryan King wrote:
> I understand this. I agree that this is a desirable
goal. I would  
> personally like to see it happen. However, the simpler

> problem of two  
> hcards representing the same person (or organization)
should be  
> solved first, because it is a simpler problem, with a
simpler  
> solution (which may not require adding any properties
to hCard).

If all you want to do is have two hCards represent the same
entity, why not just use the same UID?

I think I understand that it is to traverse the network to
discover multiple, "synonymous" hCards for the
same entity? That what you
want is not just synonymity, but discoverable synonymity. Is
that correct?


RFC2426 [1] (the vCard spec incorporated by reference into
hCard) specifies the URL type use as:
   To specify a uniform resource locator associated with
   the object that the vCard refers to.

Your algorithm was:
> 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

In that case, what you are saying is that if the UID is the
same as the URL, one should expect to be able to assume a
common
relationship between this hCard and any hCard with either no
UID or a matching UID at the URL for this hCard.

Here's what seems to fail in this usage:
1. Referrees without UID match any referring hCard
2. Ambiguous relation when multiple hCards are present at
URL
3. UIDs that are XRIs and not URLs
4. UIDs that are not URLs, generally.

1. Referrees without UID match any referring hCard
If the referred to hCard has no UID, the algorithm assumes
"relatedness", but that seems dubious at best
without a confirming UID.

2. Ambiguous relation when multiple hCards are present at
URL
If the referred to URL has multiple hCards, each with no
UID, there is no way to disambiguate which one(s) should be
"related."

So... Refering card:
<span class="vcard">
<span class="fn">Mr. Andrieu</span>
<span class="uid url">http://www.andrie
u.net</span>
</span>

While on Andrieu.net we might have multiple hCards
<span class="vcard">
<span class="fn">Joe Andrieu</span>
</span>
<span class="vcard">
<span class="fn">Julia Andrieu</span>
</span>
<span class="vcard">
<span class="fn">Mike Andrieu</span>
</span>
<span class="vcard">
<span class="fn">Maureen
Andrieu</span>
</span>

Who is "Mr. Andrieu"?

This is even more likely to occur when we accept the dynamic
nature of the web and the inevitable consistency errors of
less-than-perfect data maintenance.  It seems to me that
relating only cards with common UIDs makes a lot of sense.

3. UIDs that are XRIs and not URLs

With the use of OpenID as UID, do we extend the field URL to
include XRIs?  This may or may not make sense, but stuffing
an XRI into
a URL/URI is out of spec unless the spec changes to allow
it. XRIs are designed to replace URIs, but plenty of
consuming
applications break today if you try that.

4. UIDs that are not URLs
I stand by the argument that UIDs that are not URLs should
be viable in any mainstream use of any microformat. Your
bias towards
URLs as UIDs shouldn't limit people's use of UIDs with
alternate formats, such as XRIs.  If we feel strongly about
such a bias, as a
community, we should change the hCard spec to require UIDs
as URLs.   XRIs as UIDs is just /one/ example where I think
the evidence
is overwhelmingly clear that there is technical acceptance
and solid reasoning for UIDs that are not URLs.  Now, we
could change the
definition of "URL" to include "XRIs",
but I think we are better off accepting that we cannot
predict the future, nor should we
presume that URLs are the only good UID unless we are
willing to make that a requirement in the spec. And frankly,
that would put
our definition of URL at odds with RFC for URLs.[2]  The
spec uses "should" for good reason. It is because
of that *should* that XRI
UIDs are 100% compliant with hCard /today/ without
redefining the spec. That's a good thing. Making URL UIDs a
requirement for
discovering synonymous hCards seems arbitrarily limiting
with minimal payoff.

Items 1 & 2 could be trivially addressed by simply
modifying your algorithm to require that the UID of the
/referred to/ hCard match
the UID of the referring hCard for anything to work. So they
aren't major issues. (And it is clear that in the brevity of
your
algorithm, you didn't say termination assumed
"relatedness", so 1&2 aren't all that
important.)

However, non-URL UIDs, as exemplified by XRIs as UIDs is a
fundamental problem that you have not satisfactorily
addressed other than
by asserting 
> What better UID is there than a URL?

You also stated:
> Indeed, in vcard UID is just a string, but my proposal
is that we  
> make it by default a URL. It's a simple change (which
may already be  
> implemented in X2V).

Your disposition is clearly yours, not what the spec
reflects, and you have yet to make a solid case for it, much
less secured
community support for changing to that default.  I referred
to your disposition as a religious belief not to insult you,
but to
clarify that is an assertion of your presumptive belief. 
From your arguments, I have nothing but your faith in URLs
as UIDs, no
evidentiary arguments have been presented.  If the core of
your argument is that UIDs are supposed to be URLs, that is
a completely
different proposal than both this thread and the originating
thread (canonical hCards) is talking about.

You later stated:
> Also I'm not saying that UID-as-URI is the
"right" way to do things.  
> I'm just saying that it's the most useful way to do
things."

For many applications, XRIs are arguably more useful. In
fact, I think XRIs answer your initial question adequately.
They are a
better UID than a URL.  Your simple assertion of your
opinion is a statement of belief, rather than a compelling
argument.  My
assertion that XRIs are better is also a statement of
belief. However, there are a lot of other smart people that
also disagree on
this topic (in both directions). Debating it here would be
off-topic to say the least.  However, the acceptance of the
viability of
XRI by a significant community is itself sufficient
challenge to your blanket assertion of the "most
usefulness" of URLs as UIDs.
Other UID schemes can be just as useful, perhaps more so.

Because of that, I strongly feel that requiring UID=URL as
the only vehicle for discovering synonymous hCards is a huge
mistake.
More importantly, requiring that UIDs be URLs is a
proposal/debate in, and of itself.  It is currently
sidetracking this discussion
of how we might relate (potentially authoritative) hCards to
each other.


Instead, I would like to propose that "source" be
traversed to discover synonymous hCards, relying on UIDs for
association, without
requiring that source == UID prior to traversal.

[my apologies if my shifting position seems to undermine my
case. I have learned much discussing this topic and can see
why
"via"/"via self" has problems and find
"source" to be both in the vCard spec and suitable
for the usage.)

Again from the vCard RFC:
>  If the SOURCE type is present, then its value provides
information
>  how to find the source for the vCard.

That seems like what we are looking for.  It is not required
to be a URL, but it can be. If a consuming application does
not know
how to resolve the source, then it has no way to continue
the path of discovery. That's both reasonable and expected.

Previously, you objected:
> SOURCE is already used by X2V to indicate the URL at
which the  
> current hCard is available. I don't think we'd be able
to override  
> that at this point.

I respect the work done by Brian Suda and others on X2V, but
this argument doesn't pass the smell test.

First, I think "the URL at which the current hCard is
available" is exactly what we mean.  If a consuming
application sets the
source of the contact to where it found it, we have the
"authority" or "relatedness" we are
talking about. If the consuming
application is savvy enough, it can follow any
"source" it might find on the page to discover
additional information from other,
synonymous hCards.

Second, I have a hard time believing that modifying the X2V
XSLTs to handle the clarified semantic is an unsolvable
problem
/technically/.  It may be hard for political reasons I don't
understand, but that is a different issue and I would argue
that
shaping specifications based on politics is bad technology
development.

Third, on principle, it seems incredibly arbitrary to make a
case for the spec based on any particular implementation. 
Just because
the <blink> and <marquee> tags were implemented
in Netscape and IE, respectively, didn't mean that HTML
should adopt those
"innovations." Nor should HTML have been limited
to table-based layout just because no browsers had CSS
before there was CSS.  The
spec should evolve to provide the most coherent, consistent,
and usable foundation for the most compelling applications,
it should
not arbitrarily be limited based on existing technology.  

And indeed, both of us are suggesting an incredibly minor
change to the extended semantics of a single field to
support a particular
use case. URL and SOURCE will still mean basically the same
thing as always.  However, an additional implied semantic
would enable
discovery of synonymous cards. This seems like an odd item
to limit based on existing XSLT files.

So, I think uid+url could address problems 1&2 with a
modified algorithm (or perhaps just a clarified one: your
algorithm terminated
on no uid, but you didn't say if that implied relatedness).
However, it does not seem capable of addressing non-URL UIDs
such as
XRIs, which are acceptable forms of OpenIDs, which are now
being supported as widely by both AOL and Microsoft, two
gorrillas who
are making their own cowpaths in this area. As discussed
elsewhere OpenIDs /are/ UIDs.

In contrast, uid+source, without a requirement that
source==uid addresses all of the above shortcomings of
uid+url, including all of
the use cases that uid+url supports, with no new fields
added to hCard.

So, could you outline in a concise form the fundamental
problems you have with uid+source for related hCards?

[1] http://www.faqs
.org/rfcs/rfc2426.html
[2] http://www.ietf.o
rg/rfc/rfc1738.txt

-j

--
Joe Andrieu
joeandrieu.net
+1 (805) 705-8651


_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss