Triple abbreviations

Turtle has the ability to abbreviate triples by omitting duplicate subjects and subject/predicate pairs. This has the advantages of:

• Saving space
• Reducing the number of URIs that humans have to read
• Encouraging related properties to be grouped together

URI abbreviations

Long, duplicated, URIs are so common in RDF that a human-readable RDF syntax needs some capability to abbreviate URI prefixes.

I’m ruling out the use of QNames in content, so one option is to invent an application-level syntax for declaring prefixes.

But, why add complexity when XML already natively supports ENTITY declarations via an internal DTD subset... So, the proposal is to encourage the use of entities where abbreviation is required.

I’ve been doing some more work on my proposed alternative RDF syntax. I’ve made quite a few changes to the schema, and finally implmented an XSLT that converts from the new format to RDF/XML.

I’m also working on a process for converting from an RDF graph to the new syntax. Obviously, I can’t do this in XSLT (If RDF/XML was XSLT processable, I wouldn’t be doing this project!), so I’m implementing this process in Java using Jena at the moment.

The changes to the schema aren’t all that interesting, but there is a reason behind most of them:

• The regexps have been improved so that URIs are restricted to absolute RDF URI-Refs; nodeIds are restricted to "_:" followed by an NCName, restricted to the ASCII character-set.
• The container syntax has changed to use a fixed enum of container types. This is to provide a more uniform representation for containers that have multiple rdf:types. This still needs some work.
• The syntax for unasserted reified statements was broken before (it allowed multiple predicates and objects be nested beneath the single subject, which caused all of those statements to have the same stmtId). It has now been improved by moving stmtId to the <o> tag, so that multiple statements can now be nested and still all have unique stmtIds.
• Indexes have been removed from container items. I decided that this was too much of an edge case. So, now, sparse lists and other funky lists, have to be written out long-hand. I don’t think that this is too much of a disadvantage, because these funky lists would be hard to process using XSLT anyway.
• The id for collections has moved from the declaration itself, to a seperate listId attribute on each item. I was going to add a listId anyway, so that the list nodes could be referenced, and if I’m doing this, it makes the id on the <d> element redundant because it serves the same purpose as the listId on the first element in the list.

All of the links are here .

Currently the schema only supports xml:lang on the the <o> element. The alternative is to support xml:lang everywhere, to allow it to be inherited, but to simplify processing, I’m avoiding this at the moment.

xml:base is not supported anywhere in the schema. I think that this might be the right decision. xml:base is tricky to support in XSLT 1.0 (although I have implemented support for it as part of my Atom/RDF project).

What’s wrong with RDF/XML?

RDF is a very unusual XML vocabulary. It starts from the premise that graphs are a superset of trees, and then tries to get as much of the graph model into XML’s hierarchical structure as possible, then uses hyperlinks (via rdf:ID, rdf:resource, etc), to handle the rest. Whilst this seems a reasonable approach for humans, it doesn’t work so well for machines. It leads to a syntax so variable that it’s superficial resemblance to XML is more of a hazard than a benefit to human-authorability. Admittedly human-authored RDF/XML is one of most concise, and human-readable XML syntaxes possible for RDF, but the same can’t be said about machine-readability. Whilst an XML syntax such as Atom is simple to process using an off-the-shelf XML parser, and a small amount of code; an RDF/XML parser is an unbelieveably complicated piece of software.

Rather than use a single tag to represent a resource, with an attribute to represent the URL or id; RDF/XML embeds the URI or id in the tag name itself by (ab?)using XML Namespaces. This might be concise, but it is not particularly compatible with general purpose tools such as XML validators. Namespaces weren’t designed as a generic URI compression technology, and it shows. Due to the limitations in the character-model used by localNames, there exist many URIs that can’t be decomposed into an nsUri/localName pair, and there is no way to write predicates in RDF/XML other than as nsUri/localName pairs. This makes it impossible to serialise graphs containing predicates that end in ‘/’ or ‘#’ to RDF/XML, even though they are valid in the RDF model, and can be serialised to other syntaxes.

For me though, the biggest frustration with RDF/XML stems from the fact that despite being an XML syntax, it is impossible to use XML tools such as XSLT to process it. I want an XML syntax that is processable by humans, dedicated RDF tools, and generic XML technologies such as XSLT.

Do we need to base the syntax on XML?

Turtle is a great RDF syntax that isn’t XML-based. It is probably more human-readable than the syntax that I am currently working on, but I still think that that there is a need for a decent, human-readable XML-based syntax.

XML isn’t without issues:

Verbosity

The Turtle syntax is designed for humans to read, XML is designed for machines to read. No XML syntax is ever going to approach the aesthetics of Turtle.

Poor support for inline binary content

However, this isn’t such a big deal for RDF, as the RDF model also has poor support for binary content.

Problematic MIME-types

