Databases Reference
In-Depth Information
with an assertion of fact. In figure 4.13 the first
assertion is (book, has-author, Person123), and
the second assertion is (Person123, has-name,
“Dan”).
When stored in a graph store, the two state-
ments are independent and may even be
stored on different systems around the world.
But if the
URI
of the Person123 structure is the
same in both assertions, your application can
figure out that the author of the topic has a
name of "Dan", as shown in figure 4.14.
Has-author
Book
Person123
Has-name
Person123
“Dan”
Figure 4.13
Two distinct RDF assertions.
The first assertion states that a topic has a
person as its author. The second assertion
shows that this person has a name of Dan.
Since the object of the first and the subject
of the second have the same URI, they can
be joined together.
Figure 4.14
How two distinct RDF
assertions can be joined together to
create a new assertion. From this
graph you can answer yes to the
question, “Does this topic have any
author that has the name "Dan"?”
Has-author
Has-name
Book
Person123
“Dan”
The ability to traverse a graph relies on the fact that two nodes in different groups ref-
erence the same physical object. In this example, the Person123 node needs to glob-
ally refer to the same item. Once you determine they're the same, you can join the
graphs together. This process is useful in areas like logic inference and complex pat-
tern matching.
As you can imagine, the
W3C
, who created the
RDF
standard, is highly motivated to
be consistent across all of their standards. Since they already have a method for identi-
fying an
HTML
page anywhere in the world using a uniform resource locator struc-
ture, it makes sense to repurpose these structures whenever possible. The major
difference is that, unlike a
URL
, a
URI
doesn't have to point to any actual website or
web page. The only criteria is that you must have a way to make them globally consis-
tent across the entire web and match exactly when you compare two nodes.
While a pure triple store is the ideal, in the real world triple stores frequently asso-
ciate other information with each triple. For example, they might include what group
ID
the graph belongs to, the date and time the node was created or last updated, or
what security groups are associated with the graph. These attributes are frequently
called
link metadata
because they describe information about the link itself. Storing
this metadata with every node does take more disk space, but it makes the data much
easier to audit and manage.
4.2.3
Use cases for graph stores
In this section, we'll look at situations where a graph store can be used to effectively
solve a particular business problem:
