How do we publish from our personal data stores? Save the restful web.
Session topic: How do we publish from our Personal Data Stores? Save the RESTful web! (W2G)
Convener: Steve Williams
Notes-taker(s): Steve Williams & Scotty Logan
Tags for the session - technology discussed/ideas considered:
Personal Data Store, Privacy, Unhosted, REST
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Audio and whiteboard snapshots: http://sbw.org/iiwxii
Videos Posted:
- Part one (almost 9 mins): http://www.chachanga.com/nfb/c.php?c=_1304530699630
- Part two (about 21 mins): http://www.chachanga.com/nfb/c.php?c=_1304531262037
- Part three (another 21 mins): http://www.chachanga.com/nfb/c.php?c=_1304532591991
The Personal Data Store is a positive development for user control and privacy. However, the common understanding of web application architecture is that application service providers will have authorized access to the Personal Data Store, so people still are not completely independent of application providers.
In a the nascent application architecture @unhosted (http://www.unhosted.org/), the application provider serves Javascript to the person's web browser, and all access to the Personal Data Store is from that browser. That is, there is no need and no way for the application provider to know the identity of the person or the location of her Personal Data Store.
Steve believes the Unhosted architecture is a further step forward in user control and privacy, but he is concerned that Unhosted does not provide for publishing information from the Personal Data Store as RESTful, semantic web documents for consumption by anonymous visitors, robots, and other agents that cannot feasibly run the application's Javascript and, in any case, have no way to obtain authorization to access the Personal Data Store.
Steve asked whether this issue is being discussed and asked the attendees for ideas on how such published documents can be created, when the authoring is done in an Unhosted application.
There were several good suggestions. Steve suggested (but is not completely comfortable with) the application provider serving code that would run on the person's server, under Caja or suchlike.
Phil Windley suggested that the publishing of the RESTful documents would be triggered by events raised by agents. We didn't pursue that idea adequately.
Scotty Logan suggested that the application would include Javascript that runs in the web browser to render the RESTful document and publish it to the person's designated web server.
Scotty also suggested that the application provider would provide Javascript to be stored in the Personal Data Store, and the Personal Data Store provider would provide an "admin console" that would run that Javascript to publish updates to the RESTful documents.
An attendee observed that the above ideas do not address use cases where passive events that should trigger updates of the RESTful documents, because no web browser is involved in such events. For example, when the person's location changes, her phone might push the new location to the Personal Data Store. That should update the map on the person's home page, but no web browser is involved in the update, so there's no opportunity for the application or the Personal Data Store admin console to get involved.
We did not solve that issue. Further discussion is needed.
