Summary of Recent Discussions about an Application Programming Interface for RDF

Table of Contents

1) Motivation

RDF models are parsed and serialized to enable easy storage and transportation as a file or stream. The format most commonly used is XML, although there exist other (e.g stream of statements). Utilities for parsing and serializing RDF have been developed, an example is the SiRPAC parser[3] available on the W3C web site.

However, no Application Programming Interface (API) is available. To use applications for designing / manipulating RDF models, self-made solutions have to be developed.

Although it is possible to manipulate RDF models in XML format by using an API Standard for XML (e.g.DOM [4]), this approach is not favorable, as XML is just one way to display RDF (see above).

This lack of a standard API for RDF has led to isolated solutions (compare Chapter 2), which are often designed to fit to a specific purpose rather than to cover all important aspects of RDF modelling. Cooperation between this API’s is difficult at best, as compartibility is questionable regarding the differences.

This paper introduces a proposal for an RDF API standard made by the RDF interest community which discussed the topic in a newsgroup hosted by the W3C.
Chapter 2 is dedicated to previous approaches to an RDF API. Chapter 3 describes the development of the API standard and displays its current status. In Chapter 4 an example of implementing the standard is introduced. The last chapter is used for describe future work that may be done on the API.

2) Related Work

2.1) Mozilla

• Data about E-Mail and News.
• Browsing History.
• Bookmarks.

• A Set of Resources.
• A Set of Literals.
• A Set of Statements.

The RDF implementation of Mozilla is defined by a set of interfaces, as follows :

nsIRDFService

This interface provides methods for

• managing of datasources (mapping name to URL).
• mapping resources to URIs.
• mapping literals to strings.

The abstract interface is used to manage a resource or literal.
Derived from nsIRDFNode are the interfaces

• nsIRDFResource and
• nsIRDFLiteral

The interface is used to manage a single datasource (i.e. a model).

nsIRDFCompositeDataSource

With this interface, a set of datasources may be combined (union of the datasources). The composite datasource contains the information of all datasources combined in it.

nsIRDFObserver

The interface provides methods which allow to „observe“ a datasource for changes made and trigger reactions on them („active RDF“).

nsIRDFContainer
nsIRDFContainerUtils

This interfaces enable handling of RDF container objects (bag, sequence, alternation).

2.2) GINF

• protocolls.
• languages.
• data and
• interfaces.

• Creating a model (as empty model or copy of another model)
• Manipulating a model (adding / removing triples, manipulating the models URI)
• Performing set operations on models (union, difference)
• Accessing model data (count triples, find triples (similiar to an SQL query), get all triples, get model URI)

2.3) The RADIX proposal

Must :

• Independency of the particular means of data storage (e.g. relational databases, DBM-Files, in-memory storage).
• Support of different front-end-parsers (e.g. XML, Set of Triples).
• Manipulation of Nodes and Arcs
• Queries about Nodes and Arcs
• Support of Models
• Metadata for Models

• Management of multiple RDF storage systems by the same thread
• RDF schema integration / validation of models

• Support of several storage mechanisms.
• Possession of an input parser.
• Support of an output format.

Resource

The interface supports a single resource. It contains methods for manipulating / querying for the URI. Of interest at this point is the lack of an interface for a literal, which is treated as a standard data type (e.g. string, integer). Data of literals is stored in the Statement using the literal.

Statement (subclass of Resource)

The statement interface supports an RDF statement, with methods for changing / getting the subject, predicate and object of the statement. Because statement is a subclass of Resource, each statement has an URI (enabling easy creation of reified statements), which may be set at the creation of the statement or at a later time (via the inherited method from Resource).

Model (subclass of Resource)

This interface is used for support of an RDF Model. The Model interface provides the following functionalities :

• Adding / Removing Resources.
• Adding / Removing Statements.
• Getting the Model’s Statements.
• Querying the model (similiar to SQL), the result is returned as another Model.
• Generation of SystemIdStrings (used as identifier for Statements or Resources lacking explicitely given URI).
• Getting / Setting the models baseURI.
• Output of the model to a string (e.g. XML format).

The ModelStore Interface is used for storage of models. It is a collection of several models. Methods exist for adding / removing models from the store.

Query (subclass of statement)

The interface is used for construction of queries on models. It has no further methods other than those derived from Statement. A query to a model is made by creating a statement (via the Query interface) and calling the appropriate method from the model interface. The query returns the statements which „match“ the Query statement, null values in the Query statement match anything (Compare the find method in Section 3.2 of this paper)).

