W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2011

RDF API thoughts

From: Toby Inkster <tai@g5n.co.uk>
Date: Tue, 11 Jan 2011 13:36:22 +0000
To: RDFa WG <public-rdfa-wg@w3.org>
Message-ID: <1294752982.21876.98.camel@ophelia2.g5n.co.uk>
Here are some thoughts on the RDF API draft which a recent discussion in
the #swig IRC channel helped my clarify in my head.

The current RDF API draft is really a Notation 3 API in stealth.

The current RDF API draft goes beyond the RDF data model in several
ways. I'm a big fan of the Notation 3 data model - the RDF data model
comes with various restrictions which are seemingly arbitrary. However,
for the RDF API it makes more sense for us to stick with the RDF data

Why? Firstly, packaging something up and calling it an RDF API when it
goes significantly beyond the RDF API will irritate some people.

Secondly, it will make it difficult to implement the RDF API as a layer
on top of existing RDF toolkits.

Notation 3 support should be stripped out and worked on as an extension
to the RDF API separate document. A Notation 3 API extension is almost
certainly beyond the RDFa Working Group's current charter, but that is
fine as it doesn't stop RDFa Working Group members from working on this
extension outside of RDFa WG time. The Notation 3 API extension should
probably not be Rec track, at least not until some time when Notation 3
itself is.

The only nod towards Notation 3 that the RDF API itself should offer is
to avoid making that extension difficult. In other words, don't add
normative requirements that would preclude a conformant RDF API
implementation from also supporting Notation 3.

In particular I'd like to see the following changes made to the RDF API:

1. Drop the GraphLiteral interface.

2. Allow but do not require RDFEnvironment.createTriple to throw an
exception if the triple would not be RDF compatible. (For example, if
the subject is a literal.)

3. Allowbut do not require Graph.add to throw an exception if the triple
being added is not RDF compatible.

4. Allowbut do not require DataSerializer.serialize to throw an
exception if the triple being added is not RDF compatible, or if it
otherwise cannot be serialised. (For example, some RDF compatible
triples cannot be serialised as RDF/XML because their predicate URIs
cannot be represented as a valid QName.) Possibly provide a mode for
DataSerializer objects to silently skip triples which cannot be

Other high-level changes unrelated to Notation 3 that should be made:

1. Literals are currently allowed to have both a datatype and a
language. This goes beyond even the Notation 3 data model, so I do not
see what is gained by allowing this in the RDF API. Literals should be
forced to pick a camp.

2. Drop special support for rdf:PlainLiteral. rdf:PlainLiteral is not
used much in the wild and was never intended to be - it's a datatype
used internally by OWL 2 and RIF. Adding special support for it
complicates implementations for no reason - it should be treated the
same as any other custom datatype.

3. Move terms, prefixes and profiles into the RDFa API or, better yet,
drop them altogether. They make the API harder to implement and harder
to grok while adding very little benefit. For those people who want to
use prefixes and terms, they can be implemented quite trivially in "user


4. Move or copy PropertyGroups from the RDFa API into the RDF API. The
Graph interface should have getItemsByType, getItemBySubject and
getItemsByProperty methods which return PropertyGroups or arrays of

5. Rename PropertyGroup to something like "RDFItem", "RDFResource" or
"Description", or indeed "FartWarbler" - any name you pick out a hat
will be better than the status quo.

Toby A Inkster
Received on Tuesday, 11 January 2011 13:37:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:23 UTC