Secure Distributed Open
Social
Networks

Henry Story

Senior Staff Engineer

Semantic Web Evangelist

http://blogs.sun.com/bblfish

Sun Microsystem

photo by prakharevich

Hello, my name is Henry Story. I work for Sun Microsystems where I research on the Semantic Web. I am tasked with finding ways to get people excited about what is happening in this space, which at first may seem very abstract. So I have been looking for problems that would affect people directly, have some real immediate business value, clearly demonstrate the power of the semantic web, and that is small enough that I don't need a big budget to get things done. After all I am in the business of convincing people. Once they are convinced I hope they will help out one way or another.

Social Networking is big. It affects everyone in very personal ways. It is useful. It is what we are all about. Here I wish to show how one can build an secure, open, distributed global social network with no center of control. The only way to do this is using the semantic web....

Overview

Description of the Social Networking problem

Why this is no longer somebody else's problem: a hyper address book

The functioning of the Address Book

How to add distributed decentralized security

A final thought: how this changes the desktop paradigm

So the first thing I will do is explain what the Social Networking problem currently is. It may not seem obvious to everyone that there is a problem yet, especially to those that have just started joining the social networking fun. But anyone with a bit of experience will have encountered these problems themselves.

Well finding limitations to what is being done is easy you might say. There are limitations to any technology. If one can't do it, then one might as well not waste time thinking about it. Surely if it had been possible someone would have done it by now? This is what is known as SEP, or somebody else's problem, as explained by Arthur Dent in the hitch hiker's guide to the galaxy. It can make anything invisible. I will therefore demonstrate an Address Book that looks very much like a well known piece of software, and that you can use now to create and explore an existing and growing distributed open social network.

Having got you interested, you will want to know how it works. How can such a thing to what it is doing? This will constitute a quick introduction to the Semantic Web and hyperdata.

Then I will show a couple of ideas on how one can add fine grained security to the network, which all the current social networks provide.

And finally I will leave you with a thought on how this can be used to change the whole of your computing environment.

Too many Social Networks?

...are there too many web servers?

There are many, many social networks. Here is a picture of a small selection I found on the internet. You will notice

FaceBook

LinkedIn

Flickr

Skype

Blogger

just to name a few of the most famous. Every application is turning into a social application. Are there too many?

Are there too many web servers? Are there too many web sites?

I don't think so.

The Problem: data silos

SN don't link up:

Information can't be moved easily
(see: Data Portability the video)

Users have to create and maintain accounts on each SN they have friends on, or loose contacts

Growing number of social networks (SN)

because there are a lot of $$$ to be made

because there are many needs

there will never be one SN to rule them all.

But in practice, the way things are set up now, there are too many:

This becomes evident as soon as you have more than a couple of accounts. At that point you have to start keeping you information up to date on each of these different sites. See the linked data portability video to get a sense of how annoying that can become.

Why would you want more than one account then? Well for one all your friends are not going to be on the same social network. The world is just too big for such a convergence to happen, and we have friends in way too many places usually for us to hope that they all end up in the same place.

So why not just wait for a monopoly to emerge? Then all will be settled right? No. First, Monopolies are bad, especially in this space. Secondly, as there is so much money to be made in this space by helping people link up and advertisers link up to people there is going to continue to be a huge growth in this space. There will never be one network to rule them all, not if that network at least is not like the web: distributed, open, secure with no central point of control.

Scoble gets thrown off Facebook!

In early January 2008 Scoble, the developer who got blogging going at Microsoft, got thrown off Facebook for extracting information too agressively from his social network on Facebook.

This is the Facebook who asked users for their gmail password to extract all their contacts from their email!

see his video

These problems are not hypothetical at all. As companies compete to get larger shares of the market they are becoming more and more protective of their data. This is causing some real problems, witness the story of Scoble who got thrown off Facebook in January for wanting to extract his social graph into his own software. Scoble, for those who don't know, became famous for getting blogging going at Microsoft. I know other cases of people who got thrown off facebook, for searching their data a little too heavily.

Who does your data belong to?

An (evolving) Social Graph

relates many different things

people to information about them

name

address

phone number

relations between people:

who knows who

who worked with who

relations with external things

blogs

companies

Let us quickly clarify one term I just used: Social Graph.

A social graph is all the relations between you and the people you know and other information about them. You can think of every type of relation between these things as a specific types of arrow. Here for example I have drawn a social graph which shows me related to David and Adam by the knows relation drawn in blue. It also shows that Adam knows Abel, etc.