3) W3C RDF Interest Group RDF API Proposal

Developing a standardized RDF API was discussed since the summer of 1999. Chapter 3.1 below is dedicated to topics that were discussed in November/December 1999, when the RDF API discussion went concrete.
In Chapter 3.2 the APIs central interfaces are introduced. Chapter 3.3 contains an example how to use these interfaces.
Chapter 4 is dedicated to an implementation of the API interfaces by Sergej Melnik (available as package[11]).

Serious discussion about the API aroused around November 14^th, when a structure for an RDF API based on the existing API used by GINF was proposed{Melnik N44}.
A second proposal for the RDF API{Melnik D5}, based on the first and the discussions thereafter, was made on December 3^rd. Melniks implementation is based on the december proposal.

3.1) Points of interest

Standalone resources

There was a proposal to provide add/remove methods not only for triples, but also for inserting / removing single nodes{Saarela N79} (as in the RADIX proposal, compare section 2.3). An argument were possible problems in calculating the intersection / difference of two models (What is triple {A,B,C} minus triple {A,D,E} - {A} or {A,B,C}).
However, an argument against the existence of stand-alone resources is the question whether resources that have an identifier but provide no additional information make sense in the context of an RDF Model.
The discussion about this topic was closed without changes to the API, i.e. the current API version does not support handling of stand-alone-resources. Difference and Intersection of models is computed on the base of triples, not resources (i.e. {A,B,C} minus triple {A,D,E} is {A,B,C}).

Models as resources
In the first API proposal it was not clearly said if Models are treated as Resources (have an URI). However, there were arguments made by members of the discussion group that could hardly be ignored{Beged-Dov N53}{Daniel N119}:

A model should be a resource / have an URI because

• it is a first class concept of RDF.
• models should be capable to be the object of a statement (e.g. the statement „additional information“).
• the integration of remote models should be possible.
• metadata about models should be expressable by use of the API.

Versioning of models

A message in early December{Liljegren D12} pointed out the need for versioning of RDF models. According to this message, versioning is essential

• when actuality of information is of importance (e.g. an RDF-based weather report)
• when correcting / changing / adding to the content of an RDF model is done.

Related to the versioning of models is the concept of open/ closed models proposed in {Beged-Dov D26}. An open model is in an „edit“ phase of ist lifecycle - it may be modified, but accessing information (e.g by querying, set operations with other models) may not be done. When the model is closed, URIs are computed for the model itself, triples and no-name resources. Closed models may be accesed for information, but not edited.
In response to this proposal, it was pointed out{Melnik D46} that calculation of URIs for no-name resources should be done in the moment of modifikation, regarding the possibility of cyclic dependancies in the model.

The current implementation of the API (Compare Chapter 4) does not support open/closed models or model versions, but the discussion on this issue may be continued. For versioning of models, compare Chapter 5.

API Layers

In a message from December{Melnik D44} the creation of an RDF schema  interface was announced, according to a proposal made in an earlier message{van Dort D29}. The RDF schema interface (SchemaModel) was meant to be an extension of VirtualModel and to be placed in org.w3c.rdf.schema.
The released API contains an interface for accessing schema information (compare 3.2). It currently lacks a way of manipulating RDF schema information.

In a later message{Liljegren D81} a concrete layer proposal for the RDF API was made. The message proposed four layers¹ :

• Version Layer - A sample of all versions of a specific model.
• Schema Layer - Model schema definition.
• Simple Layer - A single model version.
• Source Layer - parsing and serializing.

URI generation for triples

In the API interface the class Triple (respective Statement) is an instance of the class Resource (Compare Picture 1). Accordingly, the API assignes an URI to each triple. Discussions aroused what this URI should be like :
A proposal was made to set a triples URI to the model URI + an UUID for the triple{Beged-Dov D6}. During  serialization, the corresponding property should get an rdf:ID entry (according to the basic serialization syntax). This approach would have the advantage that the process is independant of the used XML serialization.
Additionally, the importance of an algorithm which creates the same identifier for equal triples in different implementations was mentioned {Melnik D23}.
The API followes this approaches so far that it creates a MD5 digest as URI for each triple. This digest is calculated as digest(subject) XOR digest(predicate) XOR digest(object).
A later message {Liljegren D73} claimed that relative URIs do not make sense regarding triples, because

• Two equal triples from different models would have different URIs.
• The triple URI would change each time the model URI changes.

URI generation for anonymous resources

