On Feb 8, 2007, at 7:45 PM, Lachlan Hardy wrote:
Hi, Ryan
Thanks for summarising. It was getting confusing skipping around all
those threads
I want to address your points out of order, if I may. Firstly, just to
check that I have understood your proposal correctly
Also, the algorithm for finding the most authoritative hCard:
1. if no uid or uid == the uid from the previous iteration/recursion
=> you're done
2. if url == uid and there's an hCard at that url, recurse with the
new hCard
To provide examples of my understanding of your proposal:
various hCards for Chris Messina (thanks for having so many hCards,
Chris!) at places such as ClaimID, blogrolls, conference sites etc
would read:
ClaimID:
<a class="url uid fn" href="http://factoryjoe.com/blog/hcard";>Chris
Messina</a>
or blog link to Some Conference:
<a class="url uid fn"
href="http://someconference.com/speakers/chrismessina";>Chris
Messina</a>
or link from Some Conference:
<a class="url uid fn" href="http://factoryjoe.com/blog/hcard";>Chris
Messina</a>
At each of these URLs it finds another hCard that leads on again, thus
identifying a series of related hCards. All of which are tied, by
virtue of the UID, to the value of the element (in this case, 'Chris
Messina')
Eventually, our parser ends up at factoryjoe.com/blog/hcard and finds
an hCard containing:
<a class="url uid fn" href="http://factoryjoe.com/blog/hcard";>Chris
Messina</a>
or
<a class="url fn" href="http://factoryjoe.com/blog/hcard";>Chris
Messina</a>
The self-referential nature of this link indicates that it is the
'authoritative' hCard.
Have I understood you correctly, Ryan?
I believe so.
I'd propose that the UID is still required at the final hCard, to
explicitly confirming that *this* URL is the definitive one for the
object of this hCard.
Or is an explicit reference superfluous given the implicit
confirmation of the self-referential URL?
You actually bring up a good point that I hadn't thought of yet.
I don't think we need a UID at the terminal hCard in order to
conclude that the hCards represent the same person/organization (or,
at least, their publishers think so).
However, the addition of UID at the terminal hCard may allow us to
conclude that it is authoritative.
My proposal is that we use UID+URL to hint that there's an hCard on
the other end of that URL which represents the same entity. Also,
multiple hCards with the same UID may be considered as representing
the same entity.
To move on, I get the feeling I'm missing something here. Your
proposal seems to me to suggest that we add UID to all URLs to that
indicate the presence of a related hCard (of another hCard which has
the same subject - either person or organisation)
I'd suggest that UID is initially unnecessary. FN+URL could provide
the same understanding - eg a unique combination within a hCard,
defining the subject of the hCard and providing a pointer to further
information
This is too brittle and lacks explicit semantics. I've actually build
a tool that tried to do cluster of hCards by FN+URL (based on data
from our search engine [http://kitchen.technorati.com/search/]), but
found a large number of false negatives. For example, if you linked
to by blog the link form the mf.org blog to my blog wouldn't work,
because the FN's are different ('Ryan' vs. 'Ryan King').
-ryan
--
Ryan King
[EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
