Database Reference
In-Depth Information
8.7 ENCODING CONTEXT: AN ATHEIST'S VIEW OF WEB IDENTITY
Unlike many statements in the literature, we do not support a “God's eye view”
on the world. That is, we do not believe that there is
any
overarching view of iden-
tity—there
is
no common view of Ash Fleet, say, to which everyone will agree.
There are multiple contexts, and any agreement can only be made within a specific
context. Some contexts may be quite general, others more specific, but there is no
absolute agreement. Linked Open Data practitioners have struggled with this issue
and usually cite the example of a person as the clearest case of the God's eye view
of identity: Surely there is some representation of a person that everyone can sign up
to? Obviously, not everyone needs to bother with all the attributes about a person;
some will be interested in his or her e-mail address, while others want to know what
papers they published, but there seems to be general agreement about the identity of
a person. This absolute representation is paralleled in the idea of bona fide boundar-
ies or objects in the geographic domain, but it is a fallacy. For example, we need con-
text to answer questions like: Is Luke Skywalker a person? What uniquely identifies
a person? (Mozart might be a person, but he does not have a Social Security number
or e-mail address.) Since there is no context-free definition of an instance's identity,
every matching decision is in fact made within a context.
In the mentioned example of Ash Fleet, instances can be matched or more linked
generally only under a particular context. So, the next question is: If I am to link my
data to other nodes on the Semantic Web, how do I specify the context in which those
links are valid?
There are a number of different ways to encode context: both explicitly, through
technical mechanisms of reification, named graphs, or what we term Named Triples;
and implicitly, by characterizing the “landscape” of links, that is, the clustering of
nodes in the graph, which may be tightly clustered or fall under different namespaces.
We mentioned the concept of reification for encoding metadata about RDF in
Section 5.5.1, and this is one mechanism that people have turned to for describ-
ing the context in which the RDF graph is valid. Recall that reification specifies
an
rdf:Statement
, which has a subject, predicate, and object, and allows other
information, namely, metadata, to be added about that statement. However, as we
have seen, the technique of reification has several drawbacks. First, it makes query-
ing difficult as the triple graph model has been broken. Second, it buries metadata
within the data itself, potentially making the volume of data balloon and forcing a
user to deal with both data and metadata at the same time, which can make con-
structing queries very ugly. An alternative to reification is the technique of Named
Graphs (Carroll et al., 2005), which names multiple RDF graphs within a single data
repository or document with their own URIs, so that they can be individually refer-
enced, allowing context information to be applied to each named graph individually.
Named graphs can be taken to the extreme of granularity, that is, to assign a
context (in the form of a URI) to each resource individually, or even to each tri-
ple—a “Named Triple” if you will. Although Named Graphs are not part of the
RDF standard, they are mentioned in the SPARQL 1.0 standard, which specifies that
graphs can be explicitly named within a SPARQL query (see Section 8.3.2), and in
