[uf-discuss] hCard SOURCE

[Joe Andrieu]

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.

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.

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

For a multi-link chain not hCard encoded, see http://microformats.org/wiki/irc-people, and the associated profiles on the wiki. Both
of these /could/ use hCards. Instead, there is no semantic data ANYWHERE indicating how to contact the "irc-people", or even
clarifying that they are contactable entities.  This is a bit of a travesty, given who we are, but this is arguably because we don't
have this particular use case handled.

As an example, let's pick on Brian. =)

In irc-people, he is listed as 

<li> <a href="/wiki/User:Brian" title="User:Brian">briansuda</a> (+0000)

Because we are smart enough to know he's a person (and likely to have contact info) if we pursue the link, we find his profile
http://microformats.org/wiki/User:Brian (excerpted as follows):

<p>Brian Suda
</p><p><a href="http://suda.co.uk/" class="external" title="http://suda.co.uk/" rel="nofollow">http://suda.co.uk</a><span
class="urlexpansion">&nbsp;(<i>http://suda.co.uk/</i>)</span>

Again, because we know Brian is a person and we might believe we can reach him if we continue through the links, we go to suda.co.uk
and eventually get to his contact page where he has is hCard.

Both the irc-people listing /and/ the wiki profiles could be hCards. And could use SOURCE to link from irc-people to the profile,
and from there to a potential additional hCard served on each individual's personal page, as Brian eventually has at
http://suda.co.uk/contact/.

Currently, this information is invisible to the semantic web.  I think hCard with authoritative sources would make it easy to make
it visible.  (I say "easy" with tongue firmly planted in cheek thanks to wikitext's anti-html measures.)


I did not use SOURCE when I wrote the ProjectVRM entry initially because I didn't realize it existed.  I have since changed it to
(as rendered by wiki):
<span class="contact vcard">
  <span class="fn">Joe Andrieu</span>
  [<span class="source uid">
     <a href="http://www.switchbook.com/#Joe" class="external text" title="http://www.switchbook.com/#Joe" rel="nofollow">@</a>
   </span>]
</span>

Unfortunately, I'm getting odd X2V results. At first, the above worked after a fashion, setting the UID to "@" and overides the
SOURCE.  Given the inability in wiki-land to set the class of an anchor tag <a>, how do I specify the UID without having the URL
twice? I tried ABBR, but that isn't allowed in wikitext. After trying ABBR, and returning the initial HTML to the above, X2V stopped
working, simply asserting that there were no vCards.  Hmmph.  I'm sure its some minor bug in my own code, but I haven't yet figured
it out.

> --- 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. 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. In particular, that SOURCE is a signpost to consuming
apps that if they want more details, they should dereference the source.  It is analogous to a "footnote", where you link to more
complete information with a small, unobtrusive mark in the initial context.

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

> I think we agree on some things and are missing each other on 
> other points, hopefully we can clear this up.

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. In other words, as a consuming app, I couldn't use the X2V XSLT and follow the dereferencing chain on my own, correct?

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. Any consuming app can decide whether or not to pursue any or all of the
SOURCEs for more information.

> [1] - 
> http://www.glennjones.net/Post/825/DestroyingWalledGardens-MicroformatssyndicationandAPI's.htm
> [2] - http://www.glennjones.net/downloads/DestroyingWallGardens.pdf

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".  Also, I am ok with both UID and SOURCE being other than URLs.  If the consuming application doesn't recognize the
format as dereferenceable, then it doesn't dereference.

I would go further and say that "relatedness" in this context implies that the dereferenced SOURCE is more authoritative.  In
particular, that SOURCE is a directed relationship from the less authoritative to the more authoritative.  This seems entirely
consistent with the real-world meaning of source. If we we want URL as an undirected "related" relationship, ok, that's a fine
distinction.  I could see how linking between hCards without specifying authority might be desirable.  As long as I can use a
non-url UID and SOURCE to point to a more complete hCard, my use case would be addressed.

-j

--
Joe Andrieu
joe at andrieu.net
+1 (805) 705-8651

"An inconvenience is an adventure wrongly considered. An adventure is only an inconvenience rightly considered."
--G. K. Chesterton