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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
Yeah, I was. Sorry, I mixed up the various proposals.
@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.
...
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.
-ryan
--
Ryan King
[EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