A different type of relation is that between me and the place I live, which itself has the country relation to France, and so on. I also have a workplace home page relation to http://sun.com which David who also works at Sun also has.

In fact all of knowledge can be described as a graph of relations this way. But the notion of a social graph has recently gained wide acceptance.

Two social Networks

how can Tim and Henry link up ?

Let us consider the following two social networks. Each of them has their own social graph. On the left in green is Tim's social network, on the right in yellow is Henry's social network. Henry has a funny colored hat.

Let us imagine that I know Tim, and that he knows me. How can we link up across these social graphs?

Solution 1: minimal nave approach

but within each SN queries are very limited:e.g.: in Network A, nobody can query for Tim's address

Well a nave approach would be to just add the information to each social network. The green social network to the left has to add an entry for Henry, and a relation from Tim to Henry. The yellow social network to the right has to add an entry for Tim, and a relation from Henry to Tim.

Having added that information to each social network, users of these networks can now make simple queries, such as, for the green network who does Tim know? The database could then answer: Jessy and Henry. That is nice. But more advanced queries, such as Does Tim know anyone who lives in France? would not be able to return any results. That is because that information is not available to the network to the left. It is in the network to the right.

Solution 2: copy some information

how to copy the data? Data Portability? (DRY principle?)

how to keep the relations up to date?! Twice as much work.

queries still limited: what are the friends of Tim's friends?

Well perhaps one could just copy some of the information over. Let us copy not just the information about Tim and Henry, but also the information about where they live. The green social Network now has information about where Henry lives, and the yellow social network has information about where Tim lives.

Now of course it is possible for a user of either Social Networks to ask: does Tim know anyone living in France? And the answer would be yes, he knows Henry.

But what if that user wanted to ask a slightly more complicated question such as: please give me a list of all the Friends of Tim's Friends? Clearly the answer given will be a very partial answer. Asked in the green social network it will leave out Henry and David because that information is only available in the yellow graph. Asked in the yellow network it will leave out Jessy, as that information is only available in the green graph.

Furthermore there is a problem of duplication of information. Each network now has a copy of information from the other one. Which is authoritative? How do they get synchronized? Also how does the data get copied in the first place?

Solution 3: copy all

technically impossible: does not scale as networks grow in size and number:

how to keep information up to date?

amount of synchronization grows exponentially

politically impossible: S.N. are very protective of their data + privacy issues + oligopoly issues

To answer the more complicated queries, the only solution would in the end be to copy all the information from the SN to the right to the SN to the left. This would be to fuse the information from both networks.

But that is technically impossible in real life. How would one keep information up to date? As more networks need to synchronize and as more people participate in these networks the amount of synchronization is going to grow catastrophically.

Furthermore it is politically impossible. Social networks are very protective of their data, there are privacy issues, and there are oligopoly issues. Because for different social networks to trust each other enough to allow each other to look at their data, they would have to be so close as to not be competing properly.

The pull to one network

Due to Metcalf's law: the larger the network the more valuable it becomes.

But why does it have to be in one database? Because each database has its own LOCAL POINTER mechanism, just like every Java virtual Machine has a local pointer mechanism. You cannot easily point from one JVM/DB into another.

What if we had one big world wide database? we would need universal names for things. URIs?

Clearly there seems to be a strong pull to one network. The larger the network is, the better the queries can be in that network. This is known as the Network effect, or Metcalf's Law. The value of the network grows exponentially with the number of nodes in the network. It grows faster here because there are many different types of relations.

But why does all the information have to end up in one database? This is explained in part because each database has its own local address space. Just like every Java Virtual Machine has a local pointer mechanism, and it is very difficult to point to objects existing in different VMs.

If we had global pointers, then databases could point into other databases, and would only have to refer to information located there. There would be no need to copy all the information at all, or only when needed.

Global Identifiers do in fact exists and have been working very well for us: they are called Universal Resource Locators: URLs for short. It is what the web is built on. When you go to one web site it does not copy all the pages it is referring to. It just points to them.

The Solution: linking across social networks

requires a global namespace

So the simple solution, drawn out here, is just to linking from the person in one social network to the person in the other social network. Here the data remains where it should on the respective servers where it is maintained. No need to copy the data. Just point to it.

This just requires every object to be identifies with a URL.

