In a July 2009 post entitled Entities and Semantic Webs I wrote that "a plurality of our customers and partners place great value on understanding and discovering entities and the relationships between them". This continues to be very much the case two years later.

One of the ways organizations express information about entities is using semantic "triples", in the form of subject-predicate-object. Triples* are interesting because they capture relationships very atomically. For example: one way to represent the text "Joe attends MIT" is as a triple: subject "Joe", predicate "attends" and "MIT" as the object. When you combine a bunch of triples you end up with a graph, consisting of subject and object nodes, and predicates that are the connections between them — also known as a graph.

Modeling this type of information with AIE is quite straightforward. For example, given the following graph:

Here are some triples that describe some of the relationships:

Additional useful metadata can be added to this model, such as the source or date of the item. This makes triples into "quads" or "quints". You can use this metadata to use multiple versions of facts, from multiple sources, intelligently.

When you ingest the triples they can be modeled in various ways. For this article they were represented using XML as entity records wherein each of the predicates is a field. For example:

<triple id="P01">
  <name>Joe</name>
  <is>person</is>
  ...
</triple>

This makes it very easy to access relationships using AIE's JOIN operator. For example, we can find all people who live in a "college town" - a city that has at least one college, with a query like this:

JOIN(is:person, INNER(JOIN(is:city, INNER(is:college, 
ON="entityId=locatedIn")), ON="livesIn=entityId"))

This query returns Joe, Bob and Mike, who live in Cambridge - which has two Colleges located in it. Perhaps we'd want to find anyone who knows someone who attends MIT? Here's the query:

JOIN(is:person, INNER(JOIN(is:person, INNER(AND(is:college, name:MIT),
ON="attends=entityId")), ON="knows=entityId"))

This query returns Henry and Peter; they both know Bob, who attends MIT.

Or perhaps we'd like to match part of the graph, and aggregate another part of it. The GRAPH() operator is designed to do this; it takes two parameters, the part of the graph to match and the relationship keys to use. It then performs a recursive, directional JOIN on the keys.

For example we could find all the institutions attended by people who live in Cambridge with a query like this:

GRAPH(livesIn:L2, ON="attends=entityId")

This returns Joe, Bob and Mike, who all live in Cambridge, and MIT and Harvard, which they attend. We could also match all the institutions Joe attends via a query like this:

GRAPH(name:Joe, ON="attends=entityId")

These types of queries are interesting and valuable because they provide responses to queries that don't have the answer in mind and thus can't just be typed into a search box...they are goal-oriented queries that define the answer based on the relationships or properties that it will have. Combined with other information sources, they provide tremendous power to analyze and profile objects of interest — and understand the important connections between them.

TrackBack URI for this entry

Comments (2)