[uf-discuss] Canonical hCards (was: Search on CSS element)
David Janes
what's on my mind...
On 1/23/07, Ryan King <ry...@technorati.com> wrote:
>
> It's not a full CSS selector based search engine, but http://
> kitchen.technorati.com/contacts/search/tantek.
>
Wouldn't it be great if there was a well defined way of getting from
_an_ instance of a hCard to the _best_ (or canonical) hCard for that
person.
Just saying; I know that some work has been done on this.
Regards, etc...
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
_______________________________________________
microformats-discuss mailing list
microforma...@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Tantek Çelik
> Continuing the tradition of riffing off other threads to talk about
> what's on my mind...
>
> On 1/23/07, Ryan King <ry...@technorati.com> wrote:
>>
>> It's not a full CSS selector based search engine, but http://
>> kitchen.technorati.com/contacts/search/tantek.
>>
>
> Wouldn't it be great if there was a well defined way of getting from
> _an_ instance of a hCard to the _best_ (or canonical) hCard for that
> person.
>
> Just saying; I know that some work has been done on this.
David Janes, you're right, we need to solve this problem.
I did some research on examples in the wild and possible approaches here:
<http://microformats.org/wiki/hcard-brainstorming#hCard_to_hCard_relationshi
ps>
Please take a look and add your thoughts on the problem-space and/or
examples you have found in the wild for each type of "canonicalization"
(there are more than one).
Thanks,
Tantek
David Janes
> David Janes, you're right, we need to solve this problem.
>
> I did some research on examples in the wild and possible approaches here:
>
> <http://microformats.org/wiki/hcard-brainstorming#hCard_to_hCard_relationshi
> ps>
>
> Please take a look and add your thoughts on the problem-space and/or
> examples you have found in the wild for each type of "canonicalization"
> (there are more than one).
Well, strangely enough I do have ideas in this area. I'm going to
outline them here and move them into the wiki tomorrow, in case
there's interesting discussion.
My starting assumptions are:
- no changes should be needed to a hCard that has a "url"
- hinting is allowed, but not needed
- we follow the OpenID model of indirection [1]
The idea works like this:
- a consumer sees a hcard, say
<address class="author vcard">
<a class="url fn" href="http://theryanking.com">Ryan</a>
</address>
- the consumer looks at "http://theryanking.com"
- if the consumer sees a <link> element like the following, it knows
there is a canonical hCard. The title must be the same as the "fn" (?)
<link rel="identity.hcard" title="Ryan"
href="http://theryanking.com/blog/contact/#vcard" />
- the consumer reads this page
("http://theryanking.com/blog/contact/") and finds the canonical hCard
at id "vcard"
Notes:
- if the non-canonical hCard url has a fragment and that points to a
hCard, assume we are done
- if there is no fragment in the non-canonical hCard url, a <link> is required
- if the link does not have a fragment, the first hCard on the page is
the one we use
- I've documented this here [2] (but discuss here please)
- we could add an extra class element, say "canonical" that could be
used in conjuction with the url to guarentee there is a canonical
hCard to be found; I'm not really sure if this is necessary though.
Regards, etc...
David
[1] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2006-09-12-0001/
[2] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2006-09-12-0003/
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
_______________________________________________
Tantek Çelik
> On 1/23/07, Tantek Çelik <tan...@cs.stanford.edu> wrote:
>> David Janes, you're right, we need to solve this problem.
>>
>> I did some research on examples in the wild and possible approaches here:
>>
>> <http://microformats.org/wiki/hcard-brainstorming#hCard_to_hCard_relationshi
>> ps>
>>
>> Please take a look and add your thoughts on the problem-space and/or
>> examples you have found in the wild for each type of "canonicalization"
>> (there are more than one).
>
> Well, strangely enough I do have ideas in this area. I'm going to
> outline them here and move them into the wiki tomorrow, in case
> there's interesting discussion.
>
> My starting assumptions are:
>
> - no changes should be needed to a hCard that has a "url"
> - hinting is allowed, but not needed
I agree with those.
> - we follow the OpenID model of indirection [1]
I disagree because it involves invisible metadata.
We should avoid <link> and MUST avoid <meta> for that reason in
microformats.
> The idea works like this:
Document Examples in the Wild first of people linking to their and others'
hCards, and that will drive the scope of the solution.
Brainstorming will be much better AFTER we have documented examples in the
wild and can then reason using those examples rather than hypothetical
examples.
> - a consumer sees a hcard, say
>
> <address class="author vcard">
> <a class="url fn" href="http://theryanking.com">Ryan</a>
> </address>
>
> - the consumer looks at "http://theryanking.com"
>
> - if the consumer sees a <link> element like the following, it knows
> there is a canonical hCard. The title must be the same as the "fn" (?)
>
> <link rel="identity.hcard" title="Ryan"
> href="http://theryanking.com/blog/contact/#vcard" />
I'm ok with entertaining a new rel value as indicated on
<http://microformats.org/wiki/hcard-brainstorming#hCard_to_hCard_relationshi
ps> but not ok with requiring or requesting use of <link> for this.
Any such links should use <a href> and be visible.
> - the consumer reads this page
> ("http://theryanking.com/blog/contact/") and finds the canonical hCard
> at id "vcard"
This part I believe a reasonable end goal.
> Notes:
> - if the non-canonical hCard url has a fragment and that points to a
> hCard, assume we are done
I don't think that can be assumed, because it is a 3rd party link (most
likely). The 1st party may have changed the fragment at the destination
etc.
> - if there is no fragment in the non-canonical hCard url, a <link> is required
<link> should never be required, and should be avoided.
> - if the link does not have a fragment, the first hCard on the page is
> the one we use
That's a reasonable fallback, but before that, I'd even advocate looking for
the first <address> that is or contains an hCard on the page, since that's
following prescribed behavior from HTML4.
> - I've documented this here [2] (but discuss here please)
> - we could add an extra class element, say "canonical" that could be
> used in conjuction with the url to guarentee there is a canonical
> hCard to be found; I'm not really sure if this is necessary though.
I'm not sure that is necessary either, as the opinion of "canonicality" is
not from an item itself but rather from references to that item which tends
make it more like a relationship rather than just a class.
> Regards, etc...
> David
>
> [1] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2006-09-12-0001/
> [2] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2006-09-12-0003/
Thanks David Janes,
Tantek
Scott Reynen
> Document Examples in the Wild first of people linking to their and
> others'
> hCards, and that will drive the scope of the solution.
Does this need to be limited to hCard? I think identifying pointers
to a canonical source of data is a broader problem, as copying and
manipulating data between sites is a standard activity on the web.
Any search engine is full of links back to canonical sources.
Trackbacks are links back to canonical sources. Bloggers quoting
each other typically link back to canonical sources. Pingerati has
three links back to canonical sources of what could be abbreviated
hcards (fn only), and right under that is the same thing for events
and reviews. Can we expand the types of examples we're looking at?
Peace,
Scott
Tantek Çelik
> On Jan 23, 2007, at 4:09 PM, Tantek Çelik wrote:
>
>> Document Examples in the Wild first of people linking to their and
>> others'
>> hCards, and that will drive the scope of the solution.
>
> Does this need to be limited to hCard?
It doesn't *need* to be no, but in the interest of "solve a specific
problem" (principle #1 [1]), let's solve this for hCard first, with real
world hCard examples driving the design.
> I think identifying pointers
> to a canonical source of data is a broader problem, as copying and
> manipulating data between sites is a standard activity on the web.
Agreed. However I find that the specific types of data may have specific
canonicalization semantics that we should be careful not to accidentally
overlook (we may choose to later overlook them explicitly in the interest of
creating a building block that can be used across formats, but that should
be an explicit decision, not an incidental one).
> Any search engine is full of links back to canonical sources.
Actually I find that most search engines are full of links back to
*multiple* sources of often the same thing without any semantic on
canonicality presented or implied.
> Trackbacks are links back to canonical sources. Bloggers quoting
> each other typically link back to canonical sources. Pingerati has
> three links back to canonical sources of what could be abbreviated
> hcards (fn only), and right under that is the same thing for events
> and reviews. Can we expand the types of examples we're looking at?
None of those examples given are actually "canonical" sources, they're
merely citations and quotations of sources (for which we have existing HTML
semantics for: <cite> <q cite> <blockquote cite>. The semantic of
canonicality is not necessarily implied, only that the content came from
somewhere else, not that that somewhere else is the best / most
representative (i.e. canonical) instance of that content.
Thanks,
Tantek
[1] http://microformats.org/wiki/microformats#the_microformats_principles
Joe Andrieu
I think we don't mean "canonical" here, and perhaps fixing that will
clarify a use case that distinguishes the opportunity.
Canonical means part of a canon, or of the form of the canon, especially
when used in the sense of converting a morphological entity into an
alternative form. 2007/06/05 and June 6, 2007 both represent the same
date, only one can be canonical for any given canon. We tend to like
ISO as a canon around here. Canonical forms are articularly useful when
sorting, comparing, or looking up things that could be presented in
alternative formats.
What I think is much more useful is /authoritative/ hCards. Meaning
that this is the author's truth for this reference. The authoritative
reference is the root source of the reference. It is close to
definitive, but definitive assumes objectivity, whereas authoritative
retains the subjectivity of the author.
This sense of subjectivity is where hCards can play a huge role. An
authoritative hCard is, in effect, making a claim that it /is/ the
authoritative source for this data. It is not objective truth, simply a
claim by the author.
A few two major things happen when you do this:
1. You enable an hCard author to semantically declare this hCard as
"definitive"
2. You could provide a link from a refering hCard to the authoritative
hCard for discovery of additional information that isn't appropriate for
the design or context of the "refering" hCard.
If an authoritative hCard URL is also a permalink, it could then become
a single point of updates and changes that can suitably propagate out to
the world, a la Linked In.
Furthermore, if the authoritative representation is dated in some way,
one might be able to discern between out of date and current claims to
authority on a topic. (However, I definitely don't regard assertions
about chronological superiority as valid means to disambiguate such
claims; this is definitly a "hypothetical").
And to skip a bunch of other hypotheticals out there, I think it also
doesn't really matter if there are multiple "authoritative" hCards out
there. What's useful is allowing someone to distinguish a claim to
authority for an hCard (say on my website) that is knowably distinct
from simple refering hCards (say on http://projectvrm.org where I am a
contributor; examples follow.) False or duplicate claims to authority
are red herrings. The real value is to say "this isn't authoritive; and
btw, you might go look over there."
So, I think there are two different uses here that actually require two
different solutions.
(1) to be able to indicate a claim that an hCard is authoritative.
(2) to be able to link a "brief" hCard to a source that was considered
authoritative (or even just /more/ authoritative) at the time the brief
hCard was created, in order to provide potentially more up-to-date
and/or more detailed information.
For instance, I currently present my information on my business website
as the authoritative "business" hCard for me and as a result of this
conversation, I've linked to that from Project VRM using hCard
semantics.
(1) my "authoritative" hCard
http://www.switchbook.com
<div class="contact vcard">For inquiries:<br/>
<div class="fn">Joe Andrieu</div>
<a class="email"
href="mailto:j...@switchbook.com">j...@switchbook.com</a><br/></a>
<div class="tel">+1 (805) 705-8651</div>
<a class="url org" href="http://www.switchbook.com"><span
class="switch">Switch</span>Book Software</a>
<div class="adr">
<span class="street-address">2032-A Chapala St.</span>, <span
class="locality">Santa Barbara</span>, <span class="region">CA</span>
<span class="postal-code">93105</span>
</div>
<br/>You may also want to check out my <a
href="http://blog.joeandrieu.com/">blog</a>.
</div>
(2) a reference to it where a full hCard is impractical:
http://cyber.law.harvard.edu/projectvrm/Blogs#Blog_posts_on_VRM
It is in a wiki:
<span class="contact vcard"><span class="fn">Joe
Andrieu</span><nowiki>[</nowiki><span class="url
org">[http://www.switchbook.com/ @]</span></span><nowiki>]</nowiki>
Which generates:
<span class="contact vcard"><span class="fn">Joe Andrieu</span>[<span
class="url org"><a href="http://www.switchbook.com/" class="external
text" title="http://www.switchbook.com/"
rel="nofollow">@</a></span></span>]
And looks pretty much how I want:
Joe Andrieu [@]
With the @ sign the link to the "authoritative" hCard.
If we presume for the moment that http://www.switchbook.com is the
authoritative reference for my hCard in this context, then, I /think/
that addresses use case #2, above, correct? The URL class in the hcard
point to a "more authoritative" hCard, where I have far more information
than fit in the reference at Project VRM.
However, we still have no official way for me to indicate in the hCard
at http://www.switchbook.com that it is an authoritative reference.
Unless we use the self-referencing URL trick to indicate
"authoritative", in which case the current example solves both (1) and
(2). In effect, citing oneself as the "more authoritative" hCard means
that /this/ hCard is the most authoritative available (at the time of
creating the hCard, to the best knowledge of the author, etc.).
Working through this leads me to think that an hCard that exists at its
self-referenced URI should be considered "authoritative."
-j
p.s. I'd appreciate feedback on any errors in the above microformats.
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
David Janes
I agreee with Joe that "canonical" is the wrong word. "authorative" is
better. "best" is too vague.
On 1/23/07, Tantek Çelik <tan...@cs.stanford.edu> wrote:
> On 1/23/07 1:05 PM, "David Janes" <david...@blogmatrix.com> wrote:
>
> > On 1/23/07, Tantek Çelik <tan...@cs.stanford.edu> wrote:
> >> Please take a look and add your thoughts on the problem-space and/or
> >> examples you have found in the wild for each type of "canonicalization"
> >> (there are more than one).
>
> Brainstorming will be much better AFTER we have documented examples in the
> wild and can then reason using those examples rather than hypothetical
> examples.
(1)
OK, I'm not going to get in a pissing match over this but you did ask
what's my _thoughts_ on this.
In any case, can we do this in a non-prescriptive manner - are we not
entering new terroritory here? We know
(a) people want this problem solved
(b) people are not solving this problem because they're waiting for
some to tell them how
Let me ask this: is there a _single_ example out there of what we want to do?
(2)
I disagree with you on the LINK matter, because I think
(a) it's not, strictly speaking, part of the microformat; it's a
description of behaviours to do with a microformat
(b) if they get it wrong, it is unlikely to introduce incorrect data
(i.e. graceful failure)
(c) "home page" (i.e. url) as a directory of sorts using LINK is a
well-understood (OpenID) and well-used (RSS/Atom) concept
However, I'm not going to getting in a fight over this either. No LINKs.
(3)
Do you (Tantek + all) agree with the following "architecture", or it
least think it's worth pursuing further:
(a) hCards without additional markup; "url" is used to lookup a URL
(b) at the URL we can either find:
(b.i) the authorative hCard; OR
(b.ii) a pointer to authorative URL with the authorative hCard
(c) it's easy to find the authorative hCard on the authorative URL
I'm sure we have the technology to to (b.ii), I just don't know if
anyone has done it. Anyone?
The reason I'm asking is I'm more willing to plug work into this, but
not if you've already decided that this approach will not work.
Regards, etc...
David
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
_______________________________________________
Brian Suda
> Do you (Tantek + all) agree with the following "architecture", or it
> least think it's worth pursuing further:
>
> (a) hCards without additional markup; "url" is used to lookup a URL
> (b) at the URL we can either find:
> (b.i) the authorative hCard; OR
> (b.ii) a pointer to authorative URL with the authorative hCard
> (c) it's easy to find the authorative hCard on the authorative URL
>
> I'm sure we have the technology to to (b.ii), I just don't know if
> anyone has done it. Anyone?
I believe that http://rubhub.com/main/ acts in a similar manner. When
it finds XFN values it continues to crawl those URLs.
In a similar vein, an hCard spider could find hCards in a page with a
URL. They could then follow that URL to the person's page. Then
inspect for hCards. If none are found, it could simply follow all
rel-me links. Since rel-me is published by the author of the page,
[it is a safe asssumption?] that the subsequent requested pages are
also controled by the author. Then hCards could be looked for on those
pages as well. The problem arrises when multiple hCards are
encountered on a page - which is the authorative hCard? This issue is
not a problem with the spider, but with the mechanism to say "THIS
hCard is the one you want" (you suggested an anchor link #vcard), but
using some hueristics, it might be possible to match the URL of the
ORIGINAL hCard that started this spidering, and any hCards found in
the rel-me crawl. If the URLs match, then you could (with some degree
of certainly) collapse the values into a more robust hCard.
For example, if i leave a comment on XYZ blog. It cites me as the
author and uses and hCard.
<p class="vcard">posted by: <a class="fn url"
href="http://suda.co.uk/">Brian Suda</a></p>
So the spider will find my URL in XYZ blog and begin to spider
suda.co.uk for any rel-me links. It finds some onthe homepage to my
contact page and to my publications page. On the publications page it
finds several hCards for various events, organizations, etc. Each of
those is compared to the original from XYZ blog. The FN's don't match,
the URLs don't match - so with a high degree of probablity they are
NOT me. Then the spider visits my contact page. It finds another hCard
(we'll say 2). It compares the first one and the FN's and URLs don't
match. It compares the second one, and the URLs match, the FNs match -
with a high degree of certainly they are the same person and the data
can be merged.
By doing this, we introduce NO new technology or mark-up to find
authoritative data. We are using already existing microformats (XFN),
the data is visible using @rel instead of <link> it allows for the
market to compete and build better spiders.
We also have the lesser used UID to uniquely identify hCards. As we
talked about long ago, UID and URL should be the same thing, if we can
futher develop that idea then comparing and collapsing on URL/UID will
give us an even higher degree of certainty.
> The reason I'm asking is I'm more willing to plug work into this, but
> not if you've already decided that this approach will not work.
--- i think it will work just fine, but i also thing we have all the
tools needed right now.
People 'say' they want this feature, but i don't think they have
explored the possible solutions available currently. If we are going
to try to tell folks to add something like <link rel="id.hcard"..../>
why not just rel-me? that gets us several things at once and solves
this same issue for hCards as hCalendar as hResumes ...
The downside is that i would say for things like X2V or other
hCard->vCard services they should NOT spider links. This would be more
for a social network app that caches the data rather than generating
vCards on the fly.
I think this happily solves the 80/20 percent of all use-cases right
now. I'm also sure smarter people than me can take this to the next
step, implement something like this, and do an even better job of
getting quality data out.
-brian
--
brian suda
http://suda.co.uk
Jeremy Keith
Tantek wrote:
> I'd even advocate looking for
> the first <address> that is or contains an hCard on the page, since
> that's
> following prescribed behavior from HTML4.
On every page of my site (http://adactio.com/), I have an hCard that
uses the address element:
<address class="vcard">
<a href="http://adactio.com/" class="url org">Adactio</a>
is the online home of
<a href="mailto:jer...@adactio.com" class="email fn">Jeremy Keith</a>, a
<span class="title">web developer</span>
living and working in
<span class="adr">
<span class="locality">Brighton</span>,
<span class="country-name">England</span>
</span>.
</address>
I believe this is the correct use of the address element. Whichever
page of the site you find yourself on, the address element contains
the contact details of the site owner: me.
On my contact page, I have a longer hCard:
<div class="vcard">
<h3>Contact Details</h3>
<a class="fn url" href="http://adactio.com/">
<span class="given-name">Jeremy</span>
<span class="family-name">Keith</span>
</a>
<div class="adr">
<span class="street-address">Flat 7, <br />57/58 Brunswick Road</
span><br />
<span class="locality">Hove</span>
<a class="postal-code" href="http://maps.google.co.uk/maps?q=bn3+1dh"
title="map">BN3 1DH</a><br />
<span class="country-name">England</span>
</div>
<p><abbr title="Telephone">Tel</abbr>/<abbr title="Telefax">Fax</
abbr>: <a class="tel" href="callto:+44-1273-771485">+44 1273 771485</
a></p>
<p class="tel"><span class="type">Mobile</span>: <a class="value"
href="callto:+44-7792-069292">+44 7792 069292</a></p>
</div>
Here, I'm not using the address element (though I could) but this
longer hCard should probably be considered the authoritative one (or
it should be merged with any other hCard data collected).
I *could* use rel="me" on the first hCard (the one that appears on
every page) to point to the contact page:
<a class="url" href="http://adactio.com/contact/" rel="me">
But that feels a little uncomfortable: usually, I would point
rel="me" to the front page of my site (and that's exactly what I have
done with hCards in other places like http://bulletproofajax.com/ )
So although I have a single location for an authoritative hCard, none
of my "lesser" hCards are connected to the authoritative version.
David suggested:
> - if there is no fragment in the non-canonical hCard url, a <link>
> is required
To which, Tantek replied:
> <link> should never be required, and should be avoided.
And I tend to agree.
I have a feeling that the answer lies with rel="me".
In my case, if I were to update just the address element that appears
on the home page with a link of rel="me" pointing to my contact page,
then all roads would (eventually) lead to my authoritative hCard:
* Every page of adactio.com has an hCard with a "url" value pointing
to the front page,
* All of my hCards on other sites (e.g. the Bulletproof Ajax site,
blog comments etc.) points to the front page of adactio.com, again
using the "url" value,
* The front page of my site points to my authoritative hCard using
rel="me".
Brian described the behaviour of spidering tools and wrote:
> By doing this, we introduce NO new technology or mark-up to find
> authoritative data. We are using already existing microformats (XFN),
> the data is visible using @rel instead of <link> it allows for the
> market to compete and build better spiders.
I agree. And I think I'll go and update the front page of my site
right now. :-)
But Brian also raised another point:
> The problem arrises when multiple hCards are
> encountered on a page - which is the authorative hCard?
This is the case with http://adactio.com/contact/
As well as the "global" hCard (in the address element), the page also
contains the authoritative one.
So what I may need to do is expand the href I use in a rel="me" link
to point not just to my contact page, but specifically to a page
fragment:
<a class="url" href="http://adactio.com/contact/#vcard" rel="me">
As long as I uniquely identify my authoritative hCard with that
unique identifier (id="vcard") then, at least in theory, a spider
should be able to tell which hCard is authoritative even if more than
one hCard is on the page.
Note that I'm not suggesting a *specific* value like "vcard" for the
fragment identifier, just that the fragment identifier corresponds to
the rel="me" url. So I could just as easily use:
<a class="url" href="http://adactio.com/contact/#foobar" rel="me">
...as long as I then markup my authoritative hCard within id="foobar".
Anyway...
I started this email just to throw a real-world example out there,
but talking through it has helped me clarify what I think I need to do.
Before I finally shut up, I wanted to make sure that this link gets
mentioned at least once in this discussion:
http://gmpg.org/xfn/and/#idconsolidation
Bye,
Jeremy
--
Jeremy Keith
a d a c t i o
David Janes
> On 1/24/07, David Janes <david...@blogmatrix.com> wrote:
> > Do you (Tantek + all) agree with the following "architecture", or it
> > least think it's worth pursuing further:
> >
> > (a) hCards without additional markup; "url" is used to lookup a URL
> > (b) at the URL we can either find:
> > (b.i) the authorative hCard; OR
> > (b.ii) a pointer to authorative URL with the authorative hCard
> > (c) it's easy to find the authorative hCard on the authorative URL
> >
> > I'm sure we have the technology to to (b.ii), I just don't know if
> > anyone has done it. Anyone?
>
> URL. They could then follow that URL to the person's page. Then
> inspect for hCards. If none are found, it could simply follow all
> rel-me links. Since rel-me is published by the author of the page,
> [it is a safe asssumption?] that the subsequent requested pages are
> also controled by the author. Then hCards could be looked for on those
> pages as well. The problem arrises when multiple hCards are
> encountered on a page - which is the authorative hCard? This issue is
> not a problem with the spider, but with the mechanism to say "THIS
> hCard is the one you want" (you suggested an anchor link #vcard), but
> using some hueristics, it might be possible to match the URL of the
> ORIGINAL hCard that started this spidering, and any hCards found in
> the rel-me crawl. If the URLs match, then you could (with some degree
> of certainly) collapse the values into a more robust hCard.
Note that the '#vcard' is from Ryan's website, which I was using as my
working example. I love the rel-me bit, I'm a little less happy with
the "crawl many pages and see if we find something" (if I understand
you correctly) and I wonder if it can be improved
Let me just write out the problem again, based on a real world example
(a) Start Source Page (e.g. http://microformats.org/)
<address class="author vcard">
<a class="url fn" href="http://theryanking.com">Ryan</a>
</address>
(b) URL Page (http://theryanking.com):
... something happens ...
Note that Ryan already has a pointer on this page to his contact page:
<a href="http://theryanking.com/blog/contact/" title="contact">contact</a></li>
(c)
Authorative URL Page (http://theryanking.com/blog/contact/#vcard):
<div class="vcard" id="vcard">
... authorative hCard ...
</div>
So the issue is with the "something happens" bit. Here are a few suggestions
(I) Brian's solution (I think)
- look for "rel-me"
- check each page, matching on FN and/or URL
So we would change Brian's page:
<a href="http://theryanking.com/blog/contact/" title="contact"
rel="me">contact</a></li>
This issue here is FN on the source page may be a shorthand "Ryan" but
on the canonical page it may be
(II) Explicitly mark the authorative link with a unique class
<a href="http://theryanking.com/blog/contact/" rel="me
[hcard-authorative]">contact</a>
[hcard-authorative] is a placeholder, and obviously requires inventing
something new
(III) Modified Brian solution: require explicit ID for hcard
<a href="http://theryanking.com/blog/contact/#vcard" title="contact"
rel="me">contact</a></li>
That is, the spider will only attempt to look at rel-me URIs with a
fragment. The benefit is _explicitness_ and less open-ended work for
the spider. Requiring a fragment may introduce britleness?
Regards, etc...
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
Scott Reynen
> Tantek Ç elik wrote
>> None of those examples given are actually "canonical"
>> sources, they're merely citations and quotations of sources
>> (for which we have existing HTML semantics for: <cite> <q
>> cite> <blockquote cite>. The semantic of canonicality is not
>> necessarily implied, only that the content came from
>> somewhere else, not that that somewhere else is the best /
>> most representative (i.e. canonical) instance of that content.
>
> I think we don't mean "canonical" here, and perhaps fixing that will
> clarify a use case that distinguishes the opportunity.
>
> What I think is much more useful is /authoritative/ hCards. Meaning
> that this is the author's truth for this reference. The authoritative
> reference is the root source of the reference. It is close to
> definitive, but definitive assumes objectivity, whereas authoritative
> retains the subjectivity of the author.
I agree. Only one person knows the canonical source for a given
hCard (and even then it may change, e.g. in hCards used as OpenIDs).
Everyone else can at best point to the best authority they know.
> Working through this leads me to think that an hCard that exists at
> its
> self-referenced URI should be considered "authoritative."
My concern about this is that many publishers (myself included) try
to avoid linking a page to itself due to usability concerns, e.g. "I
just clicked on that link and didn't go anywhere. This site is broken."
Peace,
Scott
Ara Pehlivanian
> to avoid linking a page to itself due to usability concerns, e.g. "I
> just clicked on that link and didn't go anywhere. This site is broken."
Just a shot in the dark here, but couldn't the <a class="url" ...> be
assumed to be pointing to the hCard owner's site where it could be
further assumed that the authoritative hCard would reside? What's
more, if the href in the <a class="url"...> contained an id for the
actual hCard in question then you'd be pointing directly to the
correct hCard (in case the page contains multiple ones, for
work/home/etc...)
An example would be: <a class="url"
href="http://mydomain.com/contact.html#myInfo"...>
In the case of the authoritative hCard itself it could simply point to
it's own id like so: href="#myInfo", though I can see what you mean
about it giving the impression that the link is broken. But it isn't
illegal code. As a matter of fact, the authoritative hCard should
probably contain a full url with id included for accessibility's sake
(otherwise if the hCard is ever exported it won't have a url, just an
id).
Just my 2 cents,
A.
Joe Andrieu
> On Jan 23, 2007, at 8:46 PM, Joe Andrieu wrote:
> > Working through this leads me to think that an hCard that exists at
> > its
> > self-referenced URI should be considered "authoritative."
>
> My concern about this is that many publishers (myself included) try
> to avoid linking a page to itself due to usability concerns, e.g. "I
> just clicked on that link and didn't go anywhere. This site
> is broken."
Scott,
That makes sense. But if I am on the page that is hosting my hCard, how
do I indicate that this URL is the URI for the hCard?
Wouldn't you just use a <span
class="url">http://www.switchbook.com</span> instead of an <a>?
That would still get picked up by the parsers as self-referential,
wouldn't it?
-j
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
_______________________________________________
Scott Reynen
> Wouldn't you just use a <span
> class="url">http://www.switchbook.com</span> instead of an <a>?
>
> That would still get picked up by the parsers as self-referential,
> wouldn't it?
Yes it would. I hadn't considered the possibility of using
class="url" outside <a>. That makes sense to me.
Peace,
Scott
Ara Pehlivanian
> class="url" outside <a>. That makes sense to me.
I think <cite class="url">http://www.site.com</cite> would work
nicely, semantically speaking. No?
A.
Andy Mabbett
<j...@andrieu.net> writes
>A few two major things happen when you do this:
>1. You enable an hCard author to semantically declare this hCard as
>"definitive"
>2. You could provide a link from a refering hCard to the authoritative
>hCard for discovery of additional information that isn't appropriate
>for the design or context of the "refering" hCard.
Of course, it could be argued that the latter constitutes invisible
meta-data...
If example.com/Fred has:
<span class="vcard">
<span class="fn">Fred<\span>
<img class="logo">Fred-avatar.png</img>
</span>
then compare, on another site:
<span class="vcard">
<a class="fn url" href="http://example.com/Fred">Fred<\a>
</span>
with:
<a class="pavatar"
href="http://example.com/Fred-avatar.png">Fred's avatr<\a>
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 21-day week!
Andy Mabbett
Keith <jer...@adactio.com> writes
>I have a feeling that the answer lies with rel="me".
It has a certain elegance, but is rel="me" appropriate for the hCards of
organisations?
It certainly wouldn't help on pages with more than one "short" hCard,
link to a second page with the same people's full hCards, or for third
party details where the author (the "me") isn't the subject.
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 21-day week!
Andy Mabbett
<21e523c20701240350g3d7...@mail.gmail.com>, David
Janes <david...@blogmatrix.com> writes
><address class="author vcard">
><a class="url fn" href="http://theryanking.com">Ryan</a>
></address>
Making that:
<address class="author vcard">
<a class="url" href="http://theryanking.com">
<abbr class="fn" title="Ryan King">Ryan</abbr>
</a>
</address>
not only resolves your 'mismatched-fn' concern, but is also more
semantically meaningful.
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 21-day week!
Andy Mabbett
<21e523c20701240236n134...@mail.gmail.com>, David
Janes <david...@blogmatrix.com> writes
>Let me ask this: is there a _single_ example out there of what we want to do?
There is an hCard (one of several) on:
<http://www.rspb-walsall.org.uk/links.htm>
for the West Midland Bird Club, with just "fn org url". The target of
the url property:
<http://www.westmidlandbirdclub.com/>
has a more complete ("canonical", if you will) hCard for the Club, with
postal contact details.
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 21-day week!
Chris Casciano
On Jan 23, 2007, at 1:22 PM, David Janes wrote:
> Continuing the tradition of riffing off other threads to talk about
> what's on my mind...
>
> On 1/23/07, Ryan King <ry...@technorati.com> wrote:
>>
>> It's not a full CSS selector based search engine, but http://
>> kitchen.technorati.com/contacts/search/tantek.
>>
>
> Wouldn't it be great if there was a well defined way of getting from
> _an_ instance of a hCard to the _best_ (or canonical) hCard for that
> person.
>
> Just saying; I know that some work has been done on this.
>
> Regards, etc...
Not to double back on a few days worth of replies, but while I
understand the desire to eliminate noise from search results [or
elevate more complete results] I'm not sure how I feel about two things:
(a) that this isn't an issue simply to be solved by consuming
applications. E.g. "search for detailed contact data" "return only
results with email address" "match on Name 'Chris' and url contains
'placenamehere.com', or some non-hcard solutions be them XFN,
claimID, other avenues for tying these bits together.
(b) I think with any solution we need to be careful on the definition
and reliance on these flags, and more generally the notion that
there /is/ a best out there for any given individual. Just one case
would be a person who might have their contact info on a business
context, a context related to their position in a different
organization, and then yet another in a more personal context [blog,
resume on monster.com, etc]. While all are probably more informative
then a simple fn-only card from a reply on a random blog post on the
net, what is 'best' is based on context and the data will most likely
not be consolidated into one place.
P.S. the technorati search is currently giving me no results for any
contact searches I try, I'll follow up with the proper parties offlist.
--
[ Chris Casciano ]
[ ch...@placenamehere.com ] [ http://placenamehere.com ]
Andy Mabbett
Chris Casciano <ch...@placenamehere.com> writes
>(b) I think with any solution we need to be careful on the definition
>and reliance on these flags, and more generally the notion that there
>/is/ a best out there for any given individual.
Perhaps what ought to be marked up is the "parent" hCard of known
"child" hCards?
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 21-day week!
John Allsopp
from another
> I have a feeling that the answer lies with rel="me".
Might I suggest, reusing how permalinks work in hAtom and hReview
(particularly hReview)?
rel=bookmark is defined in the HTML 4 spec as
"Refers to a bookmark. A bookmark is a link to a key entry point
within an extended document" [1]
Nothing there suggests that the bookmark is in any way authoritative,
but an authoritative hCard would fall under "a key entry point within
an extended document". So, we are half way there.
Then, if we look at, hReview we find there is already a similar
solution. An hReview may point to its "permalink" (surely the
authoritative version? Ryan your thoughts on the analogy?) using
rel="bookmark self". The self part is required along with bookmark to
"indicate that the hyperlink is a permalink for the review itself" [2]
So, suggestion is use
rel="bookmark self" to denote that the resource pointed to by the
link (<a href) is the authoriatative version of the hCard (and indeed
this might be a generalizable pattern? - the authoritative version of
a microformat may be indicated by the use of a link to that
microformat, with a rel value which includes "self" and "bookmark")
Thoughts?
Thanks
john
1.http://www.w3.org/TR/html4/types.html#type-links
2.http://microformats.org/wiki/hreview#Field_details
John Allsopp
--
style master :: css editor :: http://westciv.com/style_master
about me :: http://johnfallsopp.com
Web Directions North, Vancouver Feb 6-10 :: http://
north.webdirections.org
Ben Ward
> Just a shot in the dark here, but couldn't the <a class="url" ...> be
> assumed to be pointing to the hCard owner's site where it could be
> further assumed that the authoritative hCard would reside? What's
> more, if the href in the <a class="url"...> contained an id for the
> actual hCard in question then you'd be pointing directly to the
> correct hCard (in case the page contains multiple ones, for
> work/home/etc...)
>
> An example would be: <a class="url"
> href="http://mydomain.com/contact.html#myInfo"...>
Whilst the use of fragment URLs is definitely correct as regards
focusing on specific hCards on a page, you cannot imply authority
based just on class=url — it's valid and legal that an hCard can have
multiple URLs, so which would be authoritative?. On my own site, I
link to my /about page, my Flickr account, Delicious bookmarks and so
on, all with class="url" and rel="me".
For my money, John Allsopp's idea to reuse rel="bookmark self" [1]
makes most sense. As well as being gorgeously consistent with other
existing microformats, it's also a completely graceful addition to
existing hCards.
The only concern I can see to check is if this would conflict with
and break the parsing of hAtom/hReview that already use those rel
values in combination?
It would take the guesswork out of parsing, whilst publishing useful
information. Additionally, what do people think to situations where
an hCard contains a A/@REL="bookmark self" but not @class=url? The
use case being when I don't regard my /about page as being a relevant
URL for inclusion in my hCard parsing, but do wish to have it
followed and parsed as the authoritative version.
Ben
[1]: http://microformats.org/discuss/mail/microformats-discuss/2007-
January/008309.html
John Allsopp
> For my money, John Allsopp's idea to reuse rel="bookmark self" [1]
> makes most sense. As well as being gorgeously consistent with other
> existing microformats, it's also a completely graceful addition to
> existing hCards.
thanks ;-)
There's a lot of goodness to reuse from other ufs, for sure.
> The only concern I can see to check is if this would conflict with
> and break the parsing of hAtom/hReview that already use those rel
> values in combination?
When rel-license is inside an hReview, it is taken to be associated
with the review, rather than the larger fragment it would otherwise
be associated with (e.g. post or page)
I wonder whether that makes sense more generally - things apply at
the finest level of granularity at which it mkes sense - so
rel="bookmark self" applies to the microformatted content it is most
directly descended from.
Are there reasons people think this is a bad idea?
An analogy again is categories in hAtom
You can have either feed categories or entry categories. Both are
encoded using rel-tag. The difference is that entry categories are
inside the hentry element, while feed categories are in the hFeed
element (but not in the hEntry element). The point is that hEntry
elements descend from hFeed elements, so all entry categories are
inside an hFeed element.
Indeed, Brian Suda, Michael Kaply, or someone else who does a bit of
parsing might weigh in on whether or not this is an implicit
assumption they make more generally with their parsers, or whether it
might become an explicit convention - to try and formulate it (badly)
"where a feature of microformats may apply to more than one element
in a descendent tree, it is associated with the element which most
directly contains it ."
> It would take the guesswork out of parsing, whilst publishing
> useful information. Additionally, what do people think to
> situations where an hCard contains a A/@REL="bookmark self" but not
> @class=url? The use case being when I don't regard my /about page
> as being a relevant URL for inclusion in my hCard parsing, but do
> wish to have it followed and parsed as the authoritative version.
Not sure whether this is straying into the 20% part of the problem
space? Just my initial response, with little real thought ;-)
john
Derrick Lyndon Pallas
>
> I wonder whether that makes sense more generally - things apply at the
> finest level of granularity at which it mkes sense - so rel="bookmark
> self" applies to the microformatted content it is most directly
> descended from.
> Are there reasons people think this is a bad idea?
>
> a descendent tree, it is associated with the element which most
> directly contains it ."
Personally, I think this is a bad idea; I was actually talking with Ben
West at work today about this very issue. For the sake of argument, say
hFoo --- which I decide to implement --- can contain rel-tag without
marking it in any other way. Now a new format, hBar, comes along and it
may contain rel-tag without marking it in any way; maybe I don't know
about hBar, don't care about hBar, or don't want to implement hBar. What
if my hFoo contains an hBar? In that case,
<div class="hFoo">
<span class="hBar">
<a href="http://examples.com/tag/myTag" rel="tag">Text</a>
</span>
</div>
causes a problem (given the suggestion above) because the rel-tag should
only apply to hBar but without the hFoo parser knowing about hBar (which
may be unreasonable) it will grab the rel-tag as well. A better solution
is what hCard does; from what I understand, using rel-tag with category
still requires you to say @class="category". This, incidentally, can
cause a name-space problem: it means that to keep hBar and hFoo
unambiguous, one needs to define slightly different rel-tag properties
for each.
There are two simple solutions: make features only apply to the element
in which they exist (which makes them non-features) or let features
apply to any format that can grok the feature, ignoring containers.
There are three complex solutions: use name-spaces for disambiguation,
use other naming triks to figure out which feature apply to which
container (this could get messy quickly), or require parsers for one
format to know about all other top level containers (which seems bad for
compatibility).
~D
Chris Messina
I actually started a post on this topic over a week ago -- and
absentmindedly hadn't checked on this list first before posting and
therefore published without the benefit of this discussion (I can hear
Tantek chiding me) but nonetheless, as the first half of a two-part
piece of transcending social networks (I have to write up the second
half still) I wrote this:
Scoping XFN and identifying authoritative hcards
<http://factoryjoe.com/blog/2007/01/29/scoping-xfn-and-identifying-definitive-hcards/>
I pretty much came up with a very similar proposal for handling this
issue, though from the standpoint of XFN-links, and I think that
John's suggestion is very good, though instead of using "bookmark
self" might suggest "me self" for identifying the One True Hcard:
<div class="vcard" id="vcard">
<address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
url" rel="me self">Chris Messina</a></address>
<div class="org">Citizen Agency</a>
...
</div>
That way, any hcard that links to me at
http://factoryjoe.com/blog/hcard/#hcard will find a self-referencing
hcard which serves as the proverbial "end of the road". I prefer "self
me" because of the potential conflict of embedding this kind of hcard
in other formats, as has been suggested could be an issue...
The use of the <address> tag is also important, as it signifies with
additional certainty that the author of the page own the hcards --
making it doubly authoritative.
Thus if you can find an object at "address a[rel~=self].url", there's
good chance you've got something pretty solid.
Thoughts? (I've also updated my post to reflect John's suggestion)
Chris
--
Chris Messina
Citizen Provocateur &
Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is: [ ] bloggable [X] ask first [ ] private
John Allsopp
(all the following simply thoughts in the spirit of brainstorming,
rather than any particular argument in favour of my original suggestion)
> I pretty much came up with a very similar proposal for handling this
> issue, though from the standpoint of XFN-links, and I think that
> John's suggestion is very good, though instead of using "bookmark
> self" might suggest "me self" for identifying the One True Hcard:
>
> <div class="vcard" id="vcard">
> <address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
> url" rel="me self">Chris Messina</a></address>
> <div class="org">Citizen Agency</a>
> ...
> </div>
I wonder whether hAtom had predated XFN, self instead of me would
have been chosen for the identity value?
The "definition" of the self attribute value in Atom is "self: the
feed itself". The term "the" seems to indicate "definitiveness". So,
I was initially going to argue that "self me" was tautological, but
in fact, in this sense it is not, and indeed, the addition of
bookmark is probably tautological.
So, I'd probably +1 this suggestion, and perhaps also suggest that
for hReview simply a rel value of "self" be required for the
permalink, for consistency.
> The use of the <address> tag is also important, as it signifies with
> additional certainty that the author of the page own the hcards --
> making it doubly authoritative.
Thats true. But just to note (as I am sure you know) that as address
is an inline element, this enforces certain contraints on its
descendents - they al have to be inline elements.
> Thus if you can find an object at "address a[rel~=self].url", there's
> good chance you've got something pretty solid.
>
> Thoughts? (I've also updated my post to reflect John's suggestion)
I suggest the correct use of self is definitive, so address, while
perhaps advisable, doesn't need to be required.
j
Ben Ward
>> <div class="vcard" id="vcard">
>> <address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
>> url" rel="me self">Chris Messina</a></address>
>> <div class="org">Citizen Agency</a>
>> ...
>> </div>
>>
John Allsopp:
> The "definition" of the self attribute value in Atom is "self: the
> feed itself". The term "the" seems to indicate "definitiveness".
> So, I was initially going to argue that "self me" was tautological,
> but in fact, in this sense it is not, and indeed, the addition of
> bookmark is probably tautological.
>
> So, I'd probably +1 this suggestion, […]
+1 from me as well.
Can we gauge wider support for this addition? Any problems from anyone?
Ben
Steve Ivy
Joe Andrieu
authoritative hCard {was:Re: [uf-discuss] Authoritative
hCards [was RE: Canonical hCards(was: Search on CSS element)]}
> > Chris Messina:
> >> <div class="vcard" id="vcard">
> >> <address><a
> href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
> >> url" rel="me self">Chris Messina</a></address> <div
> >> class="org">Citizen Agency</a> ...
> >> </div>
>
>
> Can we gauge wider support for this addition? Any problems
> from anyone?
+1 from me. It addresses the issues I brought up quite nicely.
-j
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
_______________________________________________
Tara Hunt
--
Sincerely,
Tara
-----------------------
tara 'miss rogue' hunt
agent provocateur
Citizen Agency (www.citizenagency.com)
blog: www.horsepigcow.com
phone: 415-694-1951
fax: 415-727-5335
Frances Berriman
> > Chris Messina:
> >> <div class="vcard" id="vcard">
> >> <address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
> >> url" rel="me self">Chris Messina</a></address>
> >> <div class="org">Citizen Agency</a>
> >> ...
> >> </div>
> >>
>
> John Allsopp:
> > The "definition" of the self attribute value in Atom is "self: the
> > feed itself". The term "the" seems to indicate "definitiveness".
> > So, I was initially going to argue that "self me" was tautological,
> > but in fact, in this sense it is not, and indeed, the addition of
> > bookmark is probably tautological.
> >
> > So, I'd probably +1 this suggestion, […]
>
> +1 from me as well.
>
> Can we gauge wider support for this addition? Any problems from anyone?
+1
--
Frances Berriman
http://fberriman.com
Colin Barrett
> On 31/01/07, Ben Ward <li...@ben-ward.co.uk> wrote:
>> > Chris Messina:
>> >> <div class="vcard" id="vcard">
>> >> <address><a href="http://factoryjoe.com/blog/hcard/#hcard"
>> class="fn
>> >> url" rel="me self">Chris Messina</a></address>
>> >> <div class="org">Citizen Agency</a>
>> >> ...
>> >> </div>
>> >>
>>
>> John Allsopp:
>> > The "definition" of the self attribute value in Atom is "self: the
>> > feed itself". The term "the" seems to indicate "definitiveness".
>> > So, I was initially going to argue that "self me" was tautological,
>> > but in fact, in this sense it is not, and indeed, the addition of
>> > bookmark is probably tautological.
>> >
>> > So, I'd probably +1 this suggestion, […]
>>
>> +1 from me as well.
>>
>> Can we gauge wider support for this addition? Any problems from
>> anyone?
>
> +1
Can I get a clearer idea of what exactly is people are +1-ing? I +1
@rel="self me", but am not willing to give my vote yet on using
<address>, as it's not entirely clear if we're talking about mandating
it, recommending it, etc. FWIW I'm not entirely convinced it's
necessary to have it.
-Colin
Ben Ward
> Can I get a clearer idea of what exactly is people are +1-ing? I +1
> @rel="self me", but am not willing to give my vote yet on using
> <address>, as it's not entirely clear if we're talking about
> mandating it, recommending it, etc. FWIW I'm not entirely convinced
> it's necessary to have it.
Apologies, I perhaps should have created a fresh example rather than
re-use Chris' original effort.
We are voting only on the use of @rel="me self" to reference an
authoritative hCard that parsers should follow.
e.g.
<div class="vcard">
<a class="fn url" href="http://ben-ward.co.uk/about" rel="me
self">Ben Ward</a>
</div>
Colin Barrett
> On 31 Jan 2007, at 12:08, Colin Barrett wrote:
>> Can I get a clearer idea of what exactly is people are +1-ing? I +1
>> @rel="self me", but am not willing to give my vote yet on using
>> <address>, as it's not entirely clear if we're talking about
>> mandating it, recommending it, etc. FWIW I'm not entirely convinced
>> it's necessary to have it.
>
> Apologies, I perhaps should have created a fresh example rather than
> re-use Chris' original effort.
>
> We are voting only on the use of @rel="me self" to reference an
> authoritative hCard that parsers should follow.
>
> e.g.
>
> <div class="vcard">
> <a class="fn url" href="http://ben-ward.co.uk/about" rel="me
> self">Ben Ward</a>
> </div>
Then +1 from me.
-Colin
Ara Pehlivanian
David Janes
> We are voting only on the use of @rel="me self" to reference an
> authoritative hCard that parsers should follow.
>
> e.g.
>
> <div class="vcard">
> <a class="fn url" href="http://ben-ward.co.uk/about" rel="me
> self">Ben Ward</a>
> </div>
Just to be 100% pedantically clear:
(Part I)
If Ben puts this on his home page, parsers look at
"http://ben-ward.co.uk/" will know to look for an authoritative hCard
because of these two things:
1. there's a vcard
2. it has a "url" link with rel="me self"
(Part II -- implication)
If Ben places a vcard on a random page with
url="http://ben-ward.co.uk/", a consumer can optionally look there to
find an authoritative hCard.
The 80-20 rule covers the case where we would want to have more than
one authoritative hCard per page (i.e. it's not that common)
(Part III - rel-self)
We're getting the definition of rel-self from here [1]: "self: the
feed itself". It's a small stretch, but I just did some searching for
counter-examples (i.e. where rel-self doesn't point to the best URI
for a feed) and came up empty.
(Part IV -- the word authoritative)
I can't think of a better word. See definition 2 here [2]
So +1
Regards, etc...
[1] http://atomenabled.org/developers/syndication/#link
[2] http://www.answers.com/authoritative&r=67
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
Ara Pehlivanian
> url="http://ben-ward.co.uk/", a consumer can optionally look there to
> find an authoritative hCard.
Just to stir the pot a little, and maybe it's a good idea to consider
authenticity in the whole discussion of authoritative cards. What
guarantees that when someone creates an hCard and puts rel="me self"
that they are giving the correct URL and that it isn't someone
impersonating you?
Would this be the place for a correlating hash to be included in the
hCard that the authoritative one has (which only the owner can
modify)?
Just a thought.
A.
Ben Ward
> Just to stir the pot a little, and maybe it's a good idea to consider
> authenticity in the whole discussion of authoritative cards. What
> guarantees that when someone creates an hCard and puts rel="me self"
> that they are giving the correct URL and that it isn't someone
> impersonating you?
The authoritative version of the hCard is only going to be relative
to the published hCard itself. The situation doesn't change. Someone
could already write an inaccurate hCard for me on their website. They
could write a more thorough version and link from one to the other
with rel="me self". This addition doesn't affect the authenticity.
Authenticity falls out of scope of hCard alone. Layer in some OpenID
and you can have start to imply some authenticity. (e.g. Parse an
hCard at the OpenID url and follow rel="me self" to another domain.)
If you mean, someone at ‘BenWardSmellsAwful.com’ (don't register
that, please) writing an hCard and linking to ben-ward.co.uk/about
with rel="self me", the relationship is such that the Fake Ben's
hcard is discarded in favour of my real one. This does not allow
someone to describe ‘this hCard here is the authoritative version of
that one over there’. The direction of parsing disallows fakes.
Ben
David Janes
> The authoritative version of the hCard is only going to be relative
> to the published hCard itself. The situation doesn't change. Someone
> could already write an inaccurate hCard for me on their website. They
> could write a more thorough version and link from one to the other
> with rel="me self". This addition doesn't affect the authenticity.
>
> Authenticity falls out of scope of hCard alone. Layer in some OpenID
> and you can have start to imply some authenticity. (e.g. Parse an
> hCard at the OpenID url and follow rel="me self" to another domain.)
>
> If you mean, someone at 'BenWardSmellsAwful.com' (don't register
> that, please) writing an hCard and linking to ben-ward.co.uk/about
> with rel="self me", the relationship is such that the Fake Ben's
> hcard is discarded in favour of my real one. This does not allow
> someone to describe 'this hCard here is the authoritative version of
> that one over there'. The direction of parsing disallows fakes.
Open ID spells this out up front: authentication is not trust [1].
It's similar for us; you/your consumer has to decide whether it trusts
a URI (BenWardSmellsAwful.com) making a authorative-hcard claim about
a hCard (ben-ward.co.uk/about), which you'll also have to make your
own decision about!
The nice thing is all the information is there for you to examine in
the open. Beyond that, the trust issue is difficult, to say the least,
and probably not solvable by microformats ... or big companies, or big
government :-)
Regards, etc...
[1] http://openid.net/about.bml
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
Ara Pehlivanian
> that, please) writing an hCard and linking to ben-ward.co.uk/about
> with rel="self me", the relationship is such that the Fake Ben's
> hcard is discarded in favour of my real one. This does not allow
> someone to describe 'this hCard here is the authoritative version of
> that one over there'. The direction of parsing disallows fakes.
Yes, but what if someone registers ben-ward.net and puts up a fake
card on that site. Then he goes and publishes a partial hCard on
myspace and points to ben-ward.net/about with rel="self me". He's
effectively hijacked your identity and/or caused confusion and there's
no real way to verify who's who or who's telling the truth. It may not
be such a big deal now, but if microformats are to grow and begin to
be integrated into who knows what apps in the future, there may be a
need to authenticate the validity of the authoritative hCard.
Now I understand that it's not up to the microformat to actually do
any authentication. But I think it makes a lot of sense to build a
mechanism into it that allows you to include a piece of verifiable
data (such as a hash or some other token) that could then be checked
against an authentication service or a file in the root of your own
domain (à-la Google Analytics).
I don't have any immediate ideas on how best to semantically do this,
but the concern popped into my head rather early on and I felt that
maybe now would be the time to bring it up.
Cheers,
A.
Joe Andrieu
> Just to stir the pot a little, and maybe it's a good idea to
> consider authenticity in the whole discussion of
> authoritative cards. What guarantees that when someone
> creates an hCard and puts rel="me self" that they are giving
> the correct URL and that it isn't someone impersonating you?
>
> Would this be the place for a correlating hash to be included
> in the hCard that the authoritative one has (which only the
> owner can modify)?
Ara,
The concept behind an "authoritative" hCard rather than "definitive" or
"canonical" one was that "authoritative" would explicitly be a /claim/
by the author of the hCard regarding its authority in describing the
subject of the hCard, i.e., use /this/ hCard as the one true source of
this individual's contact information.
The possibility for someone to impersonate another is a problem much
greater than the semantic html we use. Authentication and validation of
assertions ends up outside the scope of microformats, IMO. The
infrastructure simply isn't in place to guarantee /any/ semantic
information found online.
Note also, the possibility for "authoritative" hCards to simply fall out
of date is a huge problem. I for one, no longer have access to my
college account, but for years an old home page of mine would show up at
Google with suitably humorous results when colleagues and clients
discovered it. It is easy to see how any hCard that I would have marked
as "authoritative" on that page could still be out in the wild, despite
it no longer being accurate and independent of my inability to correct
it.
So, the inaccuracy of an hCard is its own challenge, whether from
impersonation, poor maintenance, or simply typos. But I think we can
create value by agreeing on a mechanism for expressing the concept of an
authoritative hCard. Services will simply have to accept that
"authoritative" is a claim and could be invalid for any number of
reasons.
-j
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
David Janes
> Yes, but what if someone registers ben-ward.net and puts up a fake
> card on that site. Then he goes and publishes a partial hCard on
> myspace and points to ben-ward.net/about with rel="self me". He's
> effectively hijacked your identity and/or caused confusion and there's
> no real way to verify who's who or who's telling the truth. It may not
> be such a big deal now, but if microformats are to grow and begin to
> be integrated into who knows what apps in the future, there may be a
> need to authenticate the validity of the authoritative hCard.
>
> Now I understand that it's not up to the microformat to actually do
> any authentication. But I think it makes a lot of sense to build a
> mechanism into it that allows you to include a piece of verifiable
> data (such as a hash or some other token) that could then be checked
> against an authentication service or a file in the root of your own
> domain (à-la Google Analytics).
How if there's another Ben Ward? Sorry, lot's of people have thought
about this problem in lots of different realms (as I mentioned,
OpenID) and it's intractable.
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
_______________________________________________
Scott Reynen
> Open ID spells this out up front: authentication is not trust [1].
Nonetheless, people are trying to build trust systems on top of Open ID:
http://simonwillison.net/2007/Jan/22/whitelisting/
This is another topic entirely, but it occurs to me that adding
something like rel="trust" to the linked names in moderated comments
would remove the need for a separate whitelist.
Peace,
Scott
Ara Pehlivanian
> How if there's another Ben Ward? Sorry, lot's of people have thought
> about this problem in lots of different realms (as I mentioned,
> OpenID) and it's intractable.
I guess there's no way to manage the partial hCards as they could
point anywhere and someone with the same name could easily be confused
with a potential identity hijacker. So yeah, that doesn't work.
As for authentication, I'm not sure it even matters come to think of
it. If anything, the site/page on which the authoritative hCard is
found is what needs to be authenticated rather than the piece of
markup itself.
In the end I think that the context is what lends credence to the
authenticity of the authoritative hCard and not the hCard itself.
A.
David Janes
> On Jan 31, 2007, at 9:18 AM, David Janes wrote:
>
> > Open ID spells this out up front: authentication is not trust [1].
>
> Nonetheless, people are trying to build trust systems on top of Open ID:
>
> http://simonwillison.net/2007/Jan/22/whitelisting/
>
> This is another topic entirely, but it occurs to me that adding
> something like rel="trust" to the linked names in moderated comments
> would remove the need for a separate whitelist.
>
> Peace,
> Scott
(1)
Note that this just backs up the problem one step. I.e. we had
URI-A claims (via "rel me self") that URI-B is it's authoriative hCard
now we have (via a whitelist) additionally:
URI-C claims URI-A is who he says he is.
Whitelist additions to XFN may be an interested topic to explore!
(2)
It occurs to me that one form of hijacking can be prevented
URI-A: "ben-ward.co.uk": links to "ben-ward.co.uk/about"
URI-B: "ben-ward.co.uk/about". Ben's authorative hCard
URI-X: "BenWardSucks.com": links to "ben-ward.co.uk/about"
Now, if URI-B uses "url" to point back to URI-A, i.e. Ben's home page,
then we have validatation that URI-A is making a claim that URI-B is
agreeing with. On the other hand, URI-X is making an unsubstantiated
claim.
War,
David
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
Ben Ward
> Yes, but what if someone registers ben-ward.net and puts up a fake
> card on that site. Then he goes and publishes a partial hCard on
> myspace and points to ben-ward.net/about with rel="self me". He's
> effectively hijacked your identity and/or caused confusion and there's
> no real way to verify who's who or who's telling the truth.
That's still no different to life without rel="me self".
I happen to own the domains <ben-ward.co.uk> and <ben-ward.com>. Note
hyphens. I do not own <benward.com> , <benward.co.uk> nor any other
variant.
Domains do not prove identity. What I can do is make my entire
‘online identy’ parsable by linking between my domains and my social
network profiles using rel="me". That doesn't tell you anything more
about me as a person than the fact that <flickr/photos/benward>, <ben-
ward.co.uk> and <myspace.com/benwardcouk> are part of the same
personal network of sites.
The owner of Ben-Ward.net could have his own personal network of
sites too, but they would not be linked to from my own authoritative
hCard at ben-ward.co.uk/about. Nothing stops him add rel="me" to his
hcard pointing to my site, but that takes us well out of scope of
hcard, and is still a different issue — not something introduced by
@rel="me self"
Ben
Ben Ward
On 31 Jan 2007, at 17:03, Ben Ward wrote:
> The owner of Ben-Ward.net could have his own personal network of
> sites too, but they would not be linked to from my own
> authoritative hCard at ben-ward.co.uk/about. Nothing stops him add
> rel="me" to his hcard pointing to my site, but that takes us well
> out of scope of hcard, and is still a different issue — not
> something introduced by @rel="me self"
Actually I'm wrong here. The XFN spec points out that @rel=me must be
symmetric, so the owner of ben-ward.net could *not* validly link to
ben-ward.co.uk with @rel=me unless I linked back likewise.
“me: A link to yourself at a different URL. Exclusive of all other
XFN values. *Required symmetric*.”
Benjamin West
problem with rel="me" is that it's merely an alternative version, and
not authoritative or canonical, right? Why is rel="me self" desirable
though? Were there any other alternatives considered?
Thanks,
Ben West
On 1/31/07, David Janes <david...@blogmatrix.com> wrote:
Andy Mabbett
Ward <li...@ben-ward.co.uk> writes
>>I was initially going to argue that "self me" was tautological, but
>>in fact, in this sense it is not, and indeed, the addition of
>>bookmark is probably tautological.
>>
>> So, I'd probably +1 this suggestion, […]
>
>+1 from me as well.
>
>Can we gauge wider support for this addition? Any problems from anyone?
"me self" can't be anything but tautological; nor is it appropriate when
referring to third parties. so:
-1
but isn't this sort of voting better done on the wiki than in a mailing
list?
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 28-day week!
Andy Mabbett
Allsopp <jo...@westciv.com> writes
>When rel-license is inside an hReview, it is taken to be associated
>with the review, rather than the larger fragment it would otherwise
>be associated with (e.g. post or page)
>
>I wonder whether that makes sense more generally - things apply at the
>finest level of granularity at which it mkes sense - so rel="bookmark
>self" applies to the microformatted content it is most directly
>descended from.
>Are there reasons people think this is a bad idea?
Yes - a parser at that level of granularity will understand that, but
not something paring the whole page for licenses, which may have been
written before the more granular uF was created.
I've raised this issue previously, when the example was a page about an
individual, with their genealogy, and an hCard for their dead parent.
Tagging that hCard "deceased", as is currently suggested, would be
interpreted (or at least implied) by some parsers as tagging the subject
of the page as deceased.
--
Andy Mabbett
* Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>
* Free Our Data: <http://www.freeourdata.org.uk>
* Are you using Microformats, yet: <http://microformats.org/> ?
Andy Mabbett
<923a87360701310750p380...@mail.gmail.com>, Ara
Pehlivanian <ara.peh...@gmail.com> writes
>what if someone registers ben-ward.net and puts up a fake
>card on that site.
Perhaps we need a "class="pgp-public-key" property for hCard?
;-)
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 28-day week!
Ara Pehlivanian
> Perhaps we need a "class="pgp-public-key" property for hCard?
Intriguing...
A.
Brian Suda
> <923a87360701310750p380...@mail.gmail.com>, Ara
> Pehlivanian <ara.peh...@gmail.com> writes
>
> >what if someone registers ben-ward.net and puts up a fake
> >card on that site.
>
> Perhaps we need a "class="pgp-public-key" property for hCard?
>
> ;-)
--- i'm not sure if that wink was ment for 'pgp-public-key' to be a
joke, but hCard and vCard do have a 'key' property.
This is an example in the wild.
http://www.informatik.uni-hamburg.de/SVS/personnel/henrich/index.php
Much like the DATA URI it is possible to embed a BASE64 key into HTML.
-brian
--
brian suda
http://suda.co.uk
Andy Mabbett
<21e770780702011030k542...@mail.gmail.com>, Brian
Suda <brian...@gmail.com> writes
>This is an example in the wild.
>http://www.informatik.uni-hamburg.de/SVS/personnel/henrich/index.php
I wonder what an aural browser/ screen reader would make of that...
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 29-day week!
John Allsopp
(apologies for the tardiness, I'm in one of those old fashioned,
unconnected airomoplanes)
> "me self" can't be anything but tautological; nor is it appropriate
> when
> referring to third parties. so:
in English, it is tautological. But restricting the words to their
roles in XFN and Atom, they mean quite different things - so I'd
respectfully argue that the construction isn't in this context
tautological.
The third party issue (I take it to mean that you can't refer to an
authoritative third party hCard for someone else using m, which is
quite correct).
I think that's a separate and more complex issue - how, if at all,
can you link to an authoritative hCard for someone else. Is there a
use case - sure - for example, at our conference sites, we markup
speakers with hCard, and this often includes a link to their blog
etc. In this case, a link to an authoritative (or perhaps, to be even
less strict "detailed") hCard may be somethign that is very useful.
> -1
>
> but isn't this sort of voting better done on the wiki than in a
> mailing
> list?
"rough consensus" - many more people see this mailing list regularly
than visit the wiki frequently (I'd suggest) so for gaining a sense
of rough consensus in a shortish timeframe (my original +1 was
informal) the mailing list does seem to me to be an appropriate
location for such straw polls.
j
John Allsopp
vCard has the property key - and so too does therefore hCard. vCard
defines key (more or less, no cnnection this moment to quote directly)
Specifies the public key or authentication certificate associated
with the entity the vcard represents
thanks
j
Ara Pehlivanian
> use case - sure - for example, at our conference sites, we markup
> speakers with hCard, and this often includes a link to their blog
> etc. In this case, a link to an authoritative (or perhaps, to be even
> less strict "detailed") hCard may be somethign that is very useful.
If I understand the spec correctly, since a rel="me" is symmetric,
shouldn't the hCard you're pointing to also be pointing back? If
that's true, then the authoritative hCard will quickly get
unmanageable since it will contain tens if not hundreds of reciprocal
links to partial hCards (imagine if you're listed in several different
locale directories marked up with hCard).
A.
Ara Pehlivanian
> defines key (more or less, no cnnection this moment to quote directly)
>
> Specifies the public key or authentication certificate associated
> with the entity the vcard represents
So then that settles the issue of authentication. If a third party
consumer that reads the hCard wants to validate its authenticity, it
can simply use the key (if present). It could further match all linked
hCard keys to validate the chain's integrity. N'est pas?
A.
Andy Mabbett
Allsopp <jo...@westciv.com> writes
>> "me self" can't be anything but tautological; nor is it appropriate
>>when
>> referring to third parties. so:
>
>in English, it is tautological. But restricting the words to their
>roles in XFN and Atom, they mean quite different things - so I'd
>respectfully argue that the construction isn't in this context
>tautological.
"for people first" ?
>The third party issue (I take it to mean that you can't refer to an
>authoritative third party hCard for someone else using m, which is
>quite correct).
>I think that's a separate and more complex issue - how, if at all, can
>you link to an authoritative hCard for someone else. Is there a use
>case - sure - for example, at our conference sites, we markup speakers
>with hCard, and this often includes a link to their blog etc. In this
>case, a link to an authoritative (or perhaps, to be even less strict
>"detailed") hCard may be somethign that is very useful.
I think you just answered your own question.
--
Andy Mabbett
<http://www.pigsonthewing.org.uk/uFsig/>
Welcome to the 30-day week!
Colin Barrett
> On 2/1/07, John Allsopp <jo...@westciv.com> wrote:
>> use case - sure - for example, at our conference sites, we markup
>> speakers with hCard, and this often includes a link to their blog
>> etc. In this case, a link to an authoritative (or perhaps, to be even
>> less strict "detailed") hCard may be somethign that is very useful.
>
> If I understand the spec correctly, since a rel="me" is symmetric,
> shouldn't the hCard you're pointing to also be pointing back? If
> that's true, then the authoritative hCard will quickly get
> unmanageable since it will contain tens if not hundreds of reciprocal
> links to partial hCards (imagine if you're listed in several different
> locale directories marked up with hCard).
Indeed, it seems the "me" attribute from xfn may not be entirely
desirable.
Is it even needed for a "master"/authoritative hCards to recognize
their children?
-Colin
David Janes
> Indeed, it seems the "me" attribute from xfn may not be entirely
> desirable.
>
> Is it even needed for a "master"/authoritative hCards to recognize
> their children?
>
> -Colin
I can see a use for it. For example, I'd like to primarily identify
myself with a single URI [1]. From that starting point, I could (for
example) point to my own hand constructed hCard elsewhere or I could
use a professional service, such as LinkedIn.
On the authorative hCard, I could then backlink to [1] and this would
provide protection against one form (and I know there's many others)
of identity hijacking.
Regards, etc...
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
Colin Barrett
> On 2/4/07, Colin Barrett <tim...@lava.net> wrote:
>> Indeed, it seems the "me" attribute from xfn may not be entirely
>> desirable.
>>
>> Is it even needed for a "master"/authoritative hCards to recognize
>> their children?
>>
>> -Colin
>
> I can see a use for it. For example, I'd like to primarily identify
> myself with a single URI [1]. From that starting point, I could (for
> example) point to my own hand constructed hCard elsewhere or I could
> use a professional service, such as LinkedIn.
>
> On the authorative hCard, I could then backlink to [1] and this would
> provide protection against one form (and I know there's many others)
> of identity hijacking.
>
> Regards, etc...
I should have reworded:
Is it necessary for authoritative hCards to recognize ALL their
children?
It might also be semantically wrong to put rel="me" on a link to an
hCard that isn't on a site that's your own, anyway.
-Colin
Ryan King
> In message
> <923a87360701310750p380...@mail.gmail.com>, Ara
> Pehlivanian <ara.peh...@gmail.com> writes
>
>> what if someone registers ben-ward.net and puts up a fake
>> card on that site.
>
> Perhaps we need a "class="pgp-public-key" property for hCard?
There's already a KEY field in vCard. From RFC2624:
> Type purpose: To specify a public key or authentication certificate
> associated with the object that the vCard represents.
I'm sure we could make this work. :D
-ryan
--
Ryan King
ry...@technorati.com
Ryan King
nothing I can do about that now...
On Jan 29, 2007, at 5:50 PM, John Allsopp wrote:
> Ben,
>
>> For my money, John Allsopp's idea to reuse rel="bookmark self" [1]
>> makes most sense. As well as being gorgeously consistent with
>> other existing microformats, it's also a completely graceful
>> addition to existing hCards.
>
> thanks ;-)
>
> There's a lot of goodness to reuse from other ufs, for sure.
Right, but there's also a lot of use to reusing things from the
present microformat (hCard).
vCard has a property called UID, which is defined as:
"""
Type purpose: To specify a value that represents a globally unique
identifier corresponding to the individual or resource associated
with the vCard.
"""
This is actually already in use by several large microformat
publisher (eventful.com) to between venues in their events and the
hCards for those events.
It's been proposed before that using URL and UID together is
sufficient for the things we're trying to solve here (I'm having
trouble finding a reference in the archives).
Ryan King
> Well, I certainly am coming to the party late.
>
> I actually started a post on this topic over a week ago -- and
> absentmindedly hadn't checked on this list first before posting and
> therefore published without the benefit of this discussion (I can hear
> Tantek chiding me) but nonetheless, as the first half of a two-part
> piece of transcending social networks (I have to write up the second
> half still) I wrote this:
>
> Scoping XFN and identifying authoritative hcards
> <http://factoryjoe.com/blog/2007/01/29/scoping-xfn-and-identifying-
> definitive-hcards/>
As I'm sure you know, the scope of XFN is URLs, not parts of pages.
To change this would be non-trivial and is not likely to happen.
Plus, there are much simpler ways to solve this problem.
-ryan
Ryan King
> Chris,
>
> (all the following simply thoughts in the spirit of brainstorming,
> rather than any particular argument in favour of my original
> suggestion)
>
>> I pretty much came up with a very similar proposal for handling this
>> issue, though from the standpoint of XFN-links, and I think that
>> John's suggestion is very good, though instead of using "bookmark
>> self" might suggest "me self" for identifying the One True Hcard:
>>
>> <div class="vcard" id="vcard">
>> <address><a href="http://factoryjoe.com/blog/hcard/#hcard" class="fn
>> url" rel="me self">Chris Messina</a></address>
>> <div class="org">Citizen Agency</a>
>> ...
>> </div>
>
> I wonder whether hAtom had predated XFN, self instead of me would
> have been chosen for the identity value?
>
> The "definition" of the self attribute value in Atom is "self: the
> feed itself". The term "the" seems to indicate "definitiveness".
> So, I was initially going to argue that "self me" was tautological,
> but in fact, in this sense it is not, and indeed, the addition of
> bookmark is probably tautological.
Right, 'self' implies singular and is supposed to signal the URI (or
IRI) for the feed itself, not an alternative representation or
related resource elsewhere.
'me' just means another resource that represents the same person.
> So, I'd probably +1 this suggestion, and perhaps also suggest that
> for hReview simply a rel value of "self" be required for the
> permalink, for consistency.
rel=bookmark is in HTML4, there's no reason to ignore it.
Ryan King
> On 2/1/07, John Allsopp <jo...@westciv.com> wrote:
>> use case - sure - for example, at our conference sites, we markup
>> speakers with hCard, and this often includes a link to their blog
>> etc. In this case, a link to an authoritative (or perhaps, to be even
>> less strict "detailed") hCard may be somethign that is very useful.
>
> If I understand the spec correctly, since a rel="me" is symmetric,
> shouldn't the hCard you're pointing to also be pointing back? If
> that's true, then the authoritative hCard will quickly get
> unmanageable since it will contain tens if not hundreds of reciprocal
> links to partial hCards (imagine if you're listed in several different
> locale directories marked up with hCard).
You're right, rel=me requires symmetry in order to be trusted at all.
For this reason, and others XFN is not the simplest way to do
Authoritative hCards.
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
Edward O'Connor
> Right, but there's also a lot of use to reusing things from the
> present microformat (hCard).
>
>
> vCard has a property called UID, which is defined as:
>
> """
> Type purpose: To specify a value that represents a globally unique
> identifier corresponding to the individual or resource associated with
> the vCard.
> """
>
> This is actually already in use by several large microformat publisher
> (eventful.com) to between venues in their events and the hCards for
> those events.
>
> It's been proposed before that using URL and UID together is
> sufficient for the things we're trying to solve here (I'm having
> trouble finding a reference in the archives).
<some-element class="vcard">
...
<a rel="me url uid" ...
This feels right to me. Also, from an OpenID perspective, rel="uid" in
an hcard sounds an awful lot like "this is my id."
[And yes, we (eventful.com) use rel="url uid" to point from a venue
hcard in an event entry to the venue's own (authoritative) page.]
Ted
--
Edward O'Connor
hob...@gmail.com
Ense petit placidam sub libertate quietem.
Ryan King
>> Chris Messina:
>>> <div class="vcard" id="vcard">
>>> <address><a href="http://factoryjoe.com/blog/hcard/#hcard"
>>> class="fn
>>> url" rel="me self">Chris Messina</a></address>
>>> <div class="org">Citizen Agency</a>
>>> ...
>>> </div>
>>>
>
> John Allsopp:
>> The "definition" of the self attribute value in Atom is "self: the
>> feed itself". The term "the" seems to indicate "definitiveness".
>> So, I was initially going to argue that "self me" was
>> tautological, but in fact, in this sense it is not, and indeed,
>> the addition of bookmark is probably tautological.
>>
>> So, I'd probably +1 this suggestion, […]
>
> +1 from me as well.
>
> Can we gauge wider support for this addition? Any problems from
> anyone?
Yes there are several problems:
1. XFN applies to whole pages. This means that you can't reliably put
different people's hCards on the same page and do this.
2. We have prior art that is being ignored. Publishers are already
using <a class="url uid" ...>...</a> to do this.
I apologize for being late to this discussion, but I think it's off
track and we need to correct things a bit.
-ryan
--
Ryan King
ry...@technorati.com
Ara Pehlivanian
> You're right, rel=me requires symmetry in order to be trusted at all.
> For this reason, and others XFN is not the simplest way to do
> Authoritative hCards.
I guess the real question is, "who will be creating the partial hCards
that will be referring to the authoritative hCard?" If the answer is,
"the owner of the authoritative hCard" then the scenario is manageable
and the owner can update the authoritative hCard at their leisure to
reflect the partial ones created. However, if the answer is, "anyone"
then the spec is impossible to support because the author of the
authoritative hCard has absolutely no way of tracking all of the
partial cards referring to the authoritative one. A prime example is
if you're a speaker at a conf. and the organizers put together a
simple hCard with your name in it and point to your authoritative
hCard. Worse still, if a phone directory site marks up their results
with hCard, how would you ever know to link to it? Which page would
you link to (as results tend to have multiple views).
The worst part of either scenario is the idea that your authoritative
hCard will keep growing with all this unsightly references to lesser
cards. It's a maintenance and aesthetic nightmare.
I say we should find a better way of doing this.
A.
David Janes
> On 2/7/07, Ryan King <ry...@technorati.com> wrote:
> > You're right, rel=me requires symmetry in order to be trusted at all.
> > For this reason, and others XFN is not the simplest way to do
> > Authoritative hCards.
>
> I guess the real question is, "who will be creating the partial hCards
> that will be referring to the authoritative hCard?" If the answer is,
> "the owner of the authoritative hCard" then the scenario is manageable
> and the owner can update the authoritative hCard at their leisure to
> reflect the partial ones created. However, if the answer is, "anyone"
> then the spec is impossible to support because the author of the
> authoritative hCard has absolutely no way of tracking all of the
> partial cards referring to the authoritative one. A prime example is
> if you're a speaker at a conf. and the organizers put together a
> simple hCard with your name in it and point to your authoritative
> hCard. Worse still, if a phone directory site marks up their results
> with hCard, how would you ever know to link to it? Which page would
> you link to (as results tend to have multiple views).
>
> The worst part of either scenario is the idea that your authoritative
> hCard will keep growing with all this unsightly references to lesser
> cards. It's a maintenance and aesthetic nightmare.
I think you're missing a stage:
- fragment hcard (anywhere on the net by anybody)
- points to home page, using class="url"
- home page, using class="something" rel="something-else", points to
authoritative hcard
e.g. Ryan King hCards in the wild point to http://www.ryanking.com;
http://www.ryanking.com (somehow) points to
http://www.ryanking.com/contact/ which has his authoritative hCard.
At most one back reference is required.
Regard, etc...
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
Ara Pehlivanian
> I think you're missing a stage:
>
> - fragment hcard (anywhere on the net by anybody)
> - points to home page, using class="url"
> - home page, using class="something" rel="something-else", points to
> authoritative hcard
>
> e.g. Ryan King hCards in the wild point to http://www.ryanking.com;
> http://www.ryanking.com (somehow) points to
> http://www.ryanking.com/contact/ which has his authoritative hCard.
>
> At most one back reference is required.
Is that the intended use though? Just managing the authoritative hCard
within a domain?
A.
David Janes
> > I think you're missing a stage:
> >
> > - fragment hcard (anywhere on the net by anybody)
> > - points to home page, using class="url"
> > - home page, using class="something" rel="something-else", points to
> > authoritative hcard
> >
> > e.g. Ryan King hCards in the wild point to http://www.ryanking.com;
> > http://www.ryanking.com (somehow) points to
> > http://www.ryanking.com/contact/ which has his authoritative hCard.
> >
> > At most one back reference is required.
>
> Is that the intended use though? Just managing the authoritative hCard
> within a domain?
No, Ryan King could have his authoritative hCard on LinkedIn
(hypothetical example). He still, however, refers to himself in his
hCards as url=http://www.ryanking.com (real example).
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
David Janes
>
> 1. XFN applies to whole pages. This means that you can't reliably put
> different people's hCards on the same page and do this.
>
> 2. We have prior art that is being ignored. Publishers are already
> using <a class="url uid" ...>...</a> to do this.
>
>
> I apologize for being late to this discussion, but I think it's off
> track and we need to correct things a bit.
>
Sure. Show us how it works with the original real-world case I
provided -- i.e. your hCard on microformats.org blog, pointing to your
home page, using your /contacts hcard as your authoritative hCard.
Regards, etc...
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
Ara Pehlivanian
> On 2/7/07, Ara Pehlivanian <ara.peh...@gmail.com> wrote:
> > On 2/7/07, David Janes <david...@blogmatrix.com> wrote:
> > > I think you're missing a stage:
> > >
> > > - fragment hcard (anywhere on the net by anybody)
> > > - points to home page, using class="url"
> > > - home page, using class="something" rel="something-else", points to
> > > authoritative hcard
> > >
> > > e.g. Ryan King hCards in the wild point to http://www.ryanking.com;
> > > http://www.ryanking.com (somehow) points to
> > > http://www.ryanking.com/contact/ which has his authoritative hCard.
> > >
> > > At most one back reference is required.
> >
> > Is that the intended use though? Just managing the authoritative hCard
> > within a domain?
>
> No, Ryan King could have his authoritative hCard on LinkedIn
> (hypothetical example). He still, however, refers to himself in his
> hCards as url=http://www.ryanking.com (real example).
Okay, but the only references made to the authoritative hCard are by
hCards created by Ryan himself. Nobody else can create an hCard and
use rel="me" (which makes sense).
A.
Ryan King
> On 2/7/07, Ara Pehlivanian <ara.peh...@gmail.com> wrote:
>> On 2/7/07, David Janes <david...@blogmatrix.com> wrote:
>> > I think you're missing a stage:
>> >
>> > - fragment hcard (anywhere on the net by anybody)
>> > - points to home page, using class="url"
>> > - home page, using class="something" rel="something-else",
>> points to
>> > authoritative hcard
>> >
>> > e.g. Ryan King hCards in the wild point to http://www.ryanking.com;
>> > http://www.ryanking.com (somehow) points to
>> > http://www.ryanking.com/contact/ which has his authoritative hCard.
>> >
>> > At most one back reference is required.
>>
>> Is that the intended use though? Just managing the authoritative
>> hCard
>> within a domain?
>
> No, Ryan King could have his authoritative hCard on LinkedIn
> (hypothetical example). He still, however, refers to himself in his
> hCards as url=http://www.ryanking.com (real example).
Actually it's *the*ryanking.com. ;)
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
Ryan King
> Ryan wrote:
>
>> Right, but there's also a lot of use to reusing things from the
>> present microformat (hCard).
>>
>>
>> vCard has a property called UID, which is defined as:
>>
>> """
>> Type purpose: To specify a value that represents a globally unique
>> identifier corresponding to the individual or resource associated
>> with
>> the vCard.
>> """
>>
>> This is actually already in use by several large microformat
>> publisher
>> (eventful.com) to between venues in their events and the hCards for
>> those events.
>>
>> It's been proposed before that using URL and UID together is
>> sufficient for the things we're trying to solve here (I'm having
>> trouble finding a reference in the archives).
>
> <some-element class="vcard">
> ...
> <a rel="me url uid" ...
>
> This feels right to me. Also, from an OpenID perspective, rel="uid" in
> an hcard sounds an awful lot like "this is my id."
uid goes on @class, not rel. It doesn't have to be on an anchor, nor
must it be a URL.
> [And yes, we (eventful.com) use rel="url uid" to point from a venue
> hcard in an event entry to the venue's own (authoritative) page.]
Actually you use @class.
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
Ryan Cannon
> 2. We have prior art that is being ignored. Publishers are already
> using <a class="url uid" ...>...</a> to do this.
However, UID is not a field that takes a URL for its value, just a
string, so therefore:
<a class="url uid" href="http://ryancannon.com/">Ryan</a>
Should be parsed as
URL: http;//ryancannon.com/
UID: Ryan
Right?
So while UID seems like the right value to use, according to my
reading of the spec, UID has to sit in visible text, and could be any
sort of number--like an American social security number or a mobile
phone number with country code--both of those are usually globally
unique individual identifiers.
--
Ryan Cannon
Interactive Developer
MSI Student, School of Information
University of Michigan
http://RyanCannon.com
Edward O'Connor
> string, so therefore:
Perhaps this is addressed in [1] or [2]?
1. http://microformats.org/wiki/uid-brainstorming
2. http://microformats.org/discuss/mail/microformats-discuss/2006-April/003726.html
(See also the rest of the thread)
--
Edward O'Connor
hob...@gmail.com
Ense petit placidam sub libertate quietem.
_______________________________________________
Edward O'Connor
> uid goes on @class, not rel.
Yes, thanks for the correction.
Ted
Ryan King
> On 2/7/07, Ryan King <ry...@technorati.com> wrote:
>> Yes there are several problems:
>>
>> 1. XFN applies to whole pages. This means that you can't reliably put
>> different people's hCards on the same page and do this.
>>
>> 2. We have prior art that is being ignored. Publishers are already
>> using <a class="url uid" ...>...</a> to do this.
>>
>>
>> I apologize for being late to this discussion, but I think it's off
>> track and we need to correct things a bit.
>>
>
> Sure. Show us how it works with the original real-world case I
> provided -- i.e. your hCard on microformats.org blog, pointing to your
> home page, using your /contacts hcard as your authoritative hCard.
On mf.org:
<address class="author vcard"><a class="url uid fn" href="http://
theryanking.com/">Ryan</a></address>
<address class="vcard">This site is the work of <a href="http://
theryanking.com/blog/contact/#vcard" class="fn uid url">Ryan King</
a></address>
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
Ryan King
>> However, UID is not a field that takes a URL for its value, just a
>> string, so therefore:
>
> Perhaps this is addressed in [1] or [2]?
>
>
> 1. http://microformats.org/wiki/uid-brainstorming
> 2. http://microformats.org/discuss/mail/microformats-discuss/2006-
> April/003726.html
> (See also the rest of the thread)
Indeed. I was trying to find those references, but failed. Thanks.
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
Ryan King
> On Feb 7, 2007, Ryan King wrote:
>> 2. We have prior art that is being ignored. Publishers are already
>> using <a class="url uid" ...>...</a> to do this.
>
> However, UID is not a field that takes a URL for its value, just a
> string, so therefore:
>
> <a class="url uid" href="http://ryancannon.com/">Ryan</a>
>
> Should be parsed as
>
> URL: http;//ryancannon.com/
> UID: Ryan
>
> Right?
>
> So while UID seems like the right value to use, according to my
> reading of the spec, UID has to sit in visible text, and could be
> any sort of number--like an American social security number or a
> mobile phone number with country code--both of those are usually
> globally unique individual identifiers.
Indeed, in vcard UID is just a string, but my proposal is that we
make it by default a URL. It's a simple change (which may already be
implemented in X2V).
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
David Janes
> On Feb 7, 2007, at 12:50 PM, David Janes wrote:
>
> > On 2/7/07, Ryan King <ry...@technorati.com> wrote:
> >> Yes there are several problems:
> >>
> >> 1. XFN applies to whole pages. This means that you can't reliably put
> >> different people's hCards on the same page and do this.
> >>
> >> 2. We have prior art that is being ignored. Publishers are already
> >> using <a class="url uid" ...>...</a> to do this.
> >>
> >>
> >> I apologize for being late to this discussion, but I think it's off
> >> track and we need to correct things a bit.
> >>
> >
> > Sure. Show us how it works with the original real-world case I
> > provided -- i.e. your hCard on microformats.org blog, pointing to your
> > home page, using your /contacts hcard as your authoritative hCard.
>
>
> On mf.org:
>
> <address class="author vcard"><a class="url uid fn" href="http://
> theryanking.com/">Ryan</a></address>
>
> at http://theryanking.com/:
>
> <address class="vcard">This site is the work of <a href="http://
> theryanking.com/blog/contact/#vcard" class="fn uid url">Ryan King</
> a></address>
And at the end-point? (i.e. on /blog/contact). The reason I'm asking
is "what's the rule for determining if the hCard I'm looking at points
to the authorative one". Both of these look the same.
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
NewsAgent 2000grad
my name is Henrich C. Poehls, I have been reading the list for quite
some while now, without writing. It has been very interesting to see
that the topic of authoritative hcards led the discussion to the topic
of trust and Digital Signatures.
>> Perhaps we need a "class="pgp-public-key" property for hCard?
>
> There's already a KEY field in vCard. From RFC2624:
>
>> Type purpose: To specify a public key or authentication certificate
>> associated with the object that the vCard represents.
>
> I'm sure we could make this work. :D
>
> -ryan
> --
> Ryan King
> ry...@technorati.com
In fact, I already did some work in the direction of Signed
Microformatted Content and thought it might be a good time to start a
discussion about my thoughts. For a Microformats process, however no
real world examples using such a thing like digitally signed content on
webpages exist, yet. But I believe there are some good uses for a
Microformat for Digital Signatures (this might also solve the problem of
MD5 Hashes discussed some time before).
A short overview of a proposed structure can be found on my page [1].
I am happy about comments, maybe here or maybe in the new
microformats-new, to which I just subscribed.
Henrich
[1] http://www.informatik.uni-hamburg.de/SVS/personnel/henrich/hsig.php
Ryan King
Nothing special is needed at /blog/contact/.
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
David Janes
> Nothing special is needed at /blog/contact/.
>
> -ryan
But that's the authoritative hCard. What's the algorithm (or
heuristic) that I follow if I'm a parser looking at the blog at
microformats.org, see your partial hCard and try to find your
authoritative hCard?
Sorry if this sounds pedantic, I'm not trying to be. There's some
assumption in what you're saying that I'm not getting.
Regards, etc...
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
Ben Ward
On 8 Feb 2007, at 19:02, David Janes wrote:
> On 2/8/07, Ryan King <ry...@technorati.com> wrote:
>> Nothing special is needed at /blog/contact/.
>>
>> -ryan
>
>
> Sorry if this sounds pedantic, I'm not trying to be. There's some
> assumption in what you're saying that I'm not getting.
The difference in interpretation is this: You're looking to describe
the *one true hcard*, to rule them all, bind them in the darkness and
so on and so forth.
What Ryan is describing is *relative*. So linking with UID from one
small hcard in the footer of ben-ward.co.uk to a larger, more
complete hcard at ben-ward.co.uk/about is saying, very simply: ‘/
about is the authoritative hcard _of this hcard_’.
Now, to step back into this discussion after a little break, this use
of UID solves *my* problem; a way to point from small snippet hCards
that contain name/URL to larger ones which contain comprehensive
contact details. I'm not trying to rule Middle Earth, just to say
‘there's a more comprehensive hcard over here’. And for me, this
would do the trick very nicely.
Of course, there's nothing to stop me linking _that_ ‘/about’ hCard
to another one somewhere else; such practice should not be
disallowed. But at this point, that could be getting out of 80:20.
Regards,
Ben
David Janes
>
> On 8 Feb 2007, at 19:02, David Janes wrote:
> > On 2/8/07, Ryan King <ry...@technorati.com> wrote:
> >> Nothing special is needed at /blog/contact/.
> >>
> >> -ryan
> >
> > But that's the authoritative hCard. […]
> >
>
>
> > Sorry if this sounds pedantic, I'm not trying to be. There's some
> > assumption in what you're saying that I'm not getting.
>
> The difference in interpretation is this: You're looking to describe
> the *one true hcard*, to rule them all, bind them in the darkness and
> so on and so forth.
No no no. I'm looking for the set of rules a consumer has to follow to
get from Ryan's hCard on microformats.org to his authoritative hCard
at *the*ryanking/contact.
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
_______________________________________________
Scott Reynen
> No no no. I'm looking for the set of rules a consumer has to follow to
> get from Ryan's hCard on microformats.org to his authoritative hCard
> at *the*ryanking/contact.
I thought Ryan already answer that:
On Feb 7, 2007, at 4:34 PM, Ryan King wrote:
> On mf.org:
>
> <address class="author vcard"><a class="url uid fn" href="http://
> theryanking.com/">Ryan</a></address>
>
> at http://theryanking.com/:
>
> <address class="vcard">This site is the work of <a href="http://
> theryanking.com/blog/contact/#vcard" class="fn uid url">Ryan King</
> a></address>
So as I understand that, the rules for getting the most authoritative
hCard for a given URL are:
1) parse hCard at current URL
2) If the hCard includes <a class="uid url">, load the URL in the
href, and return to step 1.
When the consumer gets to http://theryanking.com/blog/contact/#vcard
and finds no <a class="uid url">, it stops there and that's his
authoritative hCard.
Peace,
Scott
David Janes
> So as I understand that, the rules for getting the most authoritative
> hCard for a given URL are:
>
> 1) parse hCard at current URL
> 2) If the hCard includes <a class="uid url">, load the URL in the
> href, and return to step 1.
>
> When the consumer gets to http://theryanking.com/blog/contact/#vcard
> and finds no <a class="uid url">, it stops there and that's his
> authoritative hCard.
OK (and I'm not trying to turn into Andy here), but doesn't this feel
at least a little unsatisfactory? That the authoritative hCard is the
one that _doesn't_ have a UID, i.e. potentially has less information
than a fragment hCard?!
I'm not killer against the idea or anything, but at least I think that
should be brought up.
Here's one potential usage snag:
- I copy the hCard at http://theryanking.com/blog/contact/#vcard to my
"address book"
- I use it somewhere (to refer to Ryan King)
- It doesn't have a UID, so there's no tracing it back to source
Regards, etc...
--
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
David Janes
> On 2/8/07, Scott Reynen <sc...@randomchaos.com> wrote:
>
> > So as I understand that, the rules for getting the most authoritative
> > hCard for a given URL are:
> >
> > 1) parse hCard at current URL
> > 2) If the hCard includes <a class="uid url">, load the URL in the
> > href, and return to step 1.
> >
> > When the consumer gets to http://theryanking.com/blog/contact/#vcard
> > and finds no <a class="uid url">, it stops there and that's his
> > authoritative hCard.
>
> OK (and I'm not trying to turn into Andy here), but doesn't this feel
> at least a little unsatisfactory? That the authoritative hCard is the
> one that _doesn't_ have a UID, i.e. potentially has less information
> than a fragment hCard?!
>
> I'm not killer against the idea or anything, but at least I think that
> should be brought up.
>
> Here's one potential usage snag:
> - I copy the hCard at http://theryanking.com/blog/contact/#vcard to my
> "address book"
> - I use it somewhere (to refer to Ryan King)
> - It doesn't have a UID, so there's no tracing it back to source
And to do the dreaded "answering own e-mail", here's an alternate:
- fragment hCards do not need to have "uid", just "url"
- consumers (if they're interested) can dereference that URL
- if there is a UID hCard at the URL, dereference it
- the dereferenced hCard is the authoritative one
(I'm totally skipping the multiple hCard/hCard-matching issue for brevity)
Scott Reynen
>> That the authoritative hCard is the
>> one that _doesn't_ have a UID, i.e. potentially has less information
>> than a fragment hCard?!
I think this is how authority generally works in practice, from
external references.
>> Here's one potential usage snag:
>> - I copy the hCard at http://theryanking.com/blog/contact/#vcard
>> to my
>> "address book"
>> - I use it somewhere (to refer to Ryan King)
>> - It doesn't have a UID, so there's no tracing it back to source
Right, not every fragment will point back to the source. I don't
think we can solve that problem without assuming pointers where none
were intended, which would cause a much larger problem.
> And to do the dreaded "answering own e-mail", here's an alternate:
>
> - fragment hCards do not need to have "uid", just "url"
> - consumers (if they're interested) can dereference that URL
> - if there is a UID hCard at the URL, dereference it
> - the dereferenced hCard is the authoritative one
So if I point my hCard to my employer's website, where they have an
hCard for the organization, my hCard is then replaced by my
employer's? I don't think we can safely expand the meaning of "url"
like that. Right now, it only suggests some vague association
between the object of the hCard (e.g. me), and the destination (e.g.
my employer's website). Acting as a pointer to a more authoritative
hCard is a more specific meaning, and would invalidate a large number
of already-published hCards.
Peace,
Scott
Joe Andrieu
> On Feb 8, 2007, at 4:29 PM, David Janes wrote:
>
> >> That the authoritative hCard is the
> >> one that _doesn't_ have a UID, i.e. potentially has less
> information
> >> than a fragment hCard?!
>
> I think this is how authority generally works in practice, from
> external references.
Scott,
Actually, I think that's quite contradicted by evidence in the wild,
especially in the offline world. Birth certificates, passports,
driver's licenses, etc., have indicia asserting their authority.
I had previously voted for rel="self me", but the symmetry of that is
more of a low-security technique to establish mutually endorsed
validity. Interesting, but only partially useful.
I'd like to reintroduce @rel="via" to the conversation[1]:
5. The value "via" signifies that the IRI in the value of the href
attribute identifies a resource that is the source of the
information provided in the containing element.
Why not just have a "via" point to "source" hCards and any hCard that is
self-referential is "authoritative"? That seems both easy for
publishers and relatively straightforward for parsers. Keep
dereferencing @rel="via" attributes until you find one that dereferences
to itself with @rel="via self". Once you get to one that says "I'm my
own source," you've got a reasonable assertion of authority.
Ryan Cannon suggested this previously [2], but it seemed to get lost in
"uid url" conversations.
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.
Here's the formal def for @rel="self"
3. The value "self" signifies that the IRI in the value of the href
attribute identifies a resource equivalent to the containing
element.
So, refering hCards use @rel="via" and the authoritative hCard uses
@rel="via self". And if you don't want to use an <a> link that is
self-referential use a span with class="via self url".
And if the url in the rel is also the aid, the @rel="via uid" and
@rel="via self uid" should work fine.
Seems a good way to bootstrap authority.
-j
[1] http://www.ietf.org/rfc/rfc4287.txt
[2]
http://microformats.org/discuss/mail/microformats-discuss/2007-January/0
08443.html
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
Ryan King
> On 2/8/07, Ryan King <ry...@technorati.com> wrote:
>> Nothing special is needed at /blog/contact/.
>
> But that's the authoritative hCard. What's the algorithm (or
> heuristic) that I follow if I'm a parser looking at the blog at
> microformats.org, see your partial hCard and try to find your
> authoritative hCard?
>
> Sorry if this sounds pedantic, I'm not trying to be. There's some
> assumption in what you're saying that I'm not getting.
You're right, I haven't fully explained one of my assumptions. That
assumption is that we should solve the simpler problem of 'related
hcards' first, before we try to solve the problem of authoritative
hcards.
Secondly, using my proposal you might be able to sort out
authoritative hCards by simply following the url+uid links back until
you find an hcard that doesn't link to another with url+uid.
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
Ryan King
> On 2/8/07, Ben Ward <li...@ben-ward.co.uk> wrote:
>>
>> On 8 Feb 2007, at 19:02, David Janes wrote:
>> > On 2/8/07, Ryan King <ry...@technorati.com> wrote:
>> >> Nothing special is needed at /blog/contact/.
>> >>
>> >> -ryan
>> >
>> > But that's the authoritative hCard. […]
>> >
>>
>>
>> > Sorry if this sounds pedantic, I'm not trying to be. There's some
>> > assumption in what you're saying that I'm not getting.
>>
>> The difference in interpretation is this: You're looking to describe
>> the *one true hcard*, to rule them all, bind them in the darkness and
>> so on and so forth.
>
> No no no. I'm looking for the set of rules a consumer has to follow to
> get from Ryan's hCard on microformats.org to his authoritative hCard
> at *the*ryanking/contact.
The algorithm is simple and recursive:
1. if uid != url you're done
2. if url == uid and there's an hCard at that url, recurse with the
new hCard
-ryan
--
Ryan King
ry...@technorati.com
Ryan King
> On 2/8/07, Scott Reynen <sc...@randomchaos.com> wrote:
>
>> So as I understand that, the rules for getting the most authoritative
>> hCard for a given URL are:
>>
>> 1) parse hCard at current URL
>> 2) If the hCard includes <a class="uid url">, load the URL in the
>> href, and return to step 1.
>>
>> When the consumer gets to http://theryanking.com/blog/contact/#vcard
>> and finds no <a class="uid url">, it stops there and that's his
>> authoritative hCard.
>
> OK (and I'm not trying to turn into Andy here), but doesn't this feel
> at least a little unsatisfactory? That the authoritative hCard is the
> one that _doesn't_ have a UID, i.e. potentially has less information
> than a fragment hCard?!
I just thought of another base case in the recursive algorithm
if the uid of the current hcard equals that of the previous, you're
done.
> I'm not killer against the idea or anything, but at least I think that
> should be brought up.
I agree, what I'm proposing does less than what you proposed. But, I
think we need to solve this simpler problem first.
> Here's one potential usage snag:
> - I copy the hCard at http://theryanking.com/blog/contact/#vcard to my
> "address book"
> - I use it somewhere (to refer to Ryan King)
> - It doesn't have a UID, so there's no tracing it back to source
Sure, that would be unfortunate, but with the addition of the second
base case (see above) it would be solved.
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________
Ryan King
> Scott Reynen wrote:
>> On Feb 8, 2007, at 4:29 PM, David Janes wrote:
>>
>>>> That the authoritative hCard is the
>>>> one that _doesn't_ have a UID, i.e. potentially has less
>> information
>>>> than a fragment hCard?!
>>
>> I think this is how authority generally works in practice, from
>> external references.
>
> Scott,
>
> Actually, I think that's quite contradicted by evidence in the wild,
> especially in the offline world. Birth certificates, passports,
> driver's licenses, etc., have indicia asserting their authority.
>
> I had previously voted for rel="self me", but the symmetry of that is
> more of a low-security technique to establish mutually endorsed
> validity. Interesting, but only partially useful.
As explained previously, rel="me" can't help us here, because it
applies to the entire page, not a part of a page. That means that it
can't be used in places like my staff hCard at technorati: http://
technorati.com/about/staff.html#ryan_king, because there are many
hCards on that page.
> I'd like to reintroduce @rel="via" to the conversation[1]:
> 5. The value "via" signifies that the IRI in the value of the href
> attribute identifies a resource that is the source of the
> information provided in the containing element.
>
> Why not just have a "via" point to "source" hCards and any hCard
> that is
> self-referential is "authoritative"?
The simple answer is that we may already have a mechanism in hCard/
vCard which is sufficient (ie, UID). We should only look to add
things if there is nothing already in the format which is sufficient.
> That seems both easy for
> publishers and relatively straightforward for parsers. Keep
> dereferencing @rel="via" attributes until you find one that
> dereferences
> to itself with @rel="via self". Once you get to one that says "I'm my
> own source," you've got a reasonable assertion of authority.
It appears to me that this is essentially the same algorithm as the
url+uid proposal, but with adding new terms.
> Ryan Cannon suggested this previously [2], but it seemed to get
> lost in
> "uid url" conversations.
>
> 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.
Also, the url+uid proposal only concerns the case where the url and
uid are the same (and, therefore, a URL).
-ryan
--
Ryan King
ry...@technorati.com
_______________________________________________