The interactions between XML, RFC3023, the MIME RFCs, and HTTPs almost-but-not-quite-MIME encapsulation are well-known.

Despite these issues however, XML has such a massively deployed infrastructure, and there are lots of good reasons for prefering an XML based syntax for RDF:

Widely deployed XML parsers: SAX, DOM, StaX, etc...

An XML base makes it easy to write parsers for simple XML-based RDF syntaxes. A variety of parser models are available.

XSLT, XPath, XQuery, XInclude and XProc

Technologies such as XSLT allow not only the data to be easily portable across platforms, but the code as well. And the performance of XSLT is good enough for Microsoft to use it for the RSS/Atom normalization in Windows/IE7’s Feed Platform.

Validation

DTDs may be pretty feeble, and XSD may be a monster, but RelaxNG is great. Validation is important, and validation technologies for XML are prevalent.

Is it worth making a new syntax?

When the subject of Binary XML gets raised, it usually gets some push-back. This is probably because, all that XML standardizes is a syntax; once you diverge from the XML 1.0 serialisation, there isn’t much left (OK, there is the the Infoset, but it’s not a very usable application model) . With RDF however, because all interoperability is at the RDF model layer, and because the model is so simple, it is feasable to use different syntaxes. Although RDF/XML is the only syntax blessed by the W3C Recommendations; other syntaxes such as N-Triples , N3 , Turtle , TriX , RXR , and TriplesML exist without seriously fragmenting interoperability. Of course part of the reason why these other syntaxes exist is because of the serious problems with RDF/XML.

Anyway, I’ve got a RelaxNG schema, some XSLTs, and documentation of the design decisions, which I will post here later, but in the meantime, here is a quick teaser — the feed from the RSS 1.0 examples , converted to my proposed syntax:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rdf [
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!ENTITY rss "http://purl.org/rss/1.0/">
]>

<rdf xmlns="http://djpowell.net/schemas/treetriples/1/">

  <s id="http://www.xml.com/xml/news.rss">
    <p id="&rss;link">
      <o>http://xml.com/pub</o>
    </p>
    <p id="&rss;title">
      <o>XML.com</o>
    </p>
    <p id="&rss;items">
      <o id="_:b0" />
    </p>
    <p id="&rss;description">
      <o>XML.com features a rich mix of information and services 
      for the XML community.</o>
    </p>
    <p id="&rss;textinput">
      <o id="http://search.xml.com" />
    </p>
    <p id="&rdf;type">
      <o id="&rss;channel" />
    </p>
    <p id="&rss;image">
      <o id="http://xml.com/universal/images/xml_tiny.gif" />
    </p>
  </s>

  <s id="http://xml.com/pub/2000/08/09/xslt/xslt.html">
    <p id="&rss;link">
      <o>http://xml.com/pub/2000/08/09/xslt/xslt.html</o>
    </p>
    <p id="&rss;title">
      <o>Processing Inclusions with XSLT</o>
    </p>
    <p id="&rss;description">
      <o>Processing document inclusions with general XML tools can be 
     problematic. This article proposes a way of preserving inclusion 
     information through SAX-based processing.</o>
    </p>
    <p id="&rdf;type">
      <o id="&rss;item" />
    </p>
  </s>

  <s id="http://xml.com/pub/2000/08/09/rdfdb/index.html">
    <p id="&rss;link">
      <o>http://xml.com/pub/2000/08/09/rdfdb/index.html</o>
    </p>
    <p id="&rss;title">
      <o>Putting RDF to Work</o>
    </p>
    <p id="&rss;description">
      <o>Tool and API support for the Resource Description Framework 
     is slowly coming of age. Edd Dumbill takes a look at RDFDB, 
     one of the most exciting new RDF toolkits.</o>
    </p>
    <p id="&rdf;type">
      <o id="&rss;item" />
    </p>
  </s>

  <s id="http://xml.com/universal/images/xml_tiny.gif">
    <p id="&rss;link">
      <o>http://www.xml.com</o>
    </p>
    <p id="&rss;title">
      <o>XML.com</o>
    </p>
    <p id="&rss;url">
      <o>http://xml.com/universal/images/xml_tiny.gif</o>
    </p>
    <p id="&rdf;type">
      <o id="&rss;image" />
    </p>
  </s>

  <s id="http://search.xml.com">
    <p id="&rss;link">
      <o>http://search.xml.com</o>
    </p>
    <p id="&rss;title">
      <o>Search XML.com</o>
    </p>
    <p id="&rss;description">
      <o>Search XML.com's XML collection</o>
    </p>
    <p id="&rdf;type">
      <o id="&rss;textinput" />
    </p>
    <p id="&rss;name">
      <o>s</o>
    </p>
  </s>

  <d parse="seq" id="_:b0">
    <o id="http://xml.com/pub/2000/08/09/rdfdb/index.html" />
    <o id="http://xml.com/pub/2000/08/09/xslt/xslt.html" />
  </d>