The Solution: a closer look

objects and documents have URLs

Relations also have URLs: foaf:knows, foaf:name

The Self Describing Web

Let us look at this more closely.

Every object (known as a resource) has a URL: - the documents in which the information is located have URLs (here we have tim.rdf in blue, and henry/card in yellow) - the two people have URLs. My URL is bblfish.net/people/henry/card#me - relations have URLs too, here we have the foaf:knows and the foaf:name relation.

A nice side effect is that if you do not know what a object or relation refer to, you can just click on it. Try clicking on the foaf:knows or foaf:name relation for example.

This is knows as the self describing web.

A hyperdata Address Book

So to make clear that this is not just pie in the sky theory, I build a semantic web address book, which I will demonstrate now. It is open source, written in Java and available on the site shown here. Click on the picture and it will run in Java Web Start.

You will then see the following

1. first launch of jnlp

... namely an empty address book. It could be better by the way, it could search your Operating System Address Book, or you search your mail box and fill things out. If you are a good Java Programmer, I'd love you to help out. But for the moment it just is empty.

Drag and drop a foaf file you can just take drag the smiley face icon you find on the Address Book home page onto the first column. The URL you will be dragging is in this case

http://bblfish.net/people/henry/card#me

but it need not be. Other foaf urls will do just as well.

Ah, I'd better explain what I mean by a foaf url. Well it's just a normal URL that points to a friend of a friend document. You'll find out more about that as you go along.

2. drag and drop a foaf file url

the Address book will fetch the information at that URL and show you the primary topic of that foaf file in the top of the first column. You will see Henry Story appear there. Nothing very interesting yet.

3. click on the first name in the first column

Click on that first row of the first column and you will see a list of some of the people I know. You will also see more information about me in the right pane, including my home address, telephone number, home page, and so on... I am very public about all that information. I reckon that there is not much point protecting it, as it won't help on iota, given the state of virus infection of so many computers in the world...

Notice also the two same as fields at the top of the right pane. One, the bblfish.net URL that you dragged and dropped onto the first pane. The second URL is http://sixiron.sfbay.sun.com:8080/FoafServer/services/people/155492#HSwhich is an internal Sun URL.

4. explore the second column

Exploring the list of people I know, you will find Tim Berners Lee. I met Tim at a couple of semantic web conferences. He is a very nice person, and so I link to him. Notice that I don't say much in my file about him. I just give his name and the URL identifying him. You will notice it is a w3c url. It is not the same URL as my foaf file was pointing to. His information is somewhere else on a different server.

What if I want to find out more about Tim. In this Address Book it just requires pressing the space bar on your keyboard ( UI designers I welcome your improvement suggestions )

5. press the space bar on the keyboard...

The Address Book then fetch the W3C URL identifying Tim Berners Lee, and merges this new information with the graph in the database, redisplaying then the information as shown here.

You can also see a list of all Tim Berners Lees friends in the third column.

You can also see where Tim Berners Lee's office is ( in Cambridge Mass ), what his phone number is, his home page, and some other of his identifiers.

6. positioning with NASA's World Wind

Do you notice the two tabs in the right pane?

If you click the you click on the location tab, and wait a little, you will see a map of globe which you can have zoom into the location of the person highlighted. Here we can see an overview Cambridge Mass, where Tim Berners Lee's MIT offices are.

The map knows where Tim's office location is because he added that information to his foaf file.

This was put together rather quickly for JavaOne. The user interface clearly needs to be improoved. For example it should show a circle on the map to highlight his location. It won the map... All kinds of fun things are possible, and I welcome all to participate on improving this project.

So Tim added that information to his foaf file. But he could also have just pointed to another resource located on another machine to give him that information.

7. Sun Intranet Foaf experiment

So what about security?

Well here is a very simple example of how to get securit going. Remember how earlier I pointed out that I had two identifiers: two urls in the right pane that were related by the same as relation?

One of these was a sixiron.sfbay.sun.com:8080 url, a temporary sun intranet URL. This will not be accessible to anyone who is not inside the Sun firewall. Those who do have access will be able to click the space bar on my name in the first column, and the Address Book will fetch the internal sun foaf information, which will be merged with my information, because the first foaf file said those two names referred to the same thing, me.

As a result someone who has that access will be able to browse not just my public network, but also my sun protected network...

Foaf: Friend of a Friend

