DeBabelizing the profile space
So now I have my work cut out for me. With PeopleAggregator aiming to be an IdentityHub, a place to normalize and move info and data between digital identities, and me being labeled the 'PA identity guy'. So here is my task for the near future. In simple term it can be called "build import/export capabilities for profile meta-data". With the concept of remote authetication like with SXIP, OpenID or whathaveyou also comes the notion of a remote profile. Now on the technical level the resulting user profiles are not actually 'remote', but we have to pull in any availeable external profile meta-data a user might have with the remote system she is using for login. And to allow for the openess and freeness of user data PeopleAggregator stands for, we need to ALSO build a way to write-back this info. Import/Export you can call it. Marc calls it the DeBabelizer of profile meta-data.
The real trick is that this data wants and needs to move between different systems and formats. So there is a normalization step required. Meta data coming in needs to be normalized and mapped to the internal schema. Anything not in the internal schema MUST be preserved and kept accessible/editable to the user. And for data going out (export), a similar process needs to be in place. We need to map from the internal schema to the 'format' we want to export to. And we need to account for things that have been preserved. Should the export format not know some fields, we can either drop them.... or maybe find a way to pass them along.
The system I will be designing and building needs to be one thing above all: flexible and adaptable. Given the very nature of the input and output 'formats' involved, we are talking moving targets here. Take for example the FOAF format. Anyone who has had any contact with reading FOAF descriptions will agree that there are very many way to say one and the same thing in a FOAF description. And then consider the actual mapping of ontologies. What is a 'login_name' for the one system, might have it's equivalent as 'alias' or 'nameFriendly' in the other. But is it always possible to find a straight mapping? In some cases we will need to rely on educated guessing, or plain brave descission. And here the system needs to be easily updateable. Corrections, based on better understanding at a later point. And let's not forget that format and specs change. Or their use does.
So enough talk. Let me show you a diagram that I made to clarify these relationships to myself.
I think key to making this system soar is not to solve all problems here and now. The key is to make it possible to save them when the info is availeable. That is what I mean by flexible. The system needs to be able to adapt at any given time. We can't possibly solve all problems now. some problems don't even exist yet. But we need to make sure we do not hardwire certain solutions that would make changing it later on difficult.
Ok, here some notes on that diagram, or rather how it was made. some of my readers might already have guessed it was made with Tinderbox. Note that I only use boxes, color and text. That is partly due to the way Tinderbox works. It is visual, but it is not a diagram package (like Visio etc). But I think you can still work it quite well in this role if you use what you have. Note also I refrained from using Tinderbox links to visualize relationships. Visualy TB links tend to not work for me, I tend very much towards spatial hypertext I guess. I express relations through spatial placing of notes and adornments.
This might not be the best architectural diagram, but it works very well for me. I do tend to have a problem understanding classical visual diagrams, so this might be a personal thing. I'd love to hear your comments about it though!
- thinking in tinderbox
- using Tinderbox notes for templates?
- Tinderbox: going from cloud to text
- encouraging passion
alles Bild, Text und Tonmaterial ist © Martin Spernau, Verwendung und Reproduktion erfordert die Zustimmung des Authors