Awkward TriG compatibility with N3

Consider the following TriG document:

   { ex:Jack a foaf:Person }
   ex:foo { ex:Jill a foaf:Person }

Assuming the prefixes are bound, this is valid TriG 
document.  The first line puts a statement that Jack is a 
person into the default graph, and the second line puts a 
similar statement about Jill into named graph ex:foo.

But it's very nearly a valid N3 document meaning something 
quite different.  N3's formulae are conceptually much the 
same as TriG's graphs, but N3's formulae can be subject or 
object of statements.  So in N3, the following document 
makes some sort of statement (with predicate ex:foo) about 
the two formulae or graphs.

   { ex:Jack a foaf:Person } ex:foo { ex:Jill a foaf:Person } .

The only thing that stops that from being valid TriG is 
terminating '.'.  To express this in TriG we would write:

   _:a { ex:Jack a foaf:Person }
   _:b { ex:Jill a foaf:Person }
   _:a ex:foo _b

Now I can entirely understand TriG not wanting to support 
this feature of N3.  But at the same time I would be pleased 
if some future TriG-like language, maybe TriG 2.0, would 
include them because they're very useful in technologies 
like the W3C's PROV language where it's common to want to 
write:

   { ex:Jack a foaf:Person ;
             bio:birth [ dc:date "1905-01-11"^^xsd:date ] }
       prov:wasDerivedFrom [ a foaf:Document,
                             dc:title "Jack's birth certificate" ] .

So it would be nice if TriG remained compatible with N3 by 
allowing for the future possibility of such a feature.

Even though N3 is not a W3C recommendation, it (or a subset 
of it) is in use in several current products, such as cwm. 
Languages like N-Triples and Turtle are both compatible with 
N3 insofar as no valid N-Triples or Turtle document that is 
also a valid N3 document has different meanings in the 
different languages.  (They're not quite subsets of N3, but 
it would be easy enough to update N3 so that this were 
true.)  An application wishing to support N-Triples, Turtle 
and N3 may well do so with a single parser.

Strictly speaking it is also the case that TriG and N3 
because the final '.' disambiguates it, but then makes the 
grammar a long way from being LL(1) or LALR(1), as arbitrary 
look-ahead is required.  Allowing a single parser to handle 
both N3 and TriG easily is another reason why this syntax is 
problematic.


If fixing this is considered desirable, requiring a '.' 
after the closing '}' of the native (i.e. non-SPARQL) syntax 
would do this.  (This would require trival ammendments to 
grammar productions [2g] block and [3g] triplesOrGraph.) 
But it does so at the cost of breaking compatibility with 
the current (and earlier) drafts of TriG.  This has a 
pleasing symmetry with the Turtle syntax for anonymous blank 
nodes or collections:

   ( ex:a ex:b ) .
   [ a ex:class ] .
   { ex:foo ex:pred ex:bar } .

which generate the following (slightly abbreviated) N-Quads:

   <>   _:1     rdf:type   rdf:List .
   <>   _:1     rdf:first  ex:a     .
   <>   _:1     rdf:rest   _:2      .
   <>   _:2     rdf:first  ex:b     .
   <>   _:2     rdf:rest   rdf:nil  .
   <>   _:3     rdf:type   ex:class .
   _:4  ex:foo  ex:pred    ex:bar   .


Richard

Received on Sunday, 17 November 2013 19:10:08 UTC