Re: [uf-discuss] Actual research regarding usage of rel-me, rel-contact, and friends. WAS: Social Networks that use XFN and Social Networks that use FOAF
What I interpreted from Chris' words was that contact and me was the only values _needed_ to achieve contact list portability. Not that the rest should be dropped altogether. I learned that from now on, I should always include the value contact, on top of all other values. XFN exists for more than just contact list portability... -- André Luís On Wed, Mar 19, 2008 at 11:02 AM, Costello, Roger L. [EMAIL PROTECTED] wrote: Awesome job Derrick! Thanks! /Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derrick Lyndon Pallas Sent: Wednesday, March 19, 2008 1:18 AM To: Microformats Discuss Subject: [uf-discuss] Actual research regarding usage of rel-me, rel-contact, and friends. WAS: Social Networks that use XFN and Social Networks that use FOAF Out of a sample of ~150k sites with some XFN, the following XFN rels are used, in order of frequency. (That is, one site gets one vote for an XFN rel used somewhere on the site.) me65.46% friend31.82% met20.81% colleague19.56% co-worker14.46% contact11.15% neighbor5.00% co-resident4.45% sweetheart3.72% sibling3.03% spouse2.85% muse2.79% parent2.25% crush1.86% kin1.83% date1.12% child1.12% acquaintance0.14% Out of a sample of ~15M pages with XFN, the following XFN rels are used, in order of frequency. (That is, one page gets one vote for an XFN rel used somewhere on the page.) me71.051% friend22.403% colleague13.929% met13.247% co-worker11.306% contact11.182% neighbor3.618% co-resident2.940% parent2.698% sweetheart2.094% muse1.707% spouse1.652% sibling1.398% crush1.073% kin0.942% acquaintance0.641% date0.612% child0.603% So, while a large number of sites that use XFN do have me somewhere, 35% don't. Furthermore, while the statement by Chris Messina[1] is corrent in asserting that me and contact are widely used, it is not based on solid research. The above data indicates that contact is not nearly as supreme as me, which is in a different league altogether. On the contrary, friend, met, colleague, and co-worker are at least as widely used as contact. The discrepancy appears to be bias towards the short head of the usage curve. Furthermore, I don't think anyone has really done a survey of non-English usage. I certainly haven't. Many of the sites that I've found that do use more than me are non-English, but certainly should not be discounted. Here is a random sampling of sites that do use XFN and the rels are used by each in the last six months and are in the long tail. ziki.comcolleague friend me met muse spouse topspeed.comcontact friend birdz.skfriend me neighbor pushhit.com met majoke.com co-worker friend met bloguje.cz child co-resident co-worker colleague contact crush date friend kin me met muse neighbor parent sibling spouse sweetheart 11870.com contact me inter.co.yu co-resident colleague contact friend me met neighbor finaltr.com friend muse tractorfan.nl colleague kin me botonturbo.com co-resident colleague contact friend me met tecnosquad.com acquaintance co-resident colleague contact friend me met giovani.it child date friend me met muse wolkanca.comco-resident co-worker contact crush date friend me met muse spouse sweetheart ~D [1] http://factoryjoe.com/blog/2008/03/11/portable-contact-lists-and-the-ca se-against-xfn/ Derrick Lyndon Pallas wrote: Costello, Roger L. wrote: Everyone, if you know of other social networks using XFN please let me know and I will add it to the list. Thanks I should be able to generate a more complete list of sites that use XFN --- including the types of relationships found on each --- some time tonight. ~D ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Proposal: Mandatory connection of a XFN to a source hCard and a target hCard
Hi Folks, Below is a proposal. The proposal is based on the following assertion. ASSERTION An expression of a relationship is useful only if you know who is the source and who is the target of the relationship. EXAMPLE ??? is friends with ??? is not useful. But Alice is friends with Bob is useful. ^ ^ ^ | | | | | | source relationship target ASSERTION, VERSION 2 XFN relationship information is useful only if an *application* (e.g. robot) can dynamically determine who is the source and who is the target of the relationship. PROBLEM WITH XFN TODAY Today, an XFN relationship can be expressed without any indication of who is the source and who is the target of the relationship. Typically, the information about who is the source is present on the web page containing the XFN. But that information can be *anywhere* and in *any form*. Thus, given an *arbitrary web page* containing XFN, it is not possible for a robot application to determine who is the source individual. Ditto for the target individual. At best, the source and target information is obtained with an extreme level of coding effort which is unlikely to be successful with all web pages (natural language processing is required). Note: The source is the person who created the web page that contains the XFN. That is not correct, as the following example illustrates. Besides, even if it were true (which it's not), a robot application would not know who created the web page. That information must be embedded within the web page. Ditto for the target. EXAMPLE Here's an example usage of XFN on a Flickr page: a href=/photos/[EMAIL PROTECTED]/ rel=contact img src=http://farm3.static.flickr.com/2146/buddyicons/[EMAIL PROTECTED] [EMAIL PROTECTED] alt=Jolene_A width=48 height=48 /br / Jolene_A /a Notice the use of XFN: rel=contact Also notice that there is no indication of who is stating this relationship or who is the target of this relationship, i.e. to a robot application this is what the XFN indicates ??? contact ??? which is meaningless. PROPOSAL 1. If XFN is used on a web page then that web page MUST contain an hCard of the person that represents the source of the relationship. Example: Consider a web page that uses XFN: a href=... rel=friend Suppose that the intended source individual is Alice, i.e. Alice is friends with xxx Then somewhere on the web page there MUST be an hCard for Alice, e.g. div id=vcard div class=fnAlice/div 2. There MUST be a mechanism that connects the XFN to the hCard that represents the source individual. Or, there MUST be a mechanism on the hCard that connects it to the XFN. 3. The target of the XFN-bearing hyperlink MUST contain an hCard that represents the target individual. And there MUST be some mechanism that connects the XFN to that target individual's hCard. Exception: if the XFN is me then the hCard MAY not be repeated in both the web page of the source and the web page of the target. OTHER REQUIREMENTS? Are there any other requirements? Note: I am focusing just on the requirements at the present time. I'd like to collect all of the requirements prior to thinking about how it would be expressed in HTML. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Mandatory connection of a XFN to a source hCard and a target hCard
On 19 Mar 2008, at 12:36, Costello, Roger L. wrote: Hi Folks, Below is a proposal. The proposal is based on the following assertion. ASSERTION An expression of a relationship is useful only if you know who is the source and who is the target of the relationship. I agree there are issues here, but I doubt you'll get very far trying to mandate things, especially if you're after changes at *both* ends of the hyperlink. On the Web, I don't want standards geeks (even my friends!) telling me just how much or how little I must say about myself in my own pages. Even if I don't say much about myself in http://danbri.org/ it is still my homepage, and people are free to point rel=friend links at it. There's value in connectivity, even without the extra profile fields. It could be used to identify common friends, RSS feeds etc. In other words, it's not place of microformats, or of FOAF or of W3C or of Web site owners to instruct folk on how much they have to say about themselves online. We simply provide vocabulary and formats and leave it to best practice and convention and users and toolmakers and publishers. As far as I understand the microformat approach, from talking with Tantek and others, it shares this characteristic with the FOAF/RDF design: very little is mandatory. Unlike some XML formats which are full of 'must' requirements, both microformats and FOAF/RDF live in a Webby world where 'missing isn't broken' and apps have to make sense of (and aggregate across) partial information. You should also btw note that rel=me is a special case, and in fact an exception to your main argument. For example I could reciprocally assert https://identoo.com/danbri/ xfn:me http://friendfeed.com/danbri . If this was in both pages, any self-description in the one page would apply to the other, reducing need for further duplication (whether in hcard or FOAF or whatever format). cheers, Dan -- http://danbri.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Mandatory connection of a XFN to a source hCard and a target hCard
1. If XFN is used on a web page then that web page MUST contain an hCard of the person that represents the source of the relationship. MUST is pretty abhorrent to me. I use rel=me on my blog, which is also my OpenID URI, which is a very strong way of my attaching my OpenID to my flickr, twitter, del.icio.us, pownce, etc profiles. One of the strengths of XFN over FOAF for me is that it separates the concern of expressing a relationship from that of providing contact details. 2. There MUST be a mechanism that connects the XFN to the hCard that represents the source individual. Or, there MUST be a mechanism on the hCard that connects it to the XFN. I don't see the value of the hCard in this scenario, a URI is a great way to identify someone: http://epeus.blogspot.com/2008/01/urls-are-people-too.html 3. The target of the XFN-bearing hyperlink MUST contain an hCard that represents the target individual. And there MUST be some mechanism that connects the XFN to that target individual's hCard. I can see valid use-cases where the URI being linked is sufficient. OTHER REQUIREMENTS? Are there any other requirements? Yeah, backwards compatibility with XFN as it stands now. Paul -- http://blog.whatfettle.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Proposal: Mandatory connection of a XFN to asource hCard and a target hCard
Thanks Dan. Excellent points. Okay, then let's revise it from Mandatory to Best Practice. The Best Practice may be simply stated as such: If you use XFN in your web page then it is Best Practice to incorporate an hCard in the web page which identifies the source of the relationship. At present there is no motivation for anyone to adopt this Best Practice and we've seen the consequence: few social networks provide a robot-readable way of determining the source individual of an XFN relationship. In those cases, XFN is providing no useful information. So the issue becomes one of enticement. How can we entice (motivate) people that use XFN in their web page to identify the source and target individuals? One way to motivate people is to provide a mechanism that: - connects the XFN to the hCard that represents the source of the relationship - connects the XFN to an hCard that represents the target of the relationship Another way is to create an XFN validator. This tool warns people: Please identify the source and target individuals. Other ideas? /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Mandatory connection of a XFN to a source hCard and a target hCard
On Mar 19, 2008, at 6:36 AM, Costello, Roger L. wrote: 1. If XFN is used on a web page then that web page MUST contain an hCard of the person that represents the source of the relationship. 2. There MUST be a mechanism that connects the XFN to the hCard that represents the source individual. Or, there MUST be a mechanism on the hCard that connects it to the XFN. 3. The target of the XFN-bearing hyperlink MUST contain an hCard that represents the target individual. And there MUST be some mechanism that connects the XFN to that target individual's hCard. Exception: if the XFN is me then the hCard MAY not be repeated in both the web page of the source and the web page of the target. I think this could all be simplified into a single rule. rel=me with an hCard at either end is a legitimate mechanism to connect all XFN relationships on both pages to the single hCard. I see no reason to create a rule that the hCard must be on the same page (#1), only to immediately create an exception to that rule. Putting the hCard on the same page is one way to connect it to the XFN relationships, but I see no reason to prefer it over the alternatives for accomplishing the same goal, e.g. linking to an hCard on another page with rel=me. If anything, I think the latter method should be preferred, following the DRY (Don't Repeat Yourself) principle. So that would leave us with #2 and #3, which are just discussing both ends of XFN relationships. So I'd boil this all down into one simple rule: 1. All people in an XFNetwork MUST be identified via hCard somewhere within the network. My MetaFilter contacts page, for example, needn't represent me via hCard, but could instead point back to my MetaFilter profile with rel=me, which could in turn point to the hCard on my personal website with rel=me. As long as my personal website hCard is within the XFNetwork (even though it may be multiple steps away), I shouldn't need additional (likely redundant) hCards for myself. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Proposal: Mandatory connection of a XFN to asource hCard and a target hCard
Thanks Paul. Excellent comments. I too am a big fan of separation of concerns. However, if there is no way for a robot application to determine in some automated way who is friends with xxx then the separation of concerns buys me nothing. a URI is a great way to identify someone: http://epeus.blogspot.com/2008/01/urls-are-people-too.html I'm afraid that URL doesn't do much for me in terms of understanding who that person is. Here's a URL that's in a Flickr page that uses XFN: /photos/[EMAIL PROTECTED]/ I think that you'll agree that URL's like this wouldn't be enough for a robot application to create a social graph like this: Alice is friends with Bob, who is a co-worker of Jim, who is neighbors with Alice. You make a very good point that we should not require hCard to be the mechanism for identifying the source individual or the target individual. The individual could be identified through a FOAF document or OpenID or some other (standard) means. Somehow there must be a mechanism for a robot application to consume an *arbitrary document* that contains XFN and be able to determine: - who is the source individual - who is the target individual Earlier I thought that perhaps the hCard for the source individual could connect/point to the XFN. But now you have helped me realize that the connection must come from the XFN: the XFN must connect/point to the hCard or FOAF or OpenID that describes the source individual. What do you think? /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Actual research regarding usage of rel-me, rel-contact, and friends. WAS: Social Networks that use XFN and Social Networks that use FOAF
André Luís wrote: What I interpreted from Chris' words was that contact and me was the only values _needed_ to achieve contact list portability. Not that the rest should be dropped altogether. There isn't really any other way to interpret what he wrote: If you use Google’s new Social Graph API http://code.google.com/apis/socialgraph/ and actually go looking for XFN data (for example, on Twitter or Flickr or others http://microformats.org/wiki/xfn-implementations), you’ll find that, by and large, the majority of XFN links on the web are using either |rel-contact| or |rel-me|. If you’re lucky, you might find some |rel-friend|s in there, but after rel-me and rel-contact, the use of the other 16 terms falls off considerably. Compound that fact with the minor semantic distinction between “contacts” and “friends” on different sites (sites like Dopplr dispense altogether with these terms, opting for “fellow travelers”) and you quickly begin to wonder if the “semantic richness” of XFN is really just “semantic deadweight”. And, in terms of evangelism and potential adoption, this is critical. If 16 of the 18 XFN terms are just cruft, how can we maintain our credibility [?] ... So, with that, I’m no longer going to both with advocating for the complete adoption of XFN. Instead, I’m going to advocate for supporting /Contact List Portability/ by implementing rel-me and rel-contact (a “subset” of XFN). The above, taken from his post --- though his blog software appears to be having issues right now --- says that 1.) He positively asserts that if YOU look at Twitter, Flickr, and a handful of other sites, you will see that they do use rel-me and rel-contact. 2.) He negatively asserts that you might find others XFN rels in the wild but probably not because they aren't used. 3.) Therefore, XFN sans rel-me and rel-contact is cruft and should be dropped in favor of just rel-me and rel-contact. Statement #1 is flawed because the corpus is not representative; it's a look at sites that were already known to use those formats. My numbers (taken from a current, large web corpus) indicate that #2 is false across the web-at-large. Therefore, I find it hard to support his conclusion. ~D ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Mandatory connection of a XFN to asource hCard and a target hCard
Hi Roger! I too am a big fan of separation of concerns. However, if there is no way for a robot application to determine in some automated way who is friends with xxx then the separation of concerns buys me nothing. So it might be nice if Flickr pointed to profile pages, which publish hCard identifying the links, e.g: a href=/photos/[EMAIL PROTECTED]/ rel=melarr; Photos/a I'm afraid that URL doesn't do much for me in terms of understanding who that person is. You know, I don't think link to a vcard is going to help here. Google's social graph search: http://socialgraph-resources.googlecode.com/svn/trunk/samples/findcontacts.html?q=http%3A%2F%2Fflickr.com%2Fphotos%2F24172116%40N08%2F tells me: Contacts you link to People who link to you as a contact to flickr.com/photos/[EMAIL PROTECTED]/ flickr.com/photos/fiveandlime/ contact flickr.com/photos/tantek/ contact flickr.com/photos/twatson/ contact Which is better, IMO, than it saying Keir, Tantek, Tom because ultimately whilst flickr.com/photos/tantek/ might claim to be Tantek, how I come to trust it's The Tantek is far more subtle and complex than any amount of metacrap in a hCard. Paul -- http://blog.whatfettle.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Proposal: Mandatory connection of a XFN to a source hCard and a target hCard
Costello, Roger L. wrote: But Alice is friends with Bob is useful. ^ ^ ^ | | | source relationship target I think that maybe Alice and Bob are plotting something. They keep sending all these encrypted e-mails to each other. Eve and I will get to the bottom of it eventually. Yes, with explicitly included hCards (or another way of specifying information about the people), XFN becomes a *lot* more useful, but I think there is probably still some minimal value in XFN even without this. (As others have pointed out, especially with rel=me.) For many purposes, it would certainly be useful to have a documented method for converting the physical XFN model of: [url1] friend [url2] to the logical XFN model of: [person1] friend [person2] However, I don't think requiring each URL to carry an hCard is necessarily the best way of doing that. It would certainly work, but it's a very blunt tool because: 1. The owners of url1 and url2 might not want to provide contact information. 2. url1 or url2 might be a non-HTML resource (e.g. PDFs, images, mailto:; URLs, etc. The solution I've been working on is that when an XFN relationship is found taking the form [url1] friend [url2], assume that it really means: [ Person: represented-by = url1 ] friend [ Person: represented-by = url2 ] Then use a whole variety of methods to learn as much as possible about the person represented by each URL. This might include looking for hCards on both pages, analysing FOAF files linked to from either, RDFa, etc. One particularly useful technique is to look for an hCard such that the uid property is url1, and look for another with a uid property of url2. After all this analysis, we may end up with a relationship like this: [ Person: name = Alice title = Webmistress org = Webby Inc blog = url1 represented-by = url1 ] friend [ Person: represented-by = url2 ] This shouldn't be seen as a failure -- just (perhaps) as less information than we wanted. Maybe in the future we'll be able to fill in Alice's phone number, or person2's name and e-mail address. Maybe we won't. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 1 day, 17:06.] The Semantic Web http://tobyinkster.co.uk/blog/2008/03/09/sw/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Proposal: Mandatory connection of a XFN to asource hCard and a target hCard
Hi Folks, My mind has really latched on to the term that Scott Reynen used in his last message: XFNetwork Nice! In a nutshell, what's needed is a way to connect the XFNetwork to an Identity Network. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Mandatory connection of a XFN to asource hCard and a target hCard
The address element is a valid and semantic way of claiming ownership/authorship of a document, I use it on my blog, and my accounts link to my blog claiming it's me. A url is a valid and important piece of someones identity, it's not ??? is friends with ??? it's http://x is friends with http://y; Costello, Roger L. wrote: Hi Folks, My mind has really latched on to the term that Scott Reynen used in his last message: XFNetwork Nice! In a nutshell, what's needed is a way to connect the XFNetwork to an Identity Network. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Mandatory connection of a XFN to a source hCard and a target hCard
Just as an example of where URLs are more than enough, here's a way you could use Googles Social Graph API. Bob signs up to new fangled social n etwork, he's prompted for a profile address to find if any of his friends are already on here. NewFangled asks Google for his relationships, G returns pages that he claims are his (his twitter, flickr pages etc) and urls of people on other networks (Eves twitter page, Alices flickr page). It turns out no one else is on NewFangled yet, but NewFangled stores the URLs that Bob lays a claim to, his flickr and twitter pages (stored as a hash!). Now Alice comes a long to NewFangled, and goes through the same process. Amongst her relationships google returns the url to Bobs flickr page, which happens to be stored in it's db and attached to Bobs NewFangled account. Now Alice can choose to make the same connection on the new site. Anyway that's how I see Googles API being used, all based on people identifying themselves by a URL or two. Costello, Roger L. wrote: Hi Folks, Below is a proposal. The proposal is based on the following assertion. ASSERTION An expression of a relationship is useful only if you know who is the source and who is the target of the relationship. EXAMPLE ??? is friends with ??? is not useful. But Alice is friends with Bob is useful. ^ ^ ^ | | | | | | source relationship target ASSERTION, VERSION 2 XFN relationship information is useful only if an *application* (e.g. robot) can dynamically determine who is the source and who is the target of the relationship. PROBLEM WITH XFN TODAY Today, an XFN relationship can be expressed without any indication of who is the source and who is the target of the relationship. Typically, the information about who is the source is present on the web page containing the XFN. But that information can be *anywhere* and in *any form*. Thus, given an *arbitrary web page* containing XFN, it is not possible for a robot application to determine who is the source individual. Ditto for the target individual. At best, the source and target information is obtained with an extreme level of coding effort which is unlikely to be successful with all web pages (natural language processing is required). Note: The source is the person who created the web page that contains the XFN. That is not correct, as the following example illustrates. Besides, even if it were true (which it's not), a robot application would not know who created the web page. That information must be embedded within the web page. Ditto for the target. EXAMPLE Here's an example usage of XFN on a Flickr page: a href=/photos/[EMAIL PROTECTED]/ rel=contact img src=http://farm3.static.flickr.com/2146/buddyicons/[EMAIL PROTECTED] [EMAIL PROTECTED] alt=Jolene_A width=48 height=48 /br / Jolene_A /a Notice the use of XFN: rel=contact Also notice that there is no indication of who is stating this relationship or who is the target of this relationship, i.e. to a robot application this is what the XFN indicates ??? contact ??? which is meaningless. PROPOSAL 1. If XFN is used on a web page then that web page MUST contain an hCard of the person that represents the source of the relationship. Example: Consider a web page that uses XFN: a href=... rel=friend Suppose that the intended source individual is Alice, i.e. Alice is friends with xxx Then somewhere on the web page there MUST be an hCard for Alice, e.g. div id=vcard div class=fnAlice/div 2. There MUST be a mechanism that connects the XFN to the hCard that represents the source individual. Or, there MUST be a mechanism on the hCard that connects it to the XFN. 3. The target of the XFN-bearing hyperlink MUST contain an hCard that represents the target individual. And there MUST be some mechanism that connects the XFN to that target individual's hCard. Exception: if the XFN is me then the hCard MAY not be repeated in both the web page of the source and the web page of the target. OTHER REQUIREMENTS? Are there any other requirements? Note: I am focusing just on the requirements at the present time. I'd like to collect all of the requirements prior to thinking about how it would be expressed in HTML. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Mandatory connection of a XFN to asource hCard and a target hCard
On Mar 19, 2008, at 10:02 AM, Costello, Roger L. wrote: 1. All people in an XFNetwork MUST be identified via hCard somewhere within the network. How about allowing the parties involved in an XFN-relationship be identified by either hCard or a FOAF document or an OpenID? (I must confess ignorance of OpenID. Is the id specified in its own document, like FOAF, or is it embedded within HTML?) I think it's good to keep it as flexible as possible for publishers. I didn't mean to suggest my support for MUST vs. SHOULD or something else. I was just trying to show that the subject of a given document is not necessarily identified directly in the document itself. But in all of the examples, it is identified directly in the document itself (see below), so my point there may not be particularly relevant. [Scenario] You are a robot. Your mission is to create a social graph using every XFN you can find. You've just arrived at a web page with this URL: http://www.flickr.com/photos/[EMAIL PROTECTED]/. As you parse the page you encounter a link containing XFN: a href=/photos/[EMAIL PROTECTED]/ rel=contact How do you determine the identity of the source and target of this relationship? Here's my thinking on this: The source and target of the relationship are the subjects of the documents at either end of the link. So I think the question is more simply: how do you determine which person is the subject of a document? I think h# headings are good for identifying a subject, and hCard is good for identifying people, so we could easily combine those two to determine which person is the subject. I'm further convinced this is a workable solution after looking at the sites mentioned that use XFN, which are for the most part already doing what I've described above (combining h# with hCard to indicate a person as a subject). Of the 6 sites mentioned that use XFN: - 5 use h# tags around the person who is the subject of the page (the other, Twitter, uses class=about vcard). - 4 (all but MetaFilter and Last.fm) use hCards. - 3 (Flickr, Magnolia, and Pownce) already combine the two to clearly indicate a person as a subject. So I'd say start the robot on those 3, encourage MetaFilter and Last.fm to add hCard, and encourage Twitter to use a heading (h#) intersecting with the existing hCard. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] rel-license: what does the license apply to? (open issue revisited)
I'm in the process of adding 'rel=license' in the relevant places on blip.tv, a video-sharing site, and I've run squarely into the 'open issue' raised by Evan on 2006-04-07 (in the wiki). Namely, there's no obvious way to specify that the license applies to a content element on a page - a picture, a video - rather than the page as a whole. About all I can think of is that a second rel value is needed, so you'd have something like: link rel=license href=http://creativecommons.org/licenses/by-nc-nd/2.0/; / link rel=licensed href=http://example.com/myvideo.flv; / link rel=licensed href=http://example.com/myvideo.mov; / The interpretation would be: If one or more hyperlinks with 'rel=licensed' are found, the items referenced are covered by the license (but the page as a whole is not). if no hyperlinks with 'rel=licensed' are found, the license refers to the page as a whole. This has the advantage of only complicating things a little ... but it also has the flaw that it can't deal with the case where you have multiple content items covered by different licenses on the same page (which is a not unlikely scenario). I seem to remember one of the microformats has a poorly-understood algorithm for determining the scope of a declaration; could this be reapplied here? Angus ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: rel-license: what does the license apply to? (open issue revisited)
Angus McIntyre wrote: I seem to remember one of the microformats has a poorly-understood algorithm for determining the scope of a declaration; could this be reapplied here? The problem lies deeper than rel-license. The rel attribute in (X) HTML is able to specify a specific element within a page as its target (using a fragment identifier), but doesn't offer the same granularity to specify its source. XHTML2 (and RDFa, which is basically a backport of XHTML2's metadata features to earlier versions of XHTML) solves this through its about attribute. One routes for rel-license to achieve the same trick might be to adopt eRDF, a formulation of competing RDF-in-HTML, which doesn't require adding any additional attributes or elements to the page. It co-opts the id attribute to indicate a container for metadata. So: div id=foo pSome content./p div id=bar pSome more content./p a rel=license href=licence.htmllicence/a /div /div Here some more content is licensed under the terms of licence.html. Unfortunately, my experience with implementing eRDF has been that is requires a great amount of thought from the very beginning of designing a page. id attributes are too commonly used in the wild to tack on this functionality -- you get unintentional narrowing of the scope of metadata. If a page is written with eRDF in mind from the start, it's just about usable. RDFa is much more pleasant to use. I added an example to the licensing-brainstorming a few days ago which goes some way to solving the problem and allowing authors to specify exactly what is under the licence. http://microformats.org/wiki/licensing- brainstorming#Creative_Commons_Vocab A key feature is that it uses rev=license to link from a licence summary to the licensed work, thus allowing the work to be targeted in more detail (e.g. fragment identifiers can be used), and deliberately flying under the radar of existing rel-license tools. -- Toby A Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-license: what does the license apply to? (open issue revisited)
Then how do you specify the license for different elements of the page? Perhaps making your video embeds an iframe that contains the embed/object and its own rel-license would be the best set of hoops to jump through. This is where RDFa starts to shine. I don't think there's a good way in microformats to set the subject of your triple (subject/predicate/object) to be anything other than the whole current page. In the wild people seem to publish conflicting information. For example Flickr use rel-license to say that my photo pages are CC licensed and then at the bottom of the page there's a separate Yahoo copyright message that is not marked up with microformats. Ian On Wed, Mar 19, 2008 at 8:32 PM, Angus McIntyre [EMAIL PROTECTED] wrote: I'm in the process of adding 'rel=license' in the relevant places on blip.tv, a video-sharing site, and I've run squarely into the 'open issue' raised by Evan on 2006-04-07 (in the wiki). Namely, there's no obvious way to specify that the license applies to a content element on a page - a picture, a video - rather than the page as a whole. About all I can think of is that a second rel value is needed, so you'd have something like: link rel=license href=http://creativecommons.org/licenses/by-nc-nd/2.0/; / link rel=licensed href=http://example.com/myvideo.flv; / link rel=licensed href=http://example.com/myvideo.mov; / The interpretation would be: If one or more hyperlinks with 'rel=licensed' are found, the items referenced are covered by the license (but the page as a whole is not). if no hyperlinks with 'rel=licensed' are found, the license refers to the page as a whole. This has the advantage of only complicating things a little ... but it also has the flaw that it can't deal with the case where you have multiple content items covered by different licenses on the same page (which is a not unlikely scenario). I seem to remember one of the microformats has a poorly-understood algorithm for determining the scope of a declaration; could this be reapplied here? Angus ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Ian McKellar http://ian.mckellar.org/ +1 415 867 9255 [EMAIL PROTECTED]: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-license: what does the license apply to? (open issue revisited)
Hey Angus, On Wed, Mar 19, 2008 at 8:32 PM, Angus McIntyre [EMAIL PROTECTED] wrote: I'm in the process of adding 'rel=license' in the relevant places on blip.tv, a video-sharing site, and I've run squarely into the 'open issue' raised by Evan on 2006-04-07 (in the wiki). Namely, there's no obvious way to specify that the license applies to a content element on a page - a picture, a video - rather than the page as a whole. (I should probably check this before posting... but I'm in a rush...) From what I remember of the HTML spec, an a element with the rel attribute set applies to all or part of the HTML page. An example of this is rel-bookmark used for hAtom. So... the rel-license could apply just to the video. From a machine point-of-view, there's no way (that I'm aware of) to differentiate when the rel-license applies to the whole page or part of the page. Suggestions welcome. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Has the cowpath for these XFN values faded away: friend, co-worker, muse, etc?
On Mar 18, 2008, at 9:18 AM, Costello, Roger L. wrote: Chris Messina wrote[1]: ... you'll find that, by and large, the majority of XFN links on the web are using either rel-contact or rel-me. I have been looking at various social networks for the last week, and Chris' statement is consistent with what I have seen - most web pages just use contact or me. This puzzles me. Microformats are about paving existing cowpaths. Historical note: XFN was created several years before the word microformats was coined, the microformats process was created, etc. I presume the authors of XFN saw a clear cowpath for not only contact and me, but for all the other XFN values, such as friend, co-worker, muse, etc. Has the cowpath for these later values disappeared, and thus are no longer needed? There's not a lot of value in taking other relationship types out of XFN. It'd make the spec smaller, but would lead to people who encounter those edges cases asking for re-inclusion. So, in a way, whether values besides 'contact' and 'me' are valuable, it doesn't matter that much at this point, there are more important things to work on. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A (big) problem with XFN: identity of source and target not findable
This is not a big problem, its mostly solved with [1] -ryan 1. http://microformats.org/wiki/representative-hcard On Mar 18, 2008, at 5:31 AM, Costello, Roger L. wrote: Hi Folks, Flickr uses XFN. Here is a sample Flickr page that uses XFN: http://www.flickr.com/people/tantek/ At the browser menu select View Page Source. Then search for rel= Here's an example usage of XFN within that Flickr page: a href=/photos/[EMAIL PROTECTED]/ rel=contact img src=http://farm3.static.flickr.com/2146/buddyicons/[EMAIL PROTECTED] 12 [EMAIL PROTECTED] alt=Jolene_A width=48 height=48 /br / Jolene_A /a Notice the use of XFN: rel=contact Metafilter also uses XFN. Here is a sample page that uses XFN: http://www.metafilter.com/usercontacts/292 Here's an example usage of XFN within that page: a href=/user/10411 rel=colleague target=_self40 Watt/a Notice the use of XFN: rel=colleague Now, suppose that I wanted to create a spider application which crawls all social networks that use XFN. Most likely, I would want the spider to collect: 1. Who is the source? That is, who is the individual using XFN to state a relationship? 2. What is the relationship? This is, of course, obtained easily from the value of the rel attribute on the link. 3. Who is the target? That is, who is the other individual in the relationship? Examine the above snippets of code. Does 1. and 3. pop out at you? That is, do you know who are the individuals that are the source and target of the relationship? That information can be found on the Flickr and Metafilter sites, but each site does it *differently*. So, the problem with XFN can be stated as this: While XFN does a great job of providing a set of relationship values (friend, contact, co-worker, etc), it provides no means for the automated discovery of the individuals that are the source and target of the relationship. Without information about the source and target individuals, the relationship information is not very useful. You might argue: Well, the XFN *should* be embedded within an hCard, then you can discover who the source individual is. And the target page should contain an hCard, then you can discover who the target individual is. And I agree that is Best Practice. Unfortunately, this is not mandated and consequently many people don't do it. For example, Flickr and Metafilter don't do it. Nor do any of the other social networks do it. Conversely, consider FOAF. Advogato is a social network that uses FOAF. Here an example FOAF on that network: http://www.advogato.org/person/connolly/foaf.rdf At the browser menu select View Page Source to see the actual FOAF document. Notice that the individual who is the source of the relationship is clearly listed at the top of the document: foaf:nameDan Connolly/foaf:name And the individual who is the target of the relationship is clearly identified: foaf:knows foaf:Person rdf:about=http://www.advogato.org/person/jtauber/foaf.rdf#me; foaf:nickjtauber/foaf:nick rdfs:seeAlso rdf:resource=http://www.advogato.org/person/jtauber/foaf.rdf/ /foaf:Person /foaf:knows The downside of FOAF is the only built-in relationship is knows, e.g. Dan Connolly knows James Tauber. That is, FOAF doesn't possess the richness of expression in terms of relationships. (I know, there are extensions of FOAF to express more than knows, but as far as I can tell, no social network is using those extensions) The upside of FOAF is that all three pieces of information are available to a spider application: 1. The source individual (e.g. Dan Connolly) 2. The relationship (knows) 3. The target individual (e.g. James Tauber) I don't see any solution to the problem with XFN. As far as I can see, social networks using XFN cannot be processed by spiders. Only social networks that use FOAF can be processed by spiders. Bummer. Hopefully, I am missing something. I really like the simplicity of XFN and its rich set of relationships. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: Mandatory connection of a XFN to a source hCard and a target hCard
Thom Shannon wrote: It turns out no one else is on NewFangled yet, but NewFangled stores the URLs that Bob lays a claim to, his flickr and twitter pages (stored as a hash!). What's the collision rate when hypothetical implementations are unnecessarily hashed? ~D ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A (big) problem with XFN: identity of source and target not findable
Wow. A spec just like Aphrodite, born fully an adult. On Wed, Mar 19, 2008 at 8:11 PM, Ryan King [EMAIL PROTECTED] wrote: This is not a big problem, its mostly solved with [1] -ryan 1. http://microformats.org/wiki/representative-hcard On Mar 18, 2008, at 5:31 AM, Costello, Roger L. wrote: Hi Folks, Flickr uses XFN. Here is a sample Flickr page that uses XFN: http://www.flickr.com/people/tantek/ At the browser menu select View Page Source. Then search for rel= Here's an example usage of XFN within that Flickr page: a href=/photos/[EMAIL PROTECTED]/ rel=contact img src=http://farm3.static.flickr.com/2146/buddyicons/[EMAIL PROTECTED] 12 [EMAIL PROTECTED] alt=Jolene_A width=48 height=48 /br / Jolene_A /a Notice the use of XFN: rel=contact Metafilter also uses XFN. Here is a sample page that uses XFN: http://www.metafilter.com/usercontacts/292 Here's an example usage of XFN within that page: a href=/user/10411 rel=colleague target=_self40 Watt/a Notice the use of XFN: rel=colleague Now, suppose that I wanted to create a spider application which crawls all social networks that use XFN. Most likely, I would want the spider to collect: 1. Who is the source? That is, who is the individual using XFN to state a relationship? 2. What is the relationship? This is, of course, obtained easily from the value of the rel attribute on the link. 3. Who is the target? That is, who is the other individual in the relationship? Examine the above snippets of code. Does 1. and 3. pop out at you? That is, do you know who are the individuals that are the source and target of the relationship? That information can be found on the Flickr and Metafilter sites, but each site does it *differently*. So, the problem with XFN can be stated as this: While XFN does a great job of providing a set of relationship values (friend, contact, co-worker, etc), it provides no means for the automated discovery of the individuals that are the source and target of the relationship. Without information about the source and target individuals, the relationship information is not very useful. You might argue: Well, the XFN *should* be embedded within an hCard, then you can discover who the source individual is. And the target page should contain an hCard, then you can discover who the target individual is. And I agree that is Best Practice. Unfortunately, this is not mandated and consequently many people don't do it. For example, Flickr and Metafilter don't do it. Nor do any of the other social networks do it. Conversely, consider FOAF. Advogato is a social network that uses FOAF. Here an example FOAF on that network: http://www.advogato.org/person/connolly/foaf.rdf At the browser menu select View Page Source to see the actual FOAF document. Notice that the individual who is the source of the relationship is clearly listed at the top of the document: foaf:nameDan Connolly/foaf:name And the individual who is the target of the relationship is clearly identified: foaf:knows foaf:Person rdf:about=http://www.advogato.org/person/jtauber/foaf.rdf#me; foaf:nickjtauber/foaf:nick rdfs:seeAlso rdf:resource=http://www.advogato.org/person/jtauber/foaf.rdf/ /foaf:Person /foaf:knows The downside of FOAF is the only built-in relationship is knows, e.g. Dan Connolly knows James Tauber. That is, FOAF doesn't possess the richness of expression in terms of relationships. (I know, there are extensions of FOAF to express more than knows, but as far as I can tell, no social network is using those extensions) The upside of FOAF is that all three pieces of information are available to a spider application: 1. The source individual (e.g. Dan Connolly) 2. The relationship (knows) 3. The target individual (e.g. James Tauber) I don't see any solution to the problem with XFN. As far as I can see, social networks using XFN cannot be processed by spiders. Only social networks that use FOAF can be processed by spiders. Bummer. Hopefully, I am missing something. I really like the simplicity of XFN and its rich set of relationships. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com
Re: [uf-discuss] rel-license: what does the license apply to? (open issue revisited)
Is the problem that the page contains multiple video elements? If so using hAtom to define them as separate entries may help clarify this, especially in conjunction with rel-enclosure. On Wed, Mar 19, 2008 at 4:40 PM, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hey Angus, On Wed, Mar 19, 2008 at 8:32 PM, Angus McIntyre [EMAIL PROTECTED] wrote: I'm in the process of adding 'rel=license' in the relevant places on blip.tv, a video-sharing site, and I've run squarely into the 'open issue' raised by Evan on 2006-04-07 (in the wiki). Namely, there's no obvious way to specify that the license applies to a content element on a page - a picture, a video - rather than the page as a whole. (I should probably check this before posting... but I'm in a rush...) From what I remember of the HTML spec, an a element with the rel attribute set applies to all or part of the HTML page. An example of this is rel-bookmark used for hAtom. So... the rel-license could apply just to the video. From a machine point-of-view, there's no way (that I'm aware of) to differentiate when the rel-license applies to the whole page or part of the page. Suggestions welcome. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Using microformats for automation of user input
Hello list, Is anybody aware of implementation or research on the topic of microformat usage for automation of user input? It is obvious that attaching microformat to said HTML form fields makes it possible for automation software to provide known values for them, without user interaction. This is particularly useful from the point of view of automatic service provisioning and application integration. However I was unable to find tracks of microformats usage for this purposes on the web... -- Kooper ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A (big) problem with XFN: identity of source and target not findable
David, Wow. A spec just like Aphrodite, born fully an adult. p class=pedantryI think you mean the goddess Athena ;-)/p john John Allsopp style master :: css editor :: http://westciv.com/style_master about me :: http://johnfallsopp.com Web Directions Conferences :: http://webdirections.org My Microformats book :: http://microformatique.com/book ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Using microformats for automation of user input
Hi Victor, Is anybody aware of implementation or research on the topic of microformat usage for automation of user input? It is obvious that attaching microformat to said HTML form fields makes it possible for automation software to provide known values for them, without user interaction. This is particularly useful from the point of view of automatic service provisioning and application integration. However I was unable to find tracks of microformats usage for this purposes on the web... It's long occurred to me that this would be of no small value, particularly in the context of devices where text input is more of a pain than standard keyboards - things with virtual keyboards, sms keyboards, and so on. There is in fact ECML http://xml.coverpages.org/ecml.html which has a degree of support in various browsers auto complete algorithms. Because common ecommerce form fields go beyond the vocabularies of hCard, hCalendar, and so on, I wonder what value there might be in considering the microformatization of ECML (yeah yeah, tat last sentence should probably be in the new mailing list ;-) Can't really determine how much traction ECML has got with publishers (Google might be able to tell us) HTH at least a little john -- Kooper ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss John Allsopp style master :: css editor :: http://westciv.com/style_master about me :: http://johnfallsopp.com Web Directions Conferences :: http://webdirections.org My Microformats book :: http://microformatique.com/book ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A (big) problem with XFN: identity of source and target not findable
On Wed, Mar 19, 2008 at 11:28 PM, John Allsopp [EMAIL PROTECTED] wrote: Wow. A spec just like Aphrodite, born fully an adult. p class=pedantryI think you mean the goddess Athena ;-)/p gonna have to take that westciv domain away if you're not careful :-) :-) http://en.wikipedia.org/wiki/Image:La_naissance_de_Vénus.jpg -cks -- Christopher St. John http://artofsystems.blogspot.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
