RE: hCard SOURCE

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.backnetwor
k.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/Bl
ogs; 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://microf
ormats.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://microf
ormats.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.switc
hbook.com/#Joe" class="external text"
title="http://www.switc
hbook.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/Blo
gs 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.ne
t/Post/825/DestroyingWalledGardens-Microformatssyndicationan
dAPI's.htm
> [2] - http://www.glennjones.net/downloads/DestroyingWallG
ardens.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
joeandrieu.net
+1 (805) 705-8651

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


_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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.backnetwor
k.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:

ht
tp://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/Blo
gs 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/#c
ontact
http://adactio.com/
articles/1132/
http://flickr.com/peopl
e/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.o
rg/rfc/rfc2119.txt

Peace,
Scott

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss