Re: [uf-discuss] XFN for email addresses?
Chris Messina wrote: ... I created a simple XFN aggregating application, it occurs to me that adding email addresses, both for the purpose of rel-me links and for contact links is actually useful and something that should be supported in XFN (it's currently not clear whether this is acceptable or not; I'm making the case that it should be). Therefore, this: a href=mailto:[EMAIL PROTECTED] rel=contactBuddy/a should be as acceptable as this: a href=http://foo.com/buddy; rel=contactBuddy/a And, on http://foo.com/buddy, this should be permissible: a href=mailto:[EMAIL PROTECTED] rel=meBuddy/a Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. In principle it seems no worse to me than the aim: links currently recommended in the hCard spec. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On 6/12/07, John Panzer [EMAIL PROTECTED] wrote: Chris Messina wrote: ... I created a simple XFN aggregating application, it occurs to me that adding email addresses, both for the purpose of rel-me links and for contact links is actually useful and something that should be supported in XFN (it's currently not clear whether this is acceptable or not; I'm making the case that it should be). Therefore, this: a href=mailto:[EMAIL PROTECTED] rel=contactBuddy/a should be as acceptable as this: a href=http://foo.com/buddy; rel=contactBuddy/a And, on http://foo.com/buddy, this should be permissible: a href=mailto:[EMAIL PROTECTED] rel=meBuddy/a Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. In principle it seems no worse to me than the aim: links currently recommended in the hCard spec. Hmm, but both comments so far don't really say whether it's in-line with current thinking on XFN to allow for XFN linking to non-URLs. Given what you're saying, John, I should be able to also construct XFN links like this: a href=aim:goim?screenname=factoryjoe rel=meIM Me/a And as such, do the same for email addresses... right? This issue is fairly orthogonal to hcards, since you can have hcards without XFN. To date, my interpretation is that XFN links to resources not on the same page. It's not clear, in my thinking, whether those external resources can take the form of URLs, callto: or IM links. Chris -- Chris Messina Citizen Provocateur Open Source Advocate-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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On 6/13/07, Chris Messina [EMAIL PROTECTED] wrote: a href=mailto:[EMAIL PROTECTED] rel=meBuddy/a Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. In this case, I believe @rel=me requires a symmetric link to be valid. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
Chris Messina wrote: While I've resisted the temptation so far, it does seem that, in order to build a relevant and useful cross-social networking tool -- I need a way to use email addresses as well as URLs to identify people. In Therefore, this: a href=mailto:[EMAIL PROTECTED] rel=contactBuddy/a should be as acceptable as this: a href=http://foo.com/buddy; rel=contactBuddy/a And, on http://foo.com/buddy, this should be permissible: a href=mailto:[EMAIL PROTECTED] rel=meBuddy/a IMHO, XFN defines the relationship to that person, not what sort of link is being used. As the link type can be determined by looking at the URL I would imagine that any software would take that in to account if required. All you are doing with XFN is saying, for example, this link/email/im is my friend/muse/etc. Guy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On 6/13/07, Chris Messina [EMAIL PROTECTED] wrote: Hmm, but both comments so far don't really say whether it's in-line with current thinking on XFN to allow for XFN linking to non-URLs. a href=aim:goim?screenname=factoryjoe rel=meIM Me/a And as such, do the same for email addresses... right? --- i asked a similar question a year ago on IRC: http://rbach.priv.at/Microformats-IRC/2006-05-12#T033706 the answer (which i agree with) is yes. XFN defines the link the between two resouces, that is protocol agnostic. So http://, https://, mailto:, aim:, skype:, etc. I have been using this on my contact page for awhile. The rel-linter finds the just fine: http://tools.microformatic.com/help/xhtml/rel-lint/ -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On Jun 12, 2007, at 8:15 PM, Chris Messina wrote: Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. And this is a quite large issue. It effectively removes the N in XFN. It's hard to build a network where some nodes can only by sinks[1]. -ryan 1. http://en.wikipedia.org/wiki/Degree_(graph_theory)#Sink ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On 6/13/07, Ryan King [EMAIL PROTECTED] wrote: On Jun 12, 2007, at 8:15 PM, Chris Messina wrote: Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. And this is a quite large issue. It effectively removes the N in XFN. It's hard to build a network where some nodes can only by sinks[1]. -ryan 1. http://en.wikipedia.org/wiki/Degree_(graph_theory)#Sink [Trying again] And while that is a valid concern to be noted, I don't think that it precludes using non-URL based indicators as person identifiers. I mean, I'm a huge proponent of OpenID and URLs for identity; at the same time, that vision doesn't match with reality and I don't think it's going to change immediately; therefore, XFN should not be able to deal with the established convention even while things are (hopefully) moving in the direction of URL-based identifiers. In any case, consider mailing list subscriptions -- the fact that a message is sent to the identifier (aka your email address) and you respond by clicking a confirmation link proving that you can receive messages sent to that email address is no different than Technorati's current Javascript-based URL-claiming mechanism, whereby, instead of clicking a link, you insert a script that Technorati expects to find at the destination URL. The same argument can be made for IM links, since a bot could ping you and ask you for some data that only you would know, and if you're able to respond accurately, then you've similarly proven ownership of that destination. Chris -- Chris Messina Citizen Provocateur Open Source Advocate-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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On Jun 13, 2007, at 4:25 PM, Chris Messina wrote: On 6/13/07, Ryan King [EMAIL PROTECTED] wrote: On Jun 12, 2007, at 8:15 PM, Chris Messina wrote: Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. And this is a quite large issue. It effectively removes the N in XFN. It's hard to build a network where some nodes can only by sinks[1]. -ryan 1. http://en.wikipedia.org/wiki/Degree_(graph_theory)#Sink [Trying again] And while that is a valid concern to be noted, I don't think that it precludes using non-URL based indicators as person identifiers. Just be clear, I believe that by non-URL you mean non-HTTP-URL. I mean, I'm a huge proponent of OpenID and URLs for identity; at the same time, that vision doesn't match with reality and I don't think it's going to change immediately; therefore, XFN should not be able to deal with the established convention even while things are (hopefully) moving in the direction of URL-based identifiers. In any case, consider mailing list subscriptions -- the fact that a message is sent to the identifier (aka your email address) and you respond by clicking a confirmation link proving that you can receive messages sent to that email address is no different than Technorati's current Javascript-based URL-claiming mechanism, whereby, instead of clicking a link, you insert a script that Technorati expects to find at the destination URL. The same argument can be made for IM links, since a bot could ping you and ask you for some data that only you would know, and if you're able to respond accurately, then you've similarly proven ownership of that destination. Actually they are different in an important way. The code we give people to put on their blogs includes rel=me and when blog claims are successfully completed, we link back to the blog with rel=me [1]. So, these assertions are public and can be indexed by anyone. To step back a bit, I see nothing wrong with trying to use email addresses to connect people's identities. It seems to be a cowpath that's already paved. However, I don't think it fits very cleanly into XFN. For example, you can do: a rel=met href=mailto:[EMAIL PROTECTED]ryan king/a Which is a clear, unambigious assertion, there's no way to connect the URL mailto:[EMAIL PROTECTED] to the rest of the XFN network via identity reconciliation and without that, we lack a lot of utility. Of course, I don't really have a better suggestion right now. :) But I think we can find a better way to do this. -ryan 1. We know this doesn't work for multi-author blogs, we're working around that. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] XFN for email addresses?
While I've resisted the temptation so far, it does seem that, in order to build a relevant and useful cross-social networking tool -- I need a way to use email addresses as well as URLs to identify people. In particular, you'll notice that most social networks currently (and unfortunately) ask you to login to your webmail accounts (Gmail, Yahoo, Hotmail, etc) to discover whether your contacts are already on the site and if not, to invite them via email. Clearly without a widespread way to message people via their URLs, this is the only reliable method to invite people to join whatever the latest social network is. I'm not here to critique the behavior but instead to recognize what the market currently accepts and treats as acceptable. I created a simple XFN aggregating application, it occurs to me that adding email addresses, both for the purpose of rel-me links and for contact links is actually useful and something that should be supported in XFN (it's currently not clear whether this is acceptable or not; I'm making the case that it should be). Therefore, this: a href=mailto:[EMAIL PROTECTED] rel=contactBuddy/a should be as acceptable as this: a href=http://foo.com/buddy; rel=contactBuddy/a And, on http://foo.com/buddy, this should be permissible: a href=mailto:[EMAIL PROTECTED] rel=meBuddy/a Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. Thoughts are welcome. Chris -- Chris Messina Citizen Provocateur Open Source Advocate-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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
Hello Chris, Going off on sort of a separate tangent... have considered combining hCards with XFN? hCards let you mark all sorts of contact info... including e-mails. While XFN lets you show relations between people. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ All the Vlogging News on One Page http://vlograzor.com/ On 6/12/07, Chris Messina [EMAIL PROTECTED] wrote: While I've resisted the temptation so far, it does seem that, in order to build a relevant and useful cross-social networking tool -- I need a way to use email addresses as well as URLs to identify people. In particular, you'll notice that most social networks currently (and unfortunately) ask you to login to your webmail accounts (Gmail, Yahoo, Hotmail, etc) to discover whether your contacts are already on the site and if not, to invite them via email. Clearly without a widespread way to message people via their URLs, this is the only reliable method to invite people to join whatever the latest social network is. I'm not here to critique the behavior but instead to recognize what the market currently accepts and treats as acceptable. I created a simple XFN aggregating application, it occurs to me that adding email addresses, both for the purpose of rel-me links and for contact links is actually useful and something that should be supported in XFN (it's currently not clear whether this is acceptable or not; I'm making the case that it should be). Therefore, this: a href=mailto:[EMAIL PROTECTED] rel=contactBuddy/a should be as acceptable as this: a href=http://foo.com/buddy; rel=contactBuddy/a And, on http://foo.com/buddy, this should be permissible: a href=mailto:[EMAIL PROTECTED] rel=meBuddy/a Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. Thoughts are welcome. Chris -- Chris Messina Citizen Provocateur Open Source Advocate-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 ___ 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
