[uf-discuss] "authoritative hCards", a simpler proposl

[Ryan King]

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
ryan at technorati.com