A “Personal API” could be a modularized, standardized interface for collaboration.

May 7th, 2009  Comments

I aggregated my blogs to discontinue this blog and create a single Taylor Davidson: Photography, Travel, Innovation and Entrepreneurship blog in May 2009; if you liked this post, click here for the options to follow the blog by RSS, Twitter and email and click here to follow me on Twitter.

Continuing the conceptual thinking around a “personal API”…

John Hagel, John Seely Brown, and Lang Davison, Defining Common Collaboration Tensions:

Loosely versus Tightly Coupled: One objection you might reasonably raise relative to the collaboration curve is the n-squared problem, in which the expense and effort required for participants to interact in a given environment rises exponentially with the number of participants. In a pull-based creation space, loose coupling provides a way around the n-squared problem by modularizing (and standardizing the interfaces between) resources so they can be flexibly combined and recombined. This sharply contrasts with more hardwired approaches in which the activities people do and the connections between them must be redefined each time the activity or connection changes. Said differently, loosely coupled collaboration scales; tightly coupled collaboration does not.

Sound like a “personal API”?

As I explained the concept of a personal API last month,

…when I talk about “personal APIs” I’m not only talking about accessing or receiving content, I’m also talking about delivering content and context to people; using the term API is a conceptual approach to thinking about how we can “scale” our time, thoughts and value stored inside ourselves to deliver more (quantity) and deeper (quality) interactions to other people; how can we reduce inter-personal transaction costs of interactions to deliver more value?

Right now my websites and my template financial model are the only “personal APIs” I have, but in their current unorganized, unpersonalized, untargeted and “noisy” state they are only a glimmer of a way to “scale me”.

Even worse, my efforts to create signals merely adds to the noise; the web of duplicative content aggregators and republishers hinders our collective ROI on attention and increases our collaboration transaction costs; by trying to help I’m helping make it worse.

Solving this paradox by moving the idea of a “personal API” from conceptual to actual is going to be fun…

—

(Thanks to Nicolas Gabard [@NicolasGabard] for the link.)

Post to Twitter Post to Delicious Post to Facebook

By Taylor Davidson. Posted May 7th, 2009. Category: Bridging Online and Offline Interactions   Comments

SIMILAR THOUGHTS

  • I was thinking about what a service that provides personal APIs would look like if not Facebook or a similar social app. Then I thought it would be a great way to provide social network sites data. It would allow the user to control their data, unfortunately only until the feed is picked up and stored. Some sort of control on the data allowing the owner to delete the data at a later time would be useful.
  • Thinking about the components, to make it happen would require an individual's data store, a set of common rules (the API) set by the marketplace, and a network and marketplace that aggregated the access and exchange rules.

    This could be stored at a social network site, but really work, it would need to outside the traditional silos and accessible from anywhere.

    Latest thinking on the topic: http://www.taylordavidson.com/writing/2009/11/1...
  • Chris Messina on personal profile APIs

    One consequence is that companies like Google, FriendFeed, Twitter, and Facebook are clambering over each other to meet this need, each providing convenient URLs for people to print on business cards and share with friends.........even [if] I’m not able to self-host my own identity and connect with these services, there is much work being done to establish APIs that at least allow services to connect with one another — affording roaming, multi-homing, data portability, and service substitutability.


    The Open Social Web
  • Yep, Chris has been leading a variety of efforts in this space for years, and he has been a great champion of data portability and service interoperability; but OpenID and other efforts are primarily about content and data portability; when I mention "personal APIs" I'm talking about interactions and exchanges of value; for example, knowledge rather than just data, multiple back-and-forth interactions rather than a single exchange of data.

    Actually, the stock photo portfolio on your site is a great example of how we can deliver, at scale, products; instead of someone having to ask you for a photo, they can just go to the site, search for keywords, and purchase the photo (print and license) without you ever being involved.

    That type of exchange is easy with information, it's more difficult with knowledge, and that's the opportunity. Still working out how to do it; the XLS business model available for download is a start, but I've thinking about ways to change that so that more of the trade-offs, judgments and analysis can be baked into the model for automatic exchange, rather than having to come from my head every time.

    ---

    One last note: I think you'd love to dig into VRM: http://blogs.law.harvard.edu/vrm/ and http://cyber.law.harvard.edu/projectvrm/Main_Page
  • The idea is solid, it's just going to take a while partly because we are still learning the strengths and weaknesses of the various platforms that are coming on-line. Each idea seems to improve a bit on the last in some particular way - causing splintering in general.

    So, sooner or later it will come together and then we'll get spammed. :)
  • I'm hopeful that the mass of incremental innovations will lead to something more substantial, whether that's a more substantial ecosystem or a more substantial single service is something we are seeing play out in the web in general at the moment.

    And yes, anything that can be spammed (and is worthwhile to spam) will be spammed :)
  • I think we are seeing some degree of your personal API concept being applied in various pockets of different industries.

    For service industries such as entertainment, legal, medical, education etc we are seeing innovative practitioners packaging professional information into knowledge for mass consumption. In edufire for example, lessons are recording in video for subsequent viewing and dissemination.

    The only thing missing is the ability for these knowledge to be easily recombined with something else. However in music, we are seeing signs of this. Independent bands are allowing their music to be remixed. This is one example of how personal API can work: Digitalise your knowledge or output and allowing them to be used in different ways and forms.
  • In a broader sense, it's about digitalizing knowledge and access in a modular, standardized interface for exchange, rather than just a database. Traditionally we sell access to ourselves by units of value called "time"; but time it merely a proxy for value. Selling access via an API would be closer to selling real value.
  • Agree that we're starting to see if; the automatic term sheet generator is an example in the legal industry; MIT Opencourseware in education; but yes, they are still based on the publication / subscription model of distributing and accessing content without the ability to truly remix it. I wonder if knowledge-based interactions could ever be remixed the same way as knowledge-based content.
blog comments powered by Disqus