Tupelo Semantic Content Repository

Tupelo 2 is designed to be built with Maven, although it can also be built in Eclipse.

After checking out Tupelo 2, make sure Maven is installed and configured, change to the top-level directory, and issue the following command:

mvn install

Note that building Tupelo for the first time will require an active internet connection, so Maven can download its plugins, as well as the libraries Tupelo depends on.

If you have any other problems building, email futrelle (at) ncsa.uiuc.edu.

Tupelo is available as a download, although we recommend checking it out of SVN instead.

You can download Tupelo here.

Tupelo is a data and metadata management system based on semantic web technologies. Tupelo provides a variety of generic utilities for managing data and metadata using both best-of-breed semantic database implementations such as Jena and Sesame, as well as ordinary storage technologies such as flat files. Tupelo makes data and metadata portable across a variety of Contexts and deployment scenarios, including desktop applications, web-based applications, and more complex distributed architectures. Its use of global identification and explicit semantics means that metadata created and managed with Tupelo can be easily exported and used by a wide variety of RDF-aware tools and technologies.

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.

Welcome to the Tupelo project website. This website contains downloadable software, documentation, and project information about the Tupelo Semantic Content repository.

The website is organized around the topic hierarchy in the left navigation panel. To quickly see a sortable list of all content on the site, go to the Site Index.

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.