- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 23 Jun 2012 21:34:03 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: www-tag@w3.org
On 23 Jun 2012, at 21:22, Kingsley Idehen wrote: > On 6/22/12 5:01 PM, Henry Story wrote: >> On 22 Jun 2012, at 22:35, Kingsley Idehen wrote: >> >>> On 6/22/12 1:02 PM, Harry Halpin wrote: >>>> It seems like it would be better to use just mailto: (i.e., the original WebFinger design was around *email addresses*, not accounts per se) or a http: URI rather than mint a whole new scheme. >>> Here's why mailto: won't work. Most user agents will invoke an email client app. Remember, this is about using the URI as a name rather than data locator or access mechanism. That's the reason my acct: is required. Basically, follow-your-nose linked data traversal (with alternative URI resolvers hooked in via host-metadata pattern usage) without unintended consequences i.e., de-reference the next chunk of data etc... >>> >> Yes, though one wonders why they don't just put a URL in there: it could be >> >> http://google.com/.wellknown?id=joe@gmail.com > > Because, that's forcing the issue re. http: scheme URIs. Again, being an optimal solution isn't the basis for a futile mandate. > > Goal: URI based Linked Data. Basically, achieving Linked Data without http: scheme URI specificity. It can be done, and this is what the likes of Webfinger enable via acct: scheme URIs. But there is already a problem: should it be linked to an http or https URL? If it is only http, then there can be man in the middle attacks, changing information along the way. So that they soon will need an acctSec: scheme too. > > Give folks choice. We've already burnt years trying to force a RDF syntaxes on folks, now we are repeating the same thing with URIs. The conceptual framework of a system must always be distinct from implementation components. http: scheme URI, RDF syntaxes etc.. are components used to implement a specific system. Their cost-effectiveness is not the basis for eliminating alternative approaches. >> >> or whatever. All the accnt: url is is a short cut for something like the above, because inevitably the account URI has to be resolved in some way such as that. The confusion comes from not being able to distinguish between human readable names and uris. > > The issue is: human oriented natural keys (acct: scheme names) vs one synthetic (system generated) alternative (http: scheme names) that's natural to the host system, in this case the World Wide Web. accnt:joe@bblfish.net is not human understandable. It clearly comes from people who already know about URIs, markup, standards and such like. What people are going to pass to each other on post cards will be much simpler things like jon@smith.net The accnt thing is not simple enough, and it is not even secure. It requires people to adopt a pattern of publishing information on their web servers, which few other standards require. > >> >> <a href="http://google.com/.wellknown?id=joe@gmail.com">Joe@gmail.com</a> is the way we usually differentiate between human readable names and URLs. > > Why not? > > <a href="acct:joe@gmail.com">Joe</a> . who is writing this? My grandmother? Clearly not! Whoever can edit this knows about URLs and html and can therefore write the http:// version above, which requires a lot less conventions. Just point to the document you want to click on it, and see if it works. It functions in every existing browser, requires no updates to all the libraries to handle it, and is even much more natural to understand. > > The a user agent (where URI/URL scheme has been registered with an associated handler) performs de-refrence using: > http://google.com/.wellknown?id=joe@gmail.com . > > The denotation (name) and resource identification indirection is dealt with by the resolver registered with the user agent. The only problem with this is that it isn't as natural as using http: where browser style of user agents already know how to resolve. Net effect, the follow-your-nose pattern works more seamlessly since you don't need special handlers. > > >> The machine readable url is hidden from view of the user, and the human readable one is a string that the user can read. > > But in this case the "human friendly" aspect is more like a natural key in an RDBMS table. >> >> I don't think that user will find the "accnt:" string in front of their e-mail in any way intuitive. > > Users already find "joe@host" intuitive. That's the whole point. It implies: 'Joe' known to some host machine or user 'Joe' on some machine. > > Basically: ssh Joe@host means: get me on to said host as user 'Joe' . > > User 'Joe' doesn't think in terms of account 'Joe' instinctively. > >> And if they were asked to distinguish between that and an e-mail url it would get even more confusing. > > The only time email comes into play is if the mailto: scheme is used, then via follow-your-nose clicking on a URI (using a browser for instance) will result in email app. invocation. >> >> Furthermore the accnt uri then imposes a set of conventions such as .well-known on the web where web architecture tries to avoid such conventions as much as possible - essentially because there is no way to impose such conventions on the whole web. > > Yes it does. That's a cost, but costs are not the basis for invalidating an idea. The issue here is that we are trying to invalidate an approach purely on the basis of costs. Even though http: has its own set of costs as demonstrated by the Semantic Web Project odyssey and general struggles with Linked Data meme comprehension etc.. Basically, httpRange-14 imbroglio whenever the issue of real-world entity denotation combined with web resource identification comes into play. > > Imagine if all browsers adopted the host-meta patterns and stopped being http: scheme specific? At some point in time, this form of user agent will decouple from http: as a matter of survival re. trying to remain relevant. > > BTW -- in the mobile computing realm, URI scheme variety is natural and the net effect is more expansive and sophisticated use of the Web. > > Linked Data using non http: scheme URIs for denotation while still exploiting URLs for Web resource identification and actual data access: > > 1. http://linkeddata.uriburner.com/describe/?url=urn:lsid:ubio.org:namebank:12292 -- LSID (note what's in About: section of the page re. @href) > > 2. http://en.wikipedia.org/wiki/LSID -- about lsid: scheme URI from Wikipedia (again, this is costly, and http: scheme URIs are more natural to the Web) . > > Kingsley > >> >> >> Henry >> >>> -- >>> >>> Regards, >>> >>> Kingsley Idehen >>> Founder & CEO >>> OpenLink Software >>> Company Web: http://www.openlinksw.com >>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >>> Twitter/Identi.ca handle: @kidehen >>> Google+ Profile: https://plus.google.com/112399767740508618350/about >>> LinkedIn Profile: http://www.linkedin.com/in/kidehen >>> >>> >>> >>> >>> >> Social Web Architect >> http://bblfish.net/ >> >> >> >> > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > Social Web Architect http://bblfish.net/
Received on Saturday, 23 June 2012 19:34:38 UTC