Personal clouds need access to data. Lots of data. Data from all over. I envision my personal cloud as a general purpose computing platform that is always working for me. As such, it will need access to all sorts of data about me, my schedule, my to do list, and so on. Of course, it's not really the cloud that needs access to the data, but the programs running in it.

Let's return once again to the e-commerce scenario I set out in my blog post on Ways Not Places:

What if there were a protocol for e-commerce? What might happen? Let me paint a picture. A few months ago, I had six spare gorilla racks that I needed to unload. I went to a place--KSL Classified--and created a listing. Then their system took over and handled the interactions in some private, known-only-to-the-developer method completely within their site. Anyone who wanted to see if there were Gorilla Racks for sale had to go to their site. #FAIL

If there were a protocol for e-commerce, I could have merely listed the racks as unwanted in the inventory system on my personal cloud (stick with me here--protocols require different infrastructure than places). People looking for racks would broadcast their intent to purchase them. The protocol would connect anyone interested in buying storage racks to me and my cloud, allowing for much of the interaction to happen automatically. All in a distributed, decentralized manner. Where'd I get this cloud? From a cloud vendor who sells clouds that understand e-commerce, messaging, to-do, and other protocols, of course.

From Ways Not Places | Phil Windley's Technometria
Referenced Wed Mar 21 2012 14:35:00 GMT-0600 (MDT)

In this scenario, I only lightly touch on the role of data. Let's open it up a bit.

• First, I mention that there's some inventory of my stuff somewhere. This may seem farfetched at first, but why not? Amazon already gives me a list of all the books I've bought. Costco and REI know everything I've bought. Getting data about the things I buy and then having an automatically maintained inventory of my stuff probably isn't that far off.
• This scenario also would need to know how I accept payments. Paypal, Square and other services let me do that. Having that data available to the system wouldn't be hard.
• Personal data and contact information would also be needed as we moved toward consummating the sale.

How would the EXP service supporting my personal cloud know about all this data and have access to it? How could a developer write applications that have access to my data and your data even though we might be using different underlying systems for keeping personal data? How will the service know that things like "buy" and "purchase" are the same concept?

The answer to these questions is that we need a data abstraction layer. There are two important features that such an abstraction layer need:

• location-independent references - when a program needs access to the user's phone number, location-independent references abstract finding where that data is stored from the reference itself. So, for example, suppose you store your phone number in GMail contacts and I store mine at Personal.com. The application doesn't have to know that or how to connect to those various services. The program references a name that means "user's phone number" and the data abstraction layer takes care of the messy details.
• semantic data interchange - when the program wants the user's phone number and one system stores it as "cell" and another as "mobile" how do we know that's the same thing? For one or two things, it's easy enough to create these mappings ad hoc but that quickly gets old. The data abstraction layer makes these translations automatically.

I've wondered about these issues for a long time, but there's always been other, more urgent problems to solve. But we've reached a point in the development of KRL and EXP that solving the data abstraction problem is important. So we're going to spend some time this year integrating the OX XDI server into the EXP service provided by KRE. Here's a high-level picture of how that will look:

The Perl XDI library doesn't yet exist so we'll be writing that. But more importantly, we'll be integration XDI into KRL. The first thing we'll be doing is to support XDI references in KRL expressions. For example, the following (or something like it) ought to work:

pre {
  me = xri:+this+pen;
  phil_work = xri:=windley+tel+work$!1;
  my_work_date = xri:#{me}+tel+work$d!; 
  my_work = xri:#{foo(me)}+tel+work$!1;
  area_code = (xri:#{me}+tel+work!).extract(re/^\\d\\d\\d/);
}

I don't know that xri:+this+pen is correct, but what it is intended to convey is a way to find the current entity--the person that controls the personal event network running this application. KRL will need a way to make reference relative to the owner of the personal event network. Note that bee stings work and XRI references can be made in KRL expressions.

We also need ways of executing XDI statements. I view these as primitives that module writers would use to create more sophisticated interactions. For example the following would assert XDI statements against an XDI graph:

rule raw_xdi_2 {
  select when email received
  xdi:assert(
    [xri:=!1111+passport$!1+country/!/(data:,Canada),
     xri:=!1111+passport$!1+num/!/(data:,"987654321"),
     xri:=!1111+passport$!1+expires/!/(data:,2005-01-01T00:00:00Z),
     xri:=!1111+passport$!2+country/!/(data:,"New Zealand")
    ]);
}

XDI operations could be built into postlude statements for updating values:

rule updates {
  select when email received
  noop();
  always {
    set xri:=windley+tel+work!$1 "+1.206.555.1212";   
  }
}

This would be like the XDI statement:

=!1111+tel+work$!1/!/(data:,+1.206.555.1111)

All this is very preliminary and very likely to change, but it at least provides a flavor of what I'm thinking. KRL developers would need to understand XDI references (i.e. XRIs). XDI primitives would allow modules to be developed that hid most of the details of XDI statements and messages from programmers.