W3C home > Mailing lists > Public > semantic-web@w3.org > December 2012

Well Behaved RDF - Taming Blank Nodes, etc.

From: David Booth <david@dbooth.org>
Date: Wed, 12 Dec 2012 12:01:00 -0500
To: semantic-web <semantic-web@w3.org>
Message-ID: <1355331660.2301.3287.camel@dbooth-laptop>
I'm writing a paper to propose a profile of RDF that would enable
simpler tools to process RDF, and I'm wondering if others have
suggestions of constraints that may be helpful to include.  The idea is
not to change the RDF standard, but to define a useful, voluntary subset
-- Well Behaved RDF -- that is sufficient for most RDF applications but
simplifies their development.

For example, one key limitation would be in the use of blank nodes,
which severely complicate what could otherwise be simple tasks, such as
comparing two RDF graphs for equality.  With unrestricted blank nodes,
this becomes a difficult graph isomorphism problem instead of a simple
text comparison.  Some have suggested eliminating blank nodes entirely,
but a more modest restriction would be to limit them to common idioms
that do not cause such complexity problems:

  A Well-Behaved RDF graph is an RDF graph that can be serialized 
  as Turtle without the use of explicit blank node identifiers. 
  I.e., only blank nodes that are implicitly created by the 
  bracket "[ ... ]" or list "( ... )" notations are permitted. 

Are there other restrictions that would be helpful to have in a Well
Behaved RDF profile, which would simplify our lives as RDF developers,
but still meet the needs of most RDF applications?  For example, what if
anything might be said about non-lean RDF graphs?  Should typed literals
be required to be well formed per their type semantics?  Should the use
of rdf:first and rdf:rest be limited to well-formed, rdf:nil-terminated
lists, i.e., those that can be serialized as Turtle lists “( . . . )”?
Etc.  What do others think?

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Wednesday, 12 December 2012 17:01:33 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:31 UTC