Provides the API for accessing and processing data stored according to the RDF abstract syntax. The API includes a framework for constructing {@link com.ibm.team.jfs.app.rdf.Statement statements} and {@link com.ibm.team.jfs.app.rdf.IGraph graphs} and storing these in {@link com.ibm.team.jfs.app.rdf.IGraphStore graph stores}. Both graphs and stores make use of the Java Collections Framework, specifically both implement the {@link java.util.Collection} interface to allow them to act as other collections do.

The purpose of the Graph API package is to provide concrete implementations of common elements but also to describe the key interfaces required to implement an RDF Store - that is a persistent store for RDF graphs. Thus the overall RDF API distinguishes between two roles, the role of the developer writing to the RDF Graph and Query APIs and the role of the store provider writing implementations of these two API interfaces. To implement a store the developer must not only provide an implementation of {@link com.ibm.team.jfs.app.rdf.IGraphStore} but it is expected that an implementation of {@link com.ibm.team.jfs.app.rdf.IGraph} and {@link com.ibm.team.jfs.app.rdf.INamedGraph} will be required that correspond to the storage model of the {@link com.ibm.team.jfs.app.rdf.IGraphStore}.

The following diagram attempts to demonstrate the key elements currently provided by the overall RDF API. Those elements in light blue are provided, at least in part, by the RDF API whereas those elements in orange below are required to be implemented by a store provider.

In particular note the dependencies between the elements in the diagram above, the parsers implemented in the RDF API only require access to the API whereas the reasoners will require access to at least the graph API and most likely the query API as well. The overall RDF API includes a simple implementation of the graph store as an in-memory collection, this allows clients to have a light-weight non-persistent graph and store implementation for manipulating temporary graphs of statements.

What the rdf Package Contains

• Constructing and storing graphs:
  • {@link com.ibm.team.jfs.app.rdf.IGraph} -- A graph is a collection of related {@link com.ibm.team.jfs.app.rdf.Statement statements}.
  • {@link com.ibm.team.jfs.app.rdf.INamedGraph} -- A named graph is a graph that has it's own identifier.
  • {@link com.ibm.team.jfs.app.rdf.IGraphStore} -- A graph store represents the notion of some container that is either persistent or not (but more often it is) that contains a number of {@link com.ibm.team.jfs.app.rdf.IGraph graphs}.
• Constructing Statements or Triples:
  • {@link com.ibm.team.jfs.app.rdf.Statement} -- A statement in RDF represents some asserted or inferred fact about some subject. The general form of a statement is a triple of (Subject, Predicate, Object).
  • {@link com.ibm.team.jfs.app.rdf.Node} -- A node is used as the base for elements in {@link com.ibm.team.jfs.app.rdf.Statement statements}.
  • {@link com.ibm.team.jfs.app.rdf.ReferenceNode} -- A reference node explicitly captures some relationship between either two {@link com.ibm.team.jfs.app.rdf.Statement statements} or between a {@link com.ibm.team.jfs.app.rdf.Statement statement} and another resource.
  • {@link com.ibm.team.jfs.app.rdf.URINode} -- A URI node is a reference from the {@link com.ibm.team.jfs.app.rdf.Statement statement} to another resource identified by a {@link java.net.URI}.
  • {@link com.ibm.team.jfs.app.rdf.BlankNode} -- A blank node is an internally generated reference allowing a number of {@link com.ibm.team.jfs.app.rdf.Statement statement's} subject be the object of another. This kind of reference allows anonymous subgraphs.
  • {@link com.ibm.team.jfs.app.rdf.LiteralNode} -- A literal node is only ever used as the object of a {@link com.ibm.team.jfs.app.rdf.Statement statement} and carries a literal value, a string, number, boolean, date, etc.
• Graph Helpers:
  • {@link com.ibm.team.jfs.app.rdf.Resource} -- A more resource-centric API to to create a new {@link com.ibm.team.jfs.app.rdf.IGraph}. The implementation makes use of the {@link com.ibm.team.jfs.app.rdf.NodeFactory} class.
  • {@link com.ibm.team.jfs.app.rdf.NodeFactory} -- A factory class that allows clients to reuse a cache of {@link com.ibm.team.jfs.app.rdf.LiteralNode}, {@link com.ibm.team.jfs.app.rdf.URINode} and {@link com.ibm.team.jfs.app.rdf.BlankNode} instances. This represents a possibly significant performance advantage where URIs used for subjects and/or properties are used over and over.

URI usage

In both {@link com.ibm.team.jfs.app.rdf.LiteralNode} and {@link com.ibm.team.jfs.app.rdf.URINode} instances the API will validate that the URI provided by the client is both non-null as well as absolute. The RDF data model requires that all URIs in graphs be absolute, and it is the job of any given parser to ensure the correct construction of URIs using whatever resolution mechanism is provided in the representation syntax (xml:base for RDF/XML for example).

Implementing a Store

A store must implement the {@link com.ibm.team.jfs.app.rdf.IGraphStore} to allow clients to connect to the store and create new graphs, retrieve graphs and remove graphs. In general a store will also have their own implementations of both {@link com.ibm.team.jfs.app.rdf.IGraph} and {@link com.ibm.team.jfs.app.rdf.INamedGraph} as these graph implementations will often need to have links back to store-specific resources.

The package {@link com.ibm.team.jfs.app.rdf.memory} provides an example implementation of an entirely in-memory store that can be used for testing or managing temporary graphs.

@since 0.1