RE: [uf-discuss] "authoritative hCards", a simpler proposl
Ara Pehlivanian wrote: > Maybe the problem is that we're trying to point to an > authoratative hCard when in reality what we want to do is > simply (like you just said) point to a more detailed > hCard. > > > > The moment the ID is provided, it indicates that the link > isn't just pointing to any old resource on the web, but > that it is in fact pointing to a more detailed hCard. I think that makes a huge amount of sense. Determining authoritativeness is hard, leave it to another initiative and get almost everything else needed w/o it. Great suggestion. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] "authoritative hCards", a simpler proposl
Scott Reynen wrote: > I think you're still a bit confused about what was > suggested. Indeed I was confused. I could have sworn I saw some kind of usage that tagged a GUID on the end of a URL, which is what confused me, but I can't seem to find that email in my folders so, not important. Thanks for the clarification. > Many UIDs happen to be random strings of numbers and/or > letters, but that's not at all a requirement for UIDs. And I hope, something that would be frowned on! > So the proposal was just to add the UID class name to the > URL class name, e.g. Ryan King, not > to add anything to the actual URL. Cool! -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] "authoritative hCards", a simpler proposl
On 3/4/07, John Allsopp <[EMAIL PROTECTED]> wrote: Hi all, Mike Schinkel wrote: > Ryan King wrote: >> Catching up in the last few days, I find that there are some >> probelems with the "authoritative hcards" proposals. I' >> >> >> >> 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. > > In reviewing this I can't help but feel that I don't understand the > use-case > or the desired outcome. Will someone kindly explain? Is it that > there > could be hundreds of hCards on the web for Ryan King (the one for > the guy > who has the email address of [EMAIL PROTECTED]) but only one > should be > considered 'authoritative?" A number of somewhat overlapping suggestions seem to be floating around regarding this. There is definitely a strong use case, IMO, for somehow indicating that some hCard over there is a more detailed version of this one. For example, at the various conference sites I am involved wiht, we mark up all speakers using hCard. Ofen it's simply http://johnfallsopp.com"; class="url fn">John Allsopp Now, if this could point at an hCard with more information about the speaker so marked up, to me that would be potentially very useful for something like Tails or Operator to pull in that additional information, or for aggregating references to the same person and on. As to definitiveness or authoriativeness, I think that's a tougher nut to crack. j ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss Maybe the problem is that we're trying to point to an authoratative hCard when in reality what we want to do is simply (like you just said) point to a more detailed hCard. That way, if you have a professional hCard set up on your work site you might want to point to that from your conference listing page, but if you have a personal one set up as well you might want to point to IT from a personal site somewhere. Managing "authoritative" relationships between cards seems to be more hassle than it's worth. Simply pointing to a more detailed card could be the solution. So for example, the rule could simply be that the anchor with class="url" found inside the hCard will point to a more detailed hCard should it have a direct reference to an ID. In other words the following example would be pointing to a more detailed hCard: http://johnfallsopp.com/about/#myInfo"; class="url fn">John Allsopp The moment the ID is provided, it indicates that the link isn't just pointing to any old resource on the web, but that it is in fact pointing to a more detailed hCard. The only problem that I can see with this model is that you might not want your hyperlink dropping to the hCard's location when it's clicked. A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] "authoritative hCards", a simpler proposl
On Mar 4, 2007, at 10:05 PM, Mike Schinkel wrote: And, being an advocate for "Well Designed URLs", I do not think the right solution is to simply tag a random and undiscoverable and unmemorizable UID onto the end of a URL. But I'd have to understand the problem domain and use-cases to be better able to make an alternate proposal. I think you're still a bit confused about what was suggested. Every URL is already a potential UID, so there's no need to add anything onto the end. URLs are unique, and some of them (e.g. http:// theryanking.com/blog/contact/#vcard) identify people. That's all a UID needs to be: unique and identifying. Many UIDs happen to be random strings of numbers and/or letters, but that's not at all a requirement for UIDs. So the proposal was just to add the UID class name to the URL class name, e.g. Ryan King, not to add anything to the actual URL. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] "authoritative hCards", a simpler proposl
John Allsopp wrote: > A number of somewhat overlapping suggestions seem to be > floating around regarding this. > > There is definitely a strong use case, IMO, for somehow > indicating that some hCard over there is a more detailed > version of this one. > > For example, at the various conference sites I am > involved wiht, we mark up all speakers using hCard. Ofen > it's simply > > http://johnfallsopp.com"; > class="url fn">John Allsopp > > Now, if this could point at an hCard with more > information about the speaker so marked up, to me that > would be potentially very useful for something like Tails > or Operator to pull in that additional information, or > for aggregating references to the same person and on. > > As to definitiveness or authoriativeness, I think that's > a tougher nut to crack. Thanks for the clarification. In reading the threads I didn't get the part about including a URL in an hCard to point to another hCard. That is helpful. OTOH I think (as you imply) this discussion might be attempting to use a pickaxe to resolve a problem that requires a bulldozer. Or said another way, trying to resolve a problem whose proper solution lies in a different domain. I've actually recently been thinking about a related question. i.e. what is a person's canonical URL? Google "Roy T. Fielding", "Bill Gates", "Linus Torvalds", or even "John Allsopp" or "Mike Schinkel" and tell me which URL is the canonical URL? I've been planning to blog about this for weeks. Do you, or anyone, have a proposed solution to this dillema? Basically the problem is simplified as "What URL identifies a person, and more importantly, how does someone who doesn't know that person or can't reach that person to ask be able to find it?" And, being an advocate for "Well Designed URLs", I do not think the right solution is to simply tag a random and undiscoverable and unmemorizable UID onto the end of a URL. But I'd have to understand the problem domain and use-cases to be better able to make an alternate proposal. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] "authoritative hCards", a simpler proposl
Hi all, Mike Schinkel wrote: Ryan King wrote: Catching up in the last few days, I find that there are some probelems with the "authoritative hcards" proposals. I' 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. In reviewing this I can't help but feel that I don't understand the use-case or the desired outcome. Will someone kindly explain? Is it that there could be hundreds of hCards on the web for Ryan King (the one for the guy who has the email address of [EMAIL PROTECTED]) but only one should be considered 'authoritative?" A number of somewhat overlapping suggestions seem to be floating around regarding this. There is definitely a strong use case, IMO, for somehow indicating that some hCard over there is a more detailed version of this one. For example, at the various conference sites I am involved wiht, we mark up all speakers using hCard. Ofen it's simply http://johnfallsopp.com"; class="url fn">John Allsopp Now, if this could point at an hCard with more information about the speaker so marked up, to me that would be potentially very useful for something like Tails or Operator to pull in that additional information, or for aggregating references to the same person and on. As to definitiveness or authoriativeness, I think that's a tougher nut to crack. j ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] "authoritative hCards", a simpler proposl
Ryan King wrote: > Catching up in the last few days, I find that there are some > probelems with the "authoritative hcards" proposals. I' > > > > 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. In reviewing this I can't help but feel that I don't understand the use-case or the desired outcome. Will someone kindly explain? Is it that there could be hundreds of hCards on the web for Ryan King (the one for the guy who has the email address of [EMAIL PROTECTED]) but only one should be considered 'authoritative?" Also, is the proposal is just throw some unique cruft onto the end of some URL for it to stake it's claim as the authoritative one? Sorry, but I've read the proposal and related emails several times and I'm still confused. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] "authoritative hCards", a simpler proposl
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:
http://factoryjoe.com/blog/hcard";>Chris
Messina
or blog link to Some Conference:
http://someconference.com/speakers/chrismessina";>Chris
Messina
or link from Some Conference:
http://factoryjoe.com/blog/hcard";>Chris
Messina
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:
http://factoryjoe.com/blog/hcard";>Chris
Messina
or
http://factoryjoe.com/blog/hcard";>Chris
Messina
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
Re: [uf-discuss] "authoritative hCards", a simpler proposl
On 2/8/07, Ryan King <[EMAIL PROTECTED]> wrote: I propose that this is a simpler solution which will work better. 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 Here's my January 24 problem (re)statement, rewritten with Ryan's proposal. (a) Start Source Page (e.g. http://microformats.org/) http://theryanking.com";>Ryan The "url uid" indicates that the consumer should dereference to "http://theryanking.com"; (Rule #2) (b) URL Page (http://theryanking.com): Ryan changes: http://theryanking.com/blog/contact/"; title="contact">contact To Contact http://theryanking.com/contact/#vcard";>Ryan King The "url uid" indicates that the consumer should dereference to "http://theryanking.com/contact/#vcard"; (Rule #2). Note: - we have to use a heuristic to join Step (a) & (b). I don't think this is avoidable (c) Authorative URL Page (http://theryanking.com/blog/contact/#vcard): http://theryanking.com";>Ryan King ... more stuff ... Rule #1 stops iteration (uid=http://theryanking.com, which is the uid from step (b)). --- This works pretty good. Two potential changes. Rule 1. if no uid or uid == the uid from _a_ previous iteration/recursion => you're done change _the_ -> _a_: no need to go around in circles Rule 0. if this is the first hCard you've seen, and there is a url but no uid, the consumer may dereference once + works with what's out there - asking consumers to do potentially unnecessary work Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] "authoritative hCards", a simpler proposl
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: http://factoryjoe.com/blog/hcard";>Chris Messina or blog link to Some Conference: http://someconference.com/speakers/chrismessina";>Chris Messina or link from Some Conference: http://factoryjoe.com/blog/hcard";>Chris Messina 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: http://factoryjoe.com/blog/hcard";>Chris Messina or http://factoryjoe.com/blog/hcard";>Chris Messina The self-referential nature of this link indicates that it is the 'authoritative' hCard. Have I understood you correctly, Ryan? 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? 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 FN+URL points to another URL which has information about the subject. Follow those URLs until you get to one which has FN+URL+UID. The latter is the 'authoritative' hCard RFC2426 defines the purpose of UID as "To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard" To my mind that fits better... Wreak havoc upon my suggestions at will Thanks Lachlan Hardy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] "authoritative hCards", a simpler proposl
I apologize for being semi-away for awhile. Catching up in the last few days, I find that there are some probelems with the "authoritative hcards" proposals. I've already spoken up a bit, but I want to delineate my perspective and outline in full my counter-proposal. First, the problems: Problem 1: Not tackling the simplest problem first. Before solving the problem of 'canonical' or 'authoritative' hCards, we should solve the problem of 'hcards representing the same person'. Before you can have trust you need identity. Problem 2: Not understanding the scope of XFN. XFN links apply to entire pages, not parts of pages. This means that using XFN links inside multiple hCards on the same page is not possible. Therefore, while using XFN's identity consolidation to consolidate hCards is useful (and can be used regardless of any other mechanisms), it is not sufficient, as it does not allow for the case of multiple hCards on a page, nor does it work for Organizations, only people. Problem 3: No analysis of prior art. Publishers have been using the UID property of hCard to signal "another hCard for this one". The hypothesis that's being tested is that using URL and UID on the same URL is sufficient for being able to connect hCards that represent the same entity. (As a sidenote, I find that documentation of this experiment is hard to come by.) Problem 4: Not reusing within the format in question. Reusing properties from other microformats is great and certainly a design goal. However, first we must look within a given format to see if there's a property that can solve our problem. Ok, enough of the negative stuff, on to a proposal. 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. Note that eventful.com is already using this. From http:// eventful.com/events/E0-001-002585347-7: Pacific Science Center 200 Second Ave. N Seattle, Washington 98109 United States 47.5839 -122.052 ... Notice that in the vcard for this location (within an hCalendar event), they link to the page for that venue (which contains another hCard for that venue). I propose that this is a simpler solution which will work better. 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 A similar algorithm could be used to find all related hCards in the network, but only if you have access to a database of backlinks. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