Here is the way to think about what is happening. Instead of thinking just about names, we think about what the names refer to. What the names refer to is the semantics of the relation described via uris above. The triple of URIs forms the syntax. The thing they describe is the world. By distinguishing the names of things and the things they speak of we can use inferencing to deduce when two names identify the same thing. That is where inferencing comes to be important, and you will find out more on that subject by searching for OWL and rdf on the internet.

Advantages

Open Social Network no data silos

Information about people is always up to date
(an HTTP GET away)

this could be used to keep up to date on where friends are

It is easy to publish a foaf file: one click away

Drag and drop friends

security: some ideas at the end of the talk

So in summary here are the advantges of such an AddressBook. 1. We have an open social netowork without Data Silos. Metcalf's law can work a lot better in an open web 2. The information about the people you want to contact can always be up to date. It is after all just one HTTP GET away, and since there is no need to duplicate the information everywhere, we can feel more confident that people will keep their core information up to date. 3. I did not show this, but it is very easy to publish a foaf file. 4. You can drag and drop friends onto your address book 5. We can even add security, as shown previously. At the end of the talk I will go into more sophisticated ways of doing this.

Two foaf files on the internet

Ok so let us dig down a little and look more carefully at what is going on here. Let us just take a simple case of two graphs placed inside two files on two different web servers. The files can be built in two completely different ways.

The Apache server is serving up file (representation) stating a few things about Tim Bray, on the Tomcat server is serving a file (representation) stating a few things about me.

There are also arrows going from Henry to Tim and vice versa saying that they know each other.

Well, what we really have is

Well ok. Let us be clearer still. Web servers don't serve up graphs like that. And nobody has see arrows pointing across web servers.

Web server serve up representations that have a graph as their interpretation, but these graphs are usually written up in some language such as this. This is an easy to read notation called Turtle.

The arrows we showed previously come from the fact that both documents use the same URLs when talking about Tim and when talking about Henry. That is how two documents can point at the same objects.

Well, what we really have is in graph view

Ok, so now that we have explained away the magic, let us nevertheless get back to the graph representation which is easier visually to aprehend.

You could argue that what we really have are two graphs with a little overlap on each server. Henry appears in Tim's graph, and Tim appears in Henry's graph.

This might remind you of an earlier slide when we were describing the problems of the copy solution of social networks. Here though the information duplication remains very minimal, and we are linking by reference.

The graphs inside the Beatnik Database

