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.
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.
Also, I don't see what's unkind about building features that leverage
a SHOULD in a 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, I didn't suggest that we introduce new universal
identification scheme.
I'm sorry if I misunderstood you, but it seemed like you were trying
to deal with the problem of referring to hCards without a stable URL
by introducing a new 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.
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.
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.
Remember, UID signifies the entity that the hCard represents and
we're already observed and documented that, in practice, people use
URLs to signify other people and companies. This is encoded in XFN
and works well in practice.
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.
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 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.
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.
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.
Am I misunderstanding what you are getting at?
I dunno. Maybe.
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?
Once again, I think we need to model the relatedness relation first.
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...)
I hope this is the crux of our misunderstanding.
And, no, there's no way to handle multiple UIDs for a single entity.
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."
IIRC, I said "(relatively) more authoritative" was a possible
addition to the existing semantics of UID.
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.
Indeed, this is a different topic. You may not be your stuff, but I
only know you through your stuff. :D
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.
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 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.
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.
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.
-ryan
--
Ryan King
[EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