Automatic generation of URIs for anonymous (no-name) resources was of specific interest for the rdf-interest discussion group.

The concept of assigning an URL to any resource in the model did not please everyone in the community.
Starting this discussion was a message {Melnik D32} that demanded accessibility for every resource and statement in a model, which requires URI generation.
On the other side it was pointed that the URI of a named resource (e.g. the URL of a person’s homepage) usually holds more information than an generated URI, which refers to the RDF describing the resource{Brickley D33}.
In an additional message it is said that anonymous resources are ‘mentions’ of resources which (opposite to the resources themself) may be anonymous. Additionally it was pointed out, that „assigning identifiers to people is a political loaded business“ {Brickley D35}).

Nonetheless, algorithms for calculating URI’s for no-name resources were brought up.
Like some explicitely named resources, an anonymous resource is accessible via a fragment identifier (i.e. a relative hyperlink). For noname resources the fragment identifier would be a digest somehow based on data related to the resource.

Sergej Melnik proposed algorithms for calculation of digests for noname resources and models{Melnik D23}. According to his proposal, the URI of a noname resource is computed out of the digests of other resources, as follows :

• noname resource digest = pathDigest XOR attributeDigest
• pathDigest = digests of the predicates leading to the resource, XOR-combined.
• attributeDigest = digests of the attributes of the resource and their values, XOR-combined.

X

• a -> Y
  • b -> Z
    • c -> A
    • d -> B
  • e -> C

digest(Z)=a0 xor b1 xor c2 xor A3 xor d2 xor B3
digest(Y)=a0 xor b1 xor Z2 xor e1 xor C2
digest(X)=a0 xor Y1

Printed bold is the digest for the path, the other part is the digest for the attributes.
With this algorithm, digests for noname resources can be computed beginning at the resources at high levels in the RDF tree. If a noname resource later gets an explicit name, only the digests of the resources „one level above“ need to be recomputed. Furthermore, switching the order of attributes of a single resource has no effect on that resource’s digest.

For easy separation of named resources and anonymous resources, a proposal was made that anonymous resource fragments are named rdfpointer:anon:digest - opposed to named resources which would be refered to as rdfpointer:id:name{Beged-Dov D36}. In this proposal the resource fragments were used with the generated model id (see below) rather than the model’s source URI.
In a later message{Melnik D43}, disadvantages of using the generated model id were mentioned. First, URIs for anonymous resources would change whenever the model itself changes. Second, the models generated id depends on the digests of anonymous resources, creating cyclic dependancies in digest calcution.

URI generation for models

Sergej Melnik proposed an algorithm for computing a Models URI in the same message as his algorithm for triple URIs (see above).
The model digest is computed combining the digests of all triples with the xor operator. The algorithm allows fast processing of changes in the model : When adding/removing a triple, a single xor operation is sufficient to re-calculate the digest.

Equality of Resources

The RDF community agreed that an important condition algorithms for URI generation are required to to fulfill is the generation of equal URIs for equal resources. The definition of equality, however, still had to be discussed.

The first message refering to the problem {Liljegren D33} listed three cases where equality of resources could be assumed :

• 1. Identical XML from same source (Byte - for - Byte).
• 2. Identical XML from different sources (Byte - for - Byte).
• 3. Identical graphs from different sources (Statement - For - Statement).

1. Identical XML from same server (Byte - for - Byte)

A weather report RDF example {Liljegren D33} was meant to point out possible problems with this case :
The weather report resource in this example is an anonymous resource , describing the „current“ weather report (It refers to a cloud-cover photo which changes daily and has a non-changing description). Liljegren argued, if the same URI would be created for the weather report each day, it would be incorrect, because the photo (and thus the content) has changed.
A comment {Melnik D34} about this statement was that the content of the RDF would not change, because it refers to the „current“ weather, not to a specific day. So, Case 1 would imply equal resources.
Melnik stated in the same message that handling of Case 1 should be a minimum requirement for an algorithm that determines equality of resources.

2. Identical XML from different servers (Byte - for - Byte)

An example about an RDF webmaster anonymous resource {Liljegren D33} showed possible inequality between resources with same XML from different sources :
The webmaster resource in this example possesses an email address („webmaster“), a homepage („/~webmaster/“) and a constant description. When received from different servers, it refers to different persons.
It was agreed that Case 2 is not sufficient to prove equality between resources{Melnik D34}.

3.2) The RDF API Core Interfaces

Picture 1) org.w3c.rdf.model class hierarchy

