Summary
For personal data services to really take off, they have to interoperate. Here are some use cases that illustrate what PDS interoperability means.
Last week in London, I attended a workshop Iain Henderson put on at Innovation Warehouse on Personal Data Store interoperability. He used the following illustrative use cases to talk about what interoperability means for a personal data service (PDS):
- As an individual, I want to be able to pick up my data from one personal data service (locker etc.) and drop it into another with minimal fuss
- As an individual, I want to be able to have applications run on my personal data, even when it exists in multiple different services
- As an individual, I want the apps I had running on my personal data in one locker service, to work when I move my data to another one
- As an application developer, I want the apps I build to run, with minimal overhead, across multiple personal data services
- As an organisation willing to receive and respond to VRM style data feeds; I don't want to have to set up different mechanisms for each different VRM provider
- As an organisation willing to provide/ return data to customers as part of our proposition to them; I want to be able to make this data available in the minimum number of ways that meet the users needs, not a different format for each personal data service provider
- As an organisation willing to provide/ return data to customers as part of our proposition to them; I don't want to have a different button/ connection mechanism for each personal data service provider on the 'customers signed in' page of my web site
These are worth striving for. Just having a place to put personal data isn't much use to me unless I can use it, move it, etc. As more and more companies become personal data service providers, they will do well to think through how they're planning for these. Kynetx is working on a project over the next 6 months to specifically address the developer side of this. Specifically, I think developers need two things:
- location independent references—applications will be easier to write if the developer doesn't have to know where the user's data is stored and the particulars of the API, authorization scheme, and so on.
- semantic data interchange—The developer shouldn't have to parse the semantics of each data services particular tags, field names, and so on. A simple example is "cell" vs. "mobile" in a contact data store.
The particular technology we're using to do this is XDI. We'll be experimenting with how an XDI server can be integrated with the Kinetic Rules Engine and how XRI references and XDI statements can be incorporated into KRL.