Tupelo Semantic Content Repository

RDF graphs consist of statements, each of which is represented by an RDF triple. Triples are represented in Tupelo 2 with the Triple class, which extends the more generic Tuple utility.

Tupelo's server protocol is a modified and greatly extended variant of URIQA's "Semantic Web Service" interface. In addition to URIQA methods, Tupelo supports a number of other methods.

Tupelo Server methods take a variety of parameters. Common ones include:

• uri - the URI of the subject on which to perform the method
• format - the format of the input or output of the method:
  • rdf - RDF/XML format
  • nt - N-Triples format
  • n3 - n3 format

Server-side

Tupelo Server is a servlet that should be hosted in a web application container. It is configured to be backed with a single Tupelo Context and all operations requested by the client are performed against that Context.

Client-side

A client Context implementation is provided that translates all supported Operators into requests to a server. The client must be configured with the URL of the servlet representing a Tupelo Server instance. There are no restrictions on what URL can be used.

Operators are the abstract behaviors that form the Tupelo kernel. Operators are stateful descriptions of actions and the results of actions that are performed by a Context. Currently, Tupelo supports two kinds of Operators:

1. Blob operators, and
2. Triple operators

The Context abstraction is the basis of Tupelo's flexible, distributed architecture for managing information. Each Context represents one or more sources of and/or destinations for information, including binary data, text data, and RDF metadata. Contexts act as brokers between an application and any of a variety of different ways of accessing, storing, querying, and managing information, including filesystems, relational databases, web services, and RDF triple stores.

Tupelo Contexts provide a generic set of Operators, which are tasks that read or write information to or from a Context. Each Operator is designed as much as possible to behave consistently regardless of which Context is used to perform it.

For example, the BlobFetcher Operator is used to read binary data associated with a given URI, and can be used to read web pages:

Context c = new HttpContext();
BlobFetcher bf = new BlobFetcher();
bf.setUri(URI.create("http://apod.nasa.gov/apod/image/0909/butterfly_hst_big.jpg"));
c.perform(bf);
InputStream image = bf.getInputStream();

or files:

Context c = new SimpleFileContext();
c.setPathPrefix("/home/johndoe/images/");
c.setUriPrefix("tag:johndoe@email.com,2005:images#");
BlobFetcher bf = new BlobFetcher();
bf.setUri(URI.create("tag:johndoe@email.com,2005:images#lolCat23.jpg"));
c.perform(bf);
InputStream image = bf.getInputStream();

or from a variety of other ways of storing and retrieving octet streams, including relational databases and remote web services.

Core operators

The Tupelo kernel provides a small core set of Operator classes including:

• BlobFetcher for reading octet streams associated with a given URI
• BlobWriter for writing octet streams and associating them with URI's
• BlobRemover for breaking the association between a URI and an octet stream
• TripleFetcher for reading RDF metadata associated with a given URI
• TripleMatcher for finding RDF metadata statements that match a pattern
• Unifier for performing simple conjunctive RDF queries and returning result tables
• Transformer for performing simple conjunctive inference based on Unifier queries

Note: in Tupelo 2.5 much of this functionality is available using the Tupelo Chains API.

Not all Contexts support all Operator classes. For example, filesystem-backed Contexts generally cannot perform SPARQL queries or other metadata operations. An application can interrogate a Context at runtime to determine which operations can be performed and if not why not, which for instance allows a Context to reject operations because it is busy.