Up to Design Issues

The Future of RDF

Today (2010-06-26) and tomorrow, and workshop is about to take place about the future of RDF. Whilst the scheduling of the workshop did not allow me to participate directly, I summarize here my probably well-known views about some aspects of the future of RDF at the bottom level. This does not address the many other exciting things which need to be done in the semantic web, but just the RDF model and its common serializations.

Cleaning up the RDF model

1. Deprecate the form of reification in the RDF/XML spec.
2. Deprecate the bags and sequences from the RDF/XML spec, and produce a new document without it
3. Produce a new RDF/XML document without the deprecated features
4. Produce a new spec or perhaps tutorial which defines the model separately from any specific serialization, with examples from Turtle and maybe RDF/XML
5. In the RDF model, add the ability of the subject to take any of the forms allowed for the object. Currently, this means including literals
6. In RDF/XML, extend the syntax so that a collection can be incorporated anywhere any subject or object.
7. Define a common JSON serialization.

How strong should the deprecation be? One possibility is for them to be just best practice notes. It will have the great advantage of simplifying the documentation. A transitional possibility for Sequences may to have them converted to lists as a parser option, for systems which handle lists and don't handle sequences.

Extending the RDF model to allow N3

1. In RDF/XML, extend the syntax so that a graph can be incorporated anywhere any subject or object.
2. Extend the RDF model so that variables can take the place of S P or O. Use the N3 model that, to allow nested graphs, the scope of quantification of a variable can be given explicitly.

Extensions to the RDF model should be done consistently with N3 to avoid unnecessary incompatibility.

Extending N3

1. Syntax: Allow naked literal (limited, absolute, UTC) date-times in W3C standard format e.g. 2010-06-26 or 2010-06-26T12:04Z. (This format is distinguishable from other numeric forms. Date-times are a common and important datatype and reading and writing them with an explicit datatype is boring. In practice people end up putting them in data on the web as strings which prevents processing software and user agents providing appropriate functionality)
2. A syntax for quote variables is necessary in order to write SPARQL conveniently in N3. In SPARQL at the moment one can write SELECT ?x, ?y WHERE ... where the variables are implicitly quoted. To represent that in N3 model needs a form of back-quoting to indicate that the variables are being mentioned rather than used. [ select ( `?x `?y ); where { ?x foo:bar ?y } ... ]

Ontologies on top of N3

1. Merge N3 rules and AIR rules, to make one common language. AIR rules are written in N3 but use a different ontology, The rules are more complex, and as they are nodes in the graph they can be given URIs and so extended, unlike N3's { ... } => {... } which are single statements. Note this is not a change to N3. N3 rules and AIR are both ontologies which use the N3 model.

Extending N3 Including RIF features

1. Extend the N3 model to allow the direct expression of Nary functions. Define the mapping of cwm-style "Binary function of Argument list" Nary functions as reifications of new Nary functions.
2. Extend N3 syntax to allow infix operator expressions and operator precedence.

Up to Design Issues

Tim BL