On Feb 24, 2007, at 5:43 PM, Joe Andrieu wrote:
Brian Suda wrote:
--- this has managed to span several threads and lots of
messages. I have completely lost track of what people are
TRYING to do, what this actually accomplishes? There is a
pretty intereting application that already does an excellent
job of identity consolidation using the tools we have today.
http://webdd.backnetwork.com/
This is an excellent example for anyone lucky enough to have
been at a conference and played with it. There is some
discussion and slides of how it works[1,2]
Brian, from what I could get from the links provided, webdd is
using rel=me and XFN, rather than SOURCE. One potential hurdle with
that is the rel applies to full pages only, and can't point to
individual hCards.
Yeah, even if we could get around the full-page semantics of rel,
rel="me" only indicates identity, which is only half of what I'm
looking for. I agree with Ryan that we should stick with existing
vCard properties for this, specifically UID. But even if we used
rel="me" for that, we'd still have the problem of figuring out which
hCards should be preferred (by applications that want to give
preferential treatment to certain hCards) among a set of hCards all
describing the same person. I think SOURCE is useful for
communicating this, and was intended for exactly that purpose. I'm
not suggesting changing it at all, only including some examples of
how to use it in the hCard spec.
The main thing I would like to be able to do is simply provide a
"brief" hCard that links back to a "full" hCard so that when I show
up where only my name is appropriate, a consuming application (or
individual) can dereference to the full hCard to get my complete
contact information.
Me too.
-- ok, i think i see you point in that each hCard uses SOURCE
to say where they got the information from, but each time you
add something to the chain, the SOURCE is the previous link.
'A' gets the data from 'B' (so A uses B's URL as the SOURCE)
'B' got the data from 'C' (so B uses C's URL as the SOURCE).
Are people publishing in this way already? We want to model
user-behavior that already exists.
Yes. For a single-link chain, look at my example on http://
projectvrm.org/Blogs; others have also stated that they do this
sort of
thing. Following a chain to its "conclusion" would be one way to
discover the "most authoritative", but I'd be happy with just one
dereference for now.
It seems to me that whether one or a chain is followed should be up
to a consuming application, and makes no difference for publishers,
who can only point the hCards we're publishing to better hCards
(regardless of how far the chain continues from there).
For a multi-link chain not hCard encoded, see http://
microformats.org/wiki/irc-people
Or any blog with comments, which generally point to other blogs,
which generally point to author profiles. I think names linking to
better contact information for a person is one of the most common
publishing behaviors on the web. Here's a thousand examples of the
behavior to get us started:
http://kitchen.technorati.com/contact/search/brian
That class of link is what I want to model, and I think "source" is a
good name for the class. (I don't really have any problem with
rel="via" either, as I think the semantic of "via" is applicable to
the entire document, as well as the individual abbreviated hCard.)
Currently, this information is invisible to the semantic web. I
think hCard with authoritative sources would make it easy to make
it visible.
Right.
--- If we are citing where we got the data from, and each
link my previous example is citing (SOURCEing) where it got
the data from, then the X2V implementation does just this.
When it extracts a vCard from an hCard it uses the URL of the
current page as the SOURCE, even if that hCard used SOURCE
and pointed at a different URL. I'm not (and i don't think
you are) advocating following that chain to the end and using
that hCard. We don't do this with the include-pattern for
vairous reasons.
Actually, I am advocating that, specifically for this use case.
I'm finding "advocating" unclear here. In RFC-speak [1], I'm saying
MAY, not SHOULD nor MUST. Personally, I'd prefer consuming
applications that see my hCard on someone else's blog to replace it
with the SOURCEd hCard on my site. But it's no problem if they
don't, as I can always use other applications that do.
The semantic I would like to see encoded is that when a "source"
points to an hCard with the same UID, the source hCard is more
authoritative.
I'd rather not get into defining "authoritative." For my purposes, a
source is more authoritative. But if you want to define
authoritativeness by the length of the hCard, or the publication
date, or whatever makes the most sense for your application, that's
an implementation decision, not defined by the meaning of SOURCE as
far as I can tell.
You could add <a href="/foobar/contact" class="url source">
but it would not get picked-up by extracting applications -
only specialized applications that WANT to follow that chain
to the end.
That's what I'm suggesting.
Which (IMHO) is not needed, we already have an
application, The backnetwork, that does all of this without
the need of UID or SOURCE or any other mark-up.
Could you explain how that works? I read through the slides, the
website, and the blog post, but didn't see how my brief hCard at
http://projectvrm.com/Blogs would be connected back to my hCard at
http://www.switchbook.com.
Yeah, I'm not seeing this solution either. As a publisher, how do I
tell that application that one hCard is a better representation of me
than another? Or as a consumer application, how do I figure that out
with no hints in the markup? As a human, I figure that out by
looking at complicated networks of links and contextual clues. I
know Brian's preferred hCard is here:
http://suda.co.uk/contact/
because the domain is his name and it contains more information than
I find on any of these other hCards with the same name:
http://suda.co.uk/cv/#contact
http://adactio.com/articles/1132/
http://flickr.com/people/suda
But that's very speculative, and I'd like to be able to make it
explicit when incomplete representations of me are published
throughout the web.
Agreed. X2V already generates source so that one /could/
dereference from the vCard to get back to the hCard.
What it doesn't do yet, is dereference down the chain to fill out a
brief hCard based on data at its source. And frankly, if X2V is
at its core an XSLT file, it probably can't do this; please correct
me if I'm wrong.
The bigger problem though, is that you destroy the SOURCE found in
the hCard, so that dereferencing through the source is no longer
possible.
I think what X2V does currently is correct. The hCard URL *is* the
source of the vCard, so that's exactly what it should say. The
SOURCE of the vCard and the SOURCE of the SOURCE of the vCard (i.e.
the hCard SOURCE) are not the same thing, and the hCard SOURCE
shouldn't be used unless the contents of that SOURCE are used in the
vCard, which they're not.
In other words, as a consuming app, I couldn't use the X2V XSLT and
follow the dereferencing chain on my own, correct?
I don't see why you couldn't. The vCard SOURCE tells you exactly
where to start following that chain, by pointing back to the hCard.
Would it be possible to simply /add/ another SOURCE rather than
replacing the one in the hCard? It may seem odd, but I don't think
the vCard standard requries SOURCE to be singular. In other words,
retaining existing SOURCE values and adding one for the URL
where X2V found the hCard seems reasonable and appropriate.
I think it would be inappropriate to claim a URL as a SOURCE that is
not actually a source of the information in the vCard. It doesn't
really matter to me if X2V makes such misleading claims, but I'd
certainly oppose mandating it in a spec.
For the record, I'm ok with both URL and SOURCE being used for this
purpose: If there is a UID, check SOURCE and URL for
dereferencable links to hCards with a similar UID. If an hCard
exists with the same UID at either the URL or SOURCE, consider that
hCard "related".
If an hCards exists with the same UID *anywhere*, consider that hCard
related. Because UIDs are by definition unique to individuals, two
hCards with the same UID can't possibly be unrelated. But I think
SOURCE gives us valuable information that URL does not, specifically
which of two hCards considers the other a source.
I would go further and say that "relatedness" in this context
implies that the dereferenced SOURCE is more authoritative.
I'd say it only implies that for applications that consider SOURCE
more authoritative, and as noted above, there are several competing
definitions of authoritativeness, which should be left to consuming
applications to choose (or not choose) as an implementation decision.
In particular, that SOURCE is a directed relationship from the less
authoritative to the more authoritative.
If you're defining authoritativeness by how recent something is, the
SOURCE goes the opposite direction, from more authoritative to less
authoritative. I'd rather keep this simple and just say SOURCE is
where information was originally found, and however consuming
applications want to use that to determine (or ignore)
authoritativeness is an implementation decision, not defined in the
spec.
[1] http://www.ietf.org/rfc/rfc2119.txt
Peace,
Scott
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
