All that glitters...

A quick word about SPARQL....

John sent me this link to an InfoWorld article that discusses the changes that will happen once the promise of the Semantic Web becomes reality.

First, congratulations to everyone who worked on SPARQL. I have gleaned some understanding over the last few years what it means to try to get agreement and drive ideas to a finished standards proposal... it's hard.

The title of this post sounds like I'm going to say bad things about SPARQL, but I'm not. SPARQL and the functionality that it will provide is very important and very valuable. I do think that it's important to put it in the context of the XDI and Higgins work that we are engaged in.

RDF and SPARQL will provide more available structured data that can be incorporated into the DataWeb. However SPARQL only addresses a small part of the problems that I talk about on this blog. For example, SPARQL doesn't have identification, authentication and authorization built into it's framework. I think this is a shame; we have seen time and again that building the capability for security into a protocol is far superior to 'bolting it on' or 'wrapping it around'.

SPARQL specifically leaves Update and Insert semantics as 'out-of-scope'. There are lots of use cases for which this is fine. However, there are also lots of use cases where you really need to push values back out.

So SPARQL is great... we will definitely build a standard plugin so that you can consume data available via SPARQL from XDI. We will probably even build a SPARQL query engine on top of our XDI engine so that any public data available from XDI can be accessed via SPARQL.

Open Source Brain

Up till now I have had exclusive access to Steven Churchill's brilliant and clear thinking as we have been working together closely for years. Now you all have limited access too... Steve is now blogging. Check out his first post on a Simple Identity Model.

I-Name news

Did you see this?

[Twitter] Joseph Smarr posted on Twitter
You can now log into Plaxo with an iName! I just attached =joseph.smarr. OpenIDDevCamp rocks, as do John Bradley and Michael Krelin! :)

It's great having John on the ooTao team... Thanks all of you!

Relationships are real

In my previous post I touched on the question of what is a Map. In our world, today, computers tend to make the distinction between the 'real world' and the representation of the world 'fuzzy'. 

If I have an interactive 'map' of my water system and I redirect the water flow from that map; which came first.... Is the physical system now simply a representation of the virtual model? Is it a physical 'memory' of the state that I changed on my computer or is it the other way round? If the 'map' and the state of the valves in the water system are 'out of synch' which is right? My intention was to redirect the flow, therefore the 'map' is right and the water is flowing wrong. I need to fix the valve so that it correctly represents the map... or do I?  

Conventionally one would assume that the map represents the physical state and that 'instructions' either successfully change the state or not. The map should be a representation of state not the authority for it. The software has the capability to 'poll' the physical networks state such that if the state changes the map can 'auto-correct' to current conditions. Depending on the completeness of the software we just have to hope that the physical network never gets into a state that it doesn't know how to represent. 

But here's the fuzziness again. If the valve has a processor and a network connection (which it would have to have to respond to instructions) it can also 'poll' the system for what it's current state should be and auto-correct. So at what point is the physical system just solid state memory?

Another example I have been thinking about is gerrymandering. Does that districting map dictate where people vote or does it represent where they vote?

This makes my head hurt!!

All of this is not JUST mental masturbation; I'm trying to work out what comes first a 'map' of the social graph that establishes our relationships and is 'portable' or is there some other manifestation of relationship that the social graph is a portable representation of.

Here's my conclusion...

Relationships are real. Directed relationship objects MUST be reified in the identity network. Maps of the social graph will show different aspects (attributes) of both types of top level entity; entities AND relationships. Like interactive maps of the physical world where you can layer utilities, streets, satellite pictures and geo-political attributes to communicate (makes portable) the state of a given physical area. The 'social graph' is a map that communicates (makes portable) the state of some entities and their relationships. 

An important quality of the 'portable social graph' is that each 'map' only represents a sub-section of reality.  I would expect different people might have access to different 'maps'. I would expose different sub-sets of my entity and relationships data to different 'mapping authorities'.

So this leads me to the conclusion that before we can really address social graph portability we need a better understanding of what relationships are.

In systems that I have built that have reified the relationship object I have found the following qualities necessary...

• Relationships are unidirectional and COMPLETELY controlled by the 'root' end of the arc. 
• Relationships are no different from any other 'claim' that I make about you, totally unsubstantiated. (good mapping authorities MIGHT only show reciprocated or verified relationship claims)
• Other people are ALWAYS interacting with one (or more) of my relationship objects NOT with my entity object.  (that's the point of reifying the relationship)
  
• Relationship objects contain several different types of data...

1. Data that I keep about you, that is mine, only mine and is never meant to be shared. Stuff like "this guy tells really bad jokes" or "it's not in his profile but I know his home phone number is XXX"
2. Pointers to the data about me that I want you to have access to. (in my world, it is the relationship object that dereferences the pointers NOT the 'other' entity).
3. Pointers to (and caches of) information that you have exposed to me about you (and sometimes others).

XFN or FOAF are ways for me to expose a sub-set of my entity and relationships to PUBLIC mapping authorities. They are but a map of something a LOT more complex that needs to be given a lot more attention. 

(of course xdi has all of this solved... if only you would all just use it :-) )