Methods defined in the interfaces are as follows :

Interface RDFNode (Abstract, i.e. only subclasses of the interface (Resource/Literal) may be used) :

• String getLabel()
  Return value is :
  • The URI, if the RDFNode is of type Resource
  • The Content, if the RDFNode is of type Literal.

The interfaces contains no additional methods.

Interface Resource :

• String getURI()
  Returns the URI of the Resource.

• Resource subject()
  Returns the subject of the statement.
• Resource predicate()
  Returns the predicate of the statement.
• RDFNode object()
  Returns the object of the statement.

object creation

• Model create()
  The method returns an empty model.
• Model dublicate()
  The method returns a copy of the model calling it.
• Literal createLiteral(In String str)
  The method returns a new literal with content str.
• Resource createResource(In String str)
  The method returns a new resource with URI str.
• Statement createStatement(In Resource subject, Resource predicate, RDFNode object)
  The method returns a new triple with Subject, Predicate, Object as given.

• void add(In Statement t)
  The method adds the given statement to the statements of the model.
• void remove(In statement t)
  The method removes the given statement from the statements of the model.
• void setSourceURI(In String URI)
  The method sets the base URI for the model, which has the following effects :
  • At the creation of new resources, the URI may be modified.
  • The URI is used at serialization.
  • When set, the method getURI returns the sourceURI.

• String getSourceURI()
  The method returns the base URI of the model, if previously set.
• int size()
  The method returns a count of the statements in the model.
• Enumeration elements()
  The method returns an enumeration containing each statement in the model.
• boolean contains(In Statement t)
  The method returns true if the model contains the statement, false otherwise.
• Model find(In Resource subject, Resource predicate, RDFNode object)
  The method returns a „sub-model“ containing all statements matching the query parameters.
  Null values for parameters match anything.
  • find (a,0,0) returns a model containing all statements with subject a.
  • find (a,0,c) returns a model containing all statements with subject a and object c.
  • find (a,b,c) returns a model containing all statements with subject a, predicate b and object c (i.e. the statement {a,b,c} if existing in the model queried).

• SetModel intersect(In Model m)
  The method returns the intersection of the calling model with another model.
• SetModel difference(In Model m)
  The method returns the difference of the calling model with another model.
• SetModel unite(In Model m)
  The method returns the union of the calling model with another model.

• Model getGroundModel()
  Returns the „standard“ model the calling virtual model is based on.

3.3) Using the RDF API Core interfaces - A short Example

#Creating the model
Model Example;
Example=Example.create;
Example.setSourceURI(„http://example_server.de/rdf/models/example“);

#Creating Resources and Literals
Resource paper =Example.createResource(„http://paperServer/paperURL“);
Resource author =Example.createResource(„“); #noname resource
Resource author_predicate =Example.createResource(„author“);
Resource firstname_predicate =Example.createResource(„firstname“);
Resource lastname_predicate =Example.createResource(„lastname“);
Literal author_firstname = Example.createLiteral („Peter“);
Literal author_lastname = Example.createLiteral („Hannappel“);

#Creating Statements
Statement paper_attr_1= Example.createStatement (paper, author_predicate, author);
Statement author_attr_1= Example.createStatement (author, firstname_predicate, author_firstname);
Statement author_attr_2= Example.createStatement (author, lastname_predicate, author_lastname);

#adding the Statements to the model
Example.add (paper_attr_1);
Example.add (author_attr_1);
Example.add (author_attr_2);

#Use of the find method
Model authorInfo=Example.find(author,0,0);

Picture 2) The created Model (left) and the Model returned by the „find“ method (right).

4) An implementation of the RDF API Proposal

org.w3c.rdf.examples

Two examples for usage of the RDF API.

org.w3c.rdf.model

The core interfaces for the RDF API (see Section 3.3 of this paper).

org.w3c.rdf.model.impl

An implementation of the core interfaces (except of SetModel and VirtualModel, see 3.3).

org.w3c.rdf.syntax               

Interfaces for parsing and processing RDF Models.
(Input stream -> Model and Model -> output stream).

org.w3c.rdf.syntax.sirpac

A modified SiRPAC adapted to the RDF API used for both parsing and serializing.

org.w3c.rdf.syntax.xml

A parser for XML files.

org.w3c.rdf.syntax.strawman

A simplified parser for XML files, serves as base for org.w3c.syntax.xml.

org.w3c.rdf.util

