Secure Collaboration and Intel's Reliance Point

Intel posted a blog article in mid February, about a research project that they call "Reliance Point". Based on the article, it appears that they are working on ways to selectively share data (addressing privacy and IP rights concerns), and provide integrity and isolation for that data. Intel refers to Reliance Point as a "trustworthy execution environment".

The environment is interesting in that it will bring together data from multiple providers, and allow the providers to perform calculations over the complete set. The providers have to agree on the algorithm that will be used to do the calculations and trust that the infrastructure will protect their data (and not allow other uses or algorithms to be executed, or the data to be revealed).

"Letting Data Breathe" is the name of the blog post. That title seems a bit exaggerated to me. For data to "breathe" (i.e., be integrated from multiple providers), there must be some standard set of semantics and structure that is supported by the providers, or there must a way to map between the syntax and (more importantly) the semantics of the different providers. Otherwise, what do calculations mean when run against data with unknown structure, and/or unknown and disparate semantics?

There is no mention of data integration in the article, just trustworthy data availability and negotiated algorithms. But, it seems to me that the project will not work if the problem of semantics is left to the data providers to solve out-of-band. In particular, how does one provider obtain the semantics of another's available data? How is this revealed while still protecting the IP rights of the provider? If proprietary data is shared, then it is likely proprietary all the way down to the layout and syntax of the data (perhaps defined by SQL). But, I have known companies that are reluctant to share even partial db structures since that information may reveal data or IP details.

To make Reliance Point work, something along the lines of OWL and RDF are needed - a way to specify semantics (OWL + SWRL/RIF, which I will discuss in another post) along with a way to handle multiple schemas (RDF). RDF defines a subject-predicate-object structure for data, which is very flexible. All databases can be translated into it. OWL and SWRL/RIF let you define equivalences, logical statements, disjointness and more, which are necessary to actually (semantically) integrate the data.

In theory, Reliance Point seems good, but Intel is working on the easier part of the problem (the infrastructure) and not the deeper problems that will prevent usage (integrating the data).

Andrea

Using the semantic web to fight fires

On Dec 10th, I watched a fascinating webcast from SemanticWeb.com ... "Fighting Fire with the Semantic Web". I won't repeat the content (you can watch the presentation for yourself), but I will provide some of my take-aways.

We all have environments with problems similar to the fire fighters in Amsterdam (except, hopefully, not quite so dangerous or life-threatening). When going to a fire, they have to:

• Navigate the city streets (understand what else is happening with respect to road congestion, construction, etc.)
• Assess the conditions of the building, fire and available/closest resources
• Get different data based on the situation - for example, the relevant data for a forest fire (wind speed) is quite different than data for a structural fire (asbestos levels)
  
• Determine the tasks to be done and in what order
• Work with incomplete data
  
• Use tools that are not targeted to their particular situations (such as commercial GPSs targeted for normal driver needs)
  

And do this all in real-time (or faster, if possible).

In the fire fighting environment, data comes from a variety of locations (emergency infrastructure databases owned by the police, construction road reports, geospatial databases, internal fire department databases and spreadsheets, ...). This all sounds similar to the daily problems that a IT or business person experiences.

So, what did the Amsterdam fire department do? They created a flexible infrastructure based on accessing raw (RDF) data (adopting Tim Berners-Lee's mantra, "raw data now"). They pre-loaded any data that was (relatively) static, and obtained other data in real-time as needed. All the information was accessed and assembled on the fly ... based on the URI of the information. (The URI was used by the back-end system to determine how the data should be displayed to the user.) The goal was to get away from specific applications with their own UIs, system and display requirements, etc. As was stated, "we already have 8 screens in the fire truck... we don't need 9".

Because the environment focused on raw data, in a generic form (RDF triples), any relevant information could be requested and displayed. Since the infrastructure based its processing on the URI, a user could definitely "follow their nose". Taking this one step further, meta-data could also be supplied with a URI and/or a piece of data, for UI/display purposes. (Interestingly enough, I was just working on UI-related meta-data for CA's Unified Service Model, stealing some great insights from our Mainframe 2.0 team. :-)

So, what were the technical lessons that were highlighted:

• Use of RDF triples allowed the data to evolve with no change to the interfaces (except to support radically new kinds of data and their display needs - which should be rare)
• Use of raw data meant that there were no interfaces (and custom coding) with "exclusive" ways to access to data
• Use of common tags allowed quick review of possible data and selection
• All interfaces were data-driven ... meaning that the data/URI defined how it should be displayed
• Use of RDF triples (and URIs) allowed a "follow your nose" approach to locating other, related data
• What was needed could be defined by the user based on their needs (for example, what they already knew) and the situation

How cool is that? And, don't you wish that you had this yesterday?

Andrea