So what does our AddressBook do with this information. Well like a web browser it fetches the graphs by sending an HTTP GET request to each web server. It then places this information in its quad store database (it uses sesame from http://openrdf.org ) and keeps information there as to when it fetched that information and where it came from.

As you can see both graphs were fetched on the 1st of April.

Networked graphs: A merged view

Having fetched both documents, the quad store can then creates a view on the union of those two graphs and do some inferencing on it to tie information together.

In the large graph on the right we can see the result of such an inference. The Address Book can then presents this to the user in some way or another, as we saw earlier.

SPARQL: semantic query lang

PREFIX foaf:

SELECT ?p

WHERE {

?p foaf:knows ?q .

}

The presentation layer can for example query the merged view with a language such as SPARQL, the semantic web query language, designed to look an awful lot like SQL. Notice that unlike SQL URLs are a core component of the language.

Here the query asks for all the people who know someone.

The result sets can be returned in any number of formats, including a simple xml format, and RDF format, and a JSON format. More could be invented if people really felt a need for it.

SPARQL construct query

PREFIX xsd:

CONSTRUCT { ?subject ?relation ?object .} WHERE { GRAPH ?g { ?subject ?relation ?object . } ?g :fetched-at ?date . FILTER { ?date < 2008-03-30^^xsd:date }}

This CONSTRUCT query can be used to construct a graph that is a union of all graphs that were fetched after march 2008.

SPARQL also has a CONSTRUCT query mode that allows one to create new relations from old relations

The above relations says: get me all relations from all graphs that were fetched at a date previous to 30 March 2008.

Networked Graphs: SPARQL Rules

PREFIX owl:

CONSTRUCT { ?b owl:sameAs ?a . } WHERE { ?a owl:sameAs ?b . FILTER ( ! SAMETERM(?a , ?b) ) }

CONSTRUCT queries can also be thought of as rules. Here is the well known rule of symmetry of identity.

Simon Schenk's Networked Graphs can have a number of rules expressed as SPARQL CONSTRUCT queries, which works nicely with the Sesame semantic engine.

CONSTRUCT statements can be thought of as rules, ways of constructing new statements out of old statements.

Here us ing Simon Schenk's networked Graph layer, we express the well known symmetry of identity. If two names a and b refer to identical things, then b and and a are identical.

merging identities

PREFIX owl: PREFIX foaf:

CONSTRUCT { ?a owl:sameAs ?b . } WHERE { ?a foaf:homepage ?pg . ?b foaf:homepage ?pg . FILTER ( ! SAMETERM (?a , ?b)) }

The rule that if we have two names for people that have the same homepage, then the two names refer to the same person.

There are more general ways of stating this btw.

So here is perhaps a more interesting rule.

Here we are saying that if two people have the same home page, then they are the same people.

That can be very useful when you know two people under different names and they specify their home pages. You can then deduce that they are the same people.

Security: 3 approaches

Simple Firewall based security

OpenId based Security

Even simpler SSL based security

So now we have looked at how one can merge information from across the web without trouble. Let us now look at security.

Here are three solutions to consider.

Firewall protection

The simplest form of protection to demonstrate, if you have a firewall, is the one I showed earlier in the demo of the AddressBook. Place one of the foaf files inside a firewall, and link to it from a publicly available foaf file. Only people who have access to the intranet protected by the firewall will get access to the information.

Your user will have two identifying URLs: one pointing inside the firewall, and one outside the firewall. By having the external foaf file claim that the two are identical, a tool such as the Address Book can merge the information.

This may be simple, but in essence this is what the other two proposals I will put forward here do. They make one of the resources inaccessible to some users.

Protecting resources with OpenId

In order to allow clients to be able to identify themselves, without necessarily having to create an account on your site, one among perhaps a million of sites if everybody gets to have their own foaf server, a global identifier is needed. This is what OpenId provides. With Openid every person in the world can choose one or more URLs to identify themselves.

This sequence diagram illustrates the somewhat complicated OpenId protocol. For the full details you can click on the title, I will try to stick to the essentials here.

There are a two human actors here, and a number of software agents. The two human actors are Romeo and Juliette. Juliette publishes information on her server. She has public and protected information there. Romeo is using an Address Book like the one I demonstrated earlier.

In 1 Romeo drags Juliet's public foaf URL into his Address Book, which duly goes to fetch it.

Protected Resources

:me a foaf:Person;

foaf:name Henry Story;

rdfs:seeAlso .

openid:login .

This is trying to say that in order to access the protected resource one needs to login with openid first.

This is a sketch of such a vocabulary

This public foaf file may contain the following N3 (Turtle) .

It says that :me is a Person named Henry Story and that one can find more at the protected resource it also says that this resource requires one to log in first at the openid authentication end point

This is a sketch. I am looking for some people to help finalize this ontology.

OpenId continued

The AddressBook knowing that it has to log in first before it finds the additional protected information will then go through the usual OpenId authentication protocol, which as you can see is quite complicated. What the OpenId protocol does in short is to link the User Agent to a resource on the web.

What is achieved once this is done? Not much, other than that Juliette's intelligent web server can now search through her friends foaf files, to see if any of them know someone with that openid. If someone does she will trust them with the protected information.

She could of course have different policies, and only trust people two of her friends know, or only people known by her family, or whatever. It's up to her. Notice though that nobody needs to have an account on her machine for this to work. Notice also that she does this is dynamic. If her friends add someone to their network, her network grows too.

foaf+ssl: even simpler

The foaf+ssl proposal makes things even simpler by cutting the OpenId concepts down to the core, and removing the limitation of only having to work with current browsers.

Here we use the infrastructure that comes with every browser and every web server, known as https to get somewhat more than is usually thought possible. For full details click on the header of this slide.

Again in stage 1 Romeo's semantic web client fetches Juliette's public foaf.

This may say something like the following...

Protected Resources

:me a foaf:Person;

foaf:name Henry Story;

rdfs:seeAlso .

notice the seeAlso is now an https url

This time the seeAlso just points to an https url. If the AddressBook whiches to know more about :me it will have to get that information using the secure protocol, the one you use whenever you buy something on the internet.

foaf+ssl: even simpler

In stage 2 then Romeo's User Agent starts the https connection on the protected resource.

Normally the server then just returns a response with its certificate. But it is also possible for the server to ask the client's for its certificate. Getting a certificate with information that is guaranteed by a serious institution is not an easy task. It costs money, and it requires a lot of attention. Furthermore these institutions, not wanting to take much risk, are not going to put a lot of information about the user in that certificate. So if this whole scheme required getting identify information from slow moving institutions, this would never get off the ground.

Luckily it is possible to create one's own certificate, and self sign it. This is very very easy to do. But what does it prove? Anyone can put any information in their certificate right? Well just as with OpenId.

Yes, just as anyone can say anything about themselves. But we don't trust people who are the only ones to say something about themselves as much as we do people about whome others also sing praises. To understand this is to understand the dynamics of the web of trust.

X509 certificate

Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: dsaWithSHA1 Issuer: O=OpenPGP to X.509 Bridge, OU=RDFauth Test, CN=Henry Story Validity Not Before: Dec 12 21:49:50 2007 GMT Not After : Dec 6 21:49:50 2008 GMT Subject: O=OpenPGP to X.509 Bridge, OU=RDFauth Test, CN=Henry Story Subject Public Key Info: Public Key Algorithm: dsaEncryption DSA Public Key: pub: 33:41:...

This is the well known part of an X509 certificate client certificate. It has an Issuer field, a validity field, and a bunch of other information too.

X509 certificate with id

X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Key Agreement, Certificate Sign Netscape Cert Type: SSL Client, S/MIME X509v3 Subject Key Identifier: 45:DC:F9:10:33:C0:45:28:EA:90:6E:83:73:06:6F:51:21:89:13:DD X509v3 Authority Key Identifier: keyid:45:DC:F9:10:33:C0:45:28:EA:90:6E:83:73:06:6F:51:21:89:13:DD

X509v3 Subject Alternative Name: URI:http://bblfish.net/people/henry/card#me Signature Algorithm: dsaWithSHA1 30:2c:02:14:78:69:1e:4f:7d:37:36:a5:8f:37:30:58:18:5a: f6:10:e9:13:a4:ec:02:14:03:93:42:3b:c0:d4:33:63:ae:2f: eb:8c:11:08:1c:aa:93:7d:71:01

What interests us here is that there is a field in X509, that few people know about, that allow people to put a URI identifier of the subject of the certificate. This of course is an excellent place to put the foaf URI.

Very Simple Authentication

Now once the server has received the X509 certificate we just showed, it can find the URI of the owner of the Agent, namely Romeo, and from there it can GET a representation at that URI. This is what we have illustrated in part 3 of the diagram.

We will next imagine then that Romeo's public foaf file contains a relation to the signature of that certificate, essentially proving that Romeo's User Agent is tied to that ID. Since Romeo's User Agent can create that foaf document, it is also easy for it to add that information there.

The rest follow as previously. Now that Juliette's Web Server has a URI to identify the requester she can now check if any of her friends knows Romeo. If any do she can then let him see the protected resource by returning that in 5.

One advantage of this protocol is that Romeo does not even need to enter a password or an identifier for him to get logged in.

The Semantic Desktop

So finally once one has thought this through it becomes obvious that the Address Book is just one of a huge number of applications that can be changed this way.

Consider the following diagram. I have classified some well known applications into three categories, depending on whether they are Island apps, in a master/slave relation, or hyper apps.

Island Apps are what we all had in the 1980ies before the internet. The Application had could only look locally for information. If it was not on the hard drive it did not exist. A good prototype for this is Windows File Manager, or the early versions of Microsoft Word.

Master Slave apps know that there is another world out there, but they are only allowed to serve one master. Apple's iPhoto is nearly like that, though I never use that functionality. iTunes is similar. You can listen to all the music on your hard drive, or on the iTunes music site. LinkedIn and most social networks are like that now. You can work with your data while it is on their servers, but not when it is off it.

Finally there are the hyper apps. Mosaic, the grandfather of all web browsers was such a thing. Go to any page, and you can link off to any other page. The Semantic Address Book is another such tool. Where web browsers navigate hypertext, these new apps navigate hyperdata.

Notice how few apps do that.

some references

Getting Started With RDF

The Semantic Address Book web site

Page

Speaker Presentation Name

Sun Microsystems, Inc.

Click to edit the title text format

Click to edit the outline text format

Second Outline Level

Exact File Name

9/4/08

Page

Click to edit the title text format

Presenters Name

Presenters Title

Presenters Company

Click to edit the notes format

Exact File Name

9/4/08

Page