[uf-discuss] hCard SOURCE

[Scott Reynen]

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