Utilities for use with the RDF API :
RDFFactory : Convenient use of the API (e.g. : create Parser/Serializer).
RDFDigest : Creating Hash Codes used for URIs.
RDFReader : Converting an arbitrary character stream to RDF.
RDFUtil : A sample of utility methods on RDF Models (e.g. „print statements“).
SetOperations : A sample of set operations between models (union, difference, intersect).

org.w3c.rdf.vocabulary.rdf_schema_19990303

Comfortable access to RDF schema-related vocabulary.

org.w3c.rdf.vocabulary.rdf_syntax_19990222

Comfortable access to RDF syntax-related vocabulary.

org.w3c.tools.crypt

Creating and manipulating MD5-digests.

org.w3c.tools.sorter

Tools for sorting/comparing objects.

org.xml.sax

SAX Parser (SAX : Simple API for XML).

5) Future Work

Comment : References to messages from the RDF interest group are noted {Author N#} for november postings, {Author D#} for december postings, where # is the number of the message (Compare Chapter 3). The base references to the november/december discussion groups are stored in the References section [9,10].

RDF Schema / Namespace support

One of the next steps in designing the RDF API standard is an API for manipulating RDF schemata for model definition and validation. Methods for usage of namespaces should also be included. The approaches of Sergej Melnik in his API Implementation may be a good start for an discussion.

Model Versions

The concept of model versions was discussed by the interest group (Compare 3.1) but not integrated into the first API standard. In later versions of the API standard, classes / methods supporting model versioning may be published.
Versioning of models could be performed based on the way proposed in{Beged-Dov D26}. The lifecycle for a model would look like this (Picture 3).

Picture 3) Open / Closed Models and Model Versioning

An open model may be modified at will. When the model is suitable for usage, it is closed. At time of closing, validation of the model is performed. A new Model version may be created (at the author’s option) and stored in a repository to enable access to older versions later.
A closed model is only accessible for reading. When changes are to be made, the model is opened again.

There are possible modifications to that process :

• It is possible to skip the closed phase. Queries to the model go to the last version created. When skipping the closed phase, an editable model is always available.
• It may not make sense an open model is not readable, especially if no versions are created. It could be an option for the designer whether an open model can be queried somehow.

• Model getModelVersion (in Version : Integer) which retrieves the given version of the model.
• Boolean getModelStatus () returns true for open or false for closed.
• Integer getCurrentVersionNumber returns the last versionNumber.
• void newVersion (in NewVersionNumber : Integer) saves a new version of the model ; if no number is given, number is last number+1.
• void open() openes the model.
• void close() closes the model.

References

[2] Brickley, D. ; Guha, R. V. : „Resource Description Framework (RDF) Schema Specification“.
Online : http://www.w3.org/TR/PR-rdf-schema 29.1.2000.

[3] W3C : „SiRPAC“.
Online : http://www.w3.org/RDF/Implementations/SiRPAC 29.1. 2000.

[4] Apparao, V. ; Bryne, S. ; Champion, M. ; Isaaks, S. ; Jacobs, I. ; Le Hors, A. ; Nicol, G. ; Robie, J. ; Sutor, R. ; Wilson, C. ; Wood, L „Document Object Model (DOM) Level 1 Specification“.
Online : http://www.w3.org/TR/REC-DOM-Level-1 29.1. 2000.

[5] Waterson, C. : „rdf : back-end-architecture“.
Online : http://www.mozilla.org/rdf/back-end-architecture.html 29.1. 2000.

[6] Melnik, S. : „Generic Interoperability Framework“.
Online : http://www-diglib.stanford.edu/diglib/ginf 29.1. 2000.

[7] Melnik, S. : „RDF Schema Support in GINF“.
Online : http://www-diglib.stanford.edu/diglib/ginf/rdf-schema-in-ginf.html 29.1. 2000.

[8] Daniel, R. : „A proposal for an RDF API“.
Online : http://www.mailbase.ac.uk/lists/rdf-dev/1999-06/0002.html 2.1. 2000.

[9] W3C : „www-rdf-interest@w3c.org from November 1999“.
Online : http://lists.w3.org/Archives/Public/www-rdf-interest/1999Nov 2.1. 2000.

[10] W3C : „www-rdf-interest@w3c.org from December 1999“.
Online : http://lists.w3.org/Archives/Public/www-rdf-interest/1999Dec 2.1. 2000.

[11] Melnik, S. : „RDF API 1.0 draft“.
Online : http://www-db.stanford.edu/~melnik/rdf/api.html 2.1. 2000.