Archive for the ‘Relationship Persistence’ Category

What is Google Missing?

Wednesday, February 29th, 2012

After I wrote Graph Databases: Information Silo Busters it occurred to me that it names what Google (as an interface) is missing:

  • Declaring relationships
  • Persisting declared relationships

Think about it.

Google crawls a large percentage of the WWW, peering down into first one information silo and then another. And by using Google, I can look down into the same information silos. Better than nothing but could be game changing better.

What if instead of looking down into one data silo after another, I can gather together all the information I find about a subject?

Much like you create a collection of bookmarks but better. I get to say what “string” that the various URLs have information about. Nothing fancy, no complicated, whistle out your left ear syntax, just a string.

See how people like that. If successful, bump that up to two collections with a limited set of relationships (think of operators) between the two strings.

Oh, that’s the other thing, relationships need to be persisted. Think of all the traction that Facebook and others have gotten from persisting relationships.

Unless you know a good reason to throw away searches and whatever declarations I want to make about them?

I can hear Googlers saying they already do the foregoing with all the annoying tracking information attached to all search results. True that Google is tracking search results and choice of sites for particular search requests, but Googlers are guessing as to the relevance of any result for a particular user.

So, rather than guessing, and remembering that making Google more (and not less) useful to users is the key to ad revenue, why not give users the ability to declare and persist relationships in Google search results? (Any other search wannabe is free to try the same strategy.)

Graph Databases: Information Silo Busters

Wednesday, February 29th, 2012

In a post about InfiniteGraph 2.1 I found the following:

Other big data solutions all lack one thing, Clark contends. There is no easy way to represent the connection information, the relationships across the different silos of data or different data stores, he says. “That is where Objectivity can provide the enhanced storage for actually helping extract and persist those relationships so you can then ask queries about how things are connected.”

(Brian Clark, vice president, Data Management, Objectivity)

It was the last line of the post but I would have sharpened it and made it the lead slug.

Think about what Clark is saying: Not only can we persist relationship information within a datastore but also generate and persist relationship information between datastores. With no restriction on the nature of the datastores.

Try doing that with a relational database and SQL.

What I find particularly attractive is that persisting relationships across datastores means that we can jump the hurdle of making everyone use a common data model. It can be as common (in the graph) as it needs to be and no more.

Of course I think about this as being particularly suited for topic maps as we can document why we have mapped components of diverse data models to particular points in the graph but what did you expect?

But used robustly, graph databases are going to allow you to perform integration across whatever datastores are available to you, using whatever data models they use, and mapped to whatever data model you like. As others may map your graph database to models they prefer as well.

I think the need for documenting those mappings is one that needs attention sooner rather than later.

BTW, feel free to use the phrase “Graph Databases: Information Silo Busters.” (with or without attribution – I want information silos to fall more than I want personal recognition.)