</rdf>

I’ve put some links to related content at the Namespace URI: http://djpowell.net/schemas/treetriples/1/

# RELAX NG Compact Syntax Grammar for proposed RDF/TreeTriples syntax
# EXPERIMENTAL!
#
# David Powell - 2006-11-24

default namespace = "http://djpowell.net/schemas/treetriples/1/"

# Common attributes

start = rdf
## Root rdf element contains a list of triples and declarations.
rdf =
   element rdf {
      s* & d* & dstmt?
   }


## A triple is declared by creating an 's' element for the triple's
## subject, and nesting 'p' and 'o' elements inside for the predicate
## and object of the triple.  Multiple 'p' and 'o' elements can be
## nested, effectively abbreviating the common case of many statements
## with duplicate subjects, or subject/predicate pairs.
## Triples sharing the same subject MUST be represented with a single
## 's' element.
s =
   element s {
      attribute id { id },
      p+
   }

## A predicate for the parent node's subject.  Triples sharing the same
## subject and predicate MUST be represented by a single nested 's' and
## 'p' element.
p =
   element p {
       attribute id { uri },
       o+
   }

## An object which forms a triple with the grandparent node's subject, and
## the parent node's predicate.
o =
    element o {
      ## A statement id can be used to create an rdf:Statement structure
      ## corresponding to an asserted statement.
      attribute stmtId { id }?,
      (
          (attribute id { id }, nocontent) |
          literal |
          parseXml
       )
    }


## Literals can be typed, or have a language.  For XML literals, the special 
## special 'parseXml' form MUST be used.
literal = 
    (
        attribute xml:lang { lang }? |
        attribute datatype { uri }?
    ),
    text

lang =
    xsd:language

## ids may represent nodeIds for bnodes, or URIs for resources.
id =
    nodeId | uri

## A nodeId is a document-scoped label for a bNode.  nodeIds must
## start with the characters "_:", followed by an NCName, restricted to 
## ASCII characters
nodeId =
    xsd:Name { pattern = "_:[a-zA-Z_][a-zA-Z0-9.\-_]*" }

## An absolute RDF URI.  URIs will never start with the string "_:", which
## is reserved for bNodes.
## MUST be an absolute IRI..
## Leading and trailing spaces MUST NOT be present.
uri =
    xsd:anyURI
	
## Represents an XML literal.  The 'o' element and its attributes are not
## part of the content.  The contained elements are expected to follow the
## same rules as RDF/XML XML literals.
parseXml = 
   attribute parse { string "xml" },
   (text|anyElement)*

anyElement =
   element * {
      (attribute * { text }
       | text
       | anyElement)*
   }

nocontent = string ""

## Declarations provide a sane way of declaring lists, containers,
## and un-asserted, reified statements.
d = 
    element d {
       parseList |
       parseContainer
    }

## Only one un-asserted reified statement block is allowed, but it can
## contain many statements.
dstmt =
    element d {
       parseStatement
    }

## Represents an RDF collection.  The 'id' of the collection may be represented
## by a 'listId' attribute on the first member 'o' element.
## empty collections are supported.
parseList = 
   attribute parse { string "list" },
   collectedo*

## Represents an RDF container.  The URI represents the container type, which
## is assumed to be a subtype of rdfs:Container.  The attribute value:
## container indicates that none of the explicit types are stated.
## empty containers must use SPO syntax.
parseContainer = 
   attribute parse { string "seq" | string "alt" | string "bag" | string "container" },
   attribute id { id },
   containedo+

## Represents un-asserted, reified statements.
parseStatement = 
   attribute parse { string "statement" },
   s+

## NOTE there is no special support for reified containers, collections, or statements.

## Objects in containers can't contain a stmtId.
containedo =
    element o {
      (
          (attribute id { id }, nocontent) |
          literal |
          parseXml
       )
    }

## Objects in collections can't contain a stmtId, but can contain a listId to
## allow the list nodes themselves to be referenced.
collectedo =
    element o {
      attribute listId { id }?,
      (
          (attribute id { id }, nocontent) |
          literal |
          parseXml
       )
    }

Ok, I finally decided to give ‘newrdfsyntax’ a name. It’s now called ‘treetriples’ . I also took the opportunity to change the URLs on the site, and to change the namespace to http://djpowell.net/schemas/treetriples/1/ .

The rationale, and spec isn’t too far behind either.

Thanks to the include support that I added to my strange batch blog publishing thing, and thanks to Vista’s symlinks, I have changed the entries that contain inline examples and schemas to include the latest versions from CVS. Cool.

I tried using hard-links to organize web publishing on Windows XP, but they don't work so well, cause any app that implements ‘save’ by moving a temp file over the original breaks the hard-link.