Summary

Cambridge Semantics believes that a new W3C RDF Working Group with a limited scope would be very beneficial to current consumers and vendors of Semantic Web technologies, while providing marginal benefit in broadening the community of Semantic Web practitioners. We believe that a rechartered Working Group would be best served by performing the following functions:

The remainder of this position paper provides details and rationale for each of these items.

Existing RDF Specifications

RDF adoption over the past decade has continued slowly and steadily. It would be a mistkae to introduce any changes to the specifications at this point that would result in currently conformant applications becoming non-standard. It would also be a mistake to extend the core RDF model in revolutionary ways that are not already well-established in the marketplace.

On the other hand, there are elements of the current RDF specifications that are little used and poorly understood and could be deprecated as an indication that they are areas of the specifications that are best avoided. This deprecation could go hand-in-hand with appropriate best practices "recipes" (see below) to aid new adopters of RDF in alternative approaches to the deprecated features. Candidates for deprecation occur:

Named Graphs

A substantial number of RDF databases, frameworks and programming environment extend RDF's basic triple model. Some move from triples to five or six or even more elements; but by far the most common extension is to add a fourth component to an RDF statement. The fourth component is known sometimes as a context or simply a quad, but most commonly it is referred to with the name that the SPARQL RDF Dataset model gives it: a named graph.

Cambridge Semantics's Anzo Semantic Platform is based entirely on named graphs. Anzo uses named graphs to group related RDF triples and provide services including:

While SPARQL defines an RDF Dataset that can contain zero or more named graphs, it does not specify the semantics of named graphs in terms of interpretations, entailments, etc. Specifying the semantics of named graphs will add legitimacy to a common extension of the RDF model, and will ensure that different implementations treat named graphs in like ways. It will also help ensure that the SPARQL model is treated in a uniform fashion by different RDF databases, and it will provide a foundation for other Semantic Web standards to define their behavior in the presence of named graphs.

A likely starting point for these semantics is Named Graphs, Provenance and Trust by Carroll, Bizer, Hayes, and Stickler.

Serializations

While specifying the semantics of named graphs is a foundational step to achieving interoperability, Cambridge Semantics believes that standardizing commonly used RDF serializations is the single most important task that a new W3C RDF Working Group might take on. In particular, Cambridge Semantics advocates for standardization of these two serializations:

  1. Turtle. Turtle is the most accessible serialization of the RDF model. It is easy to understand, easy to parse, easy to produce, and easy to teach. More and more examples, tutorials, and other collateral about RDF are expressed in Turtle, despite the lack of standardization. Standardizing Turtle would give a stable specification and test cases, and would help improve the ubiquitous availability of Turtle parsers and writers in RDF systems.
  2. TriG. TriG is Cambridge Semantics's preferred serialization of named graphs. It is a simple extension of the Turtle serialization that is easy for both systems and humans to produce. TriG provides a convenient serialization to exchange multiple RDF graphs between systems for tasks such as synchronization, update (deltas), and forward-chained reasoning.

Education and Best Practices

Neither the Semantic Web Education and Outreach group nor the Semantic Web Best Practices group are currently active. A new RDF Working Group would have a strong position to publish educational materials for working with RDF. As noted above, this might include best practice replacements for deprecated features. It might also include: