Re: Awkward TriG compatibility with N3

Richard, thanks for your interest in TriG and your thoughts on this.

On 11/17/2013 02:09 PM, Richard Smith wrote:
>
> 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 } .
>

This is certainly an unfortunate ambiguity.

> 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.
>

Agreed.

> 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   .
>

I don't think this will work because old-style TriG parsers don't expect 
that period, and (more importantly) and old-style TriG content doesn't 
include it.    I haven't actually researched this, but I note that the 
example in the original TriG spec [1] does not include a period.   So if 
we require the period, old content wont be parsable by new parsers.

Speaking more generally, the RDF Working Group has been trying to 
balance compatibility with old-style TriG and with SPARQL, while 
generally trying to produce something useful.  I see the path forward 
toward more N3 features as going by way of the SPARQL-style syntax.   
That is, if people start to use the GRAPH keyword and leave off the 
curly braces around default graph triples, then we'll have a language 
that can be evolved toward N3.     As long as we have to be compatible 
with old-TriG, the situation is overly constrained.

Note also that the semantics of N3 are radically different from the 
semantics of TriG.    In N3 (without variables), a {...} expression is 
an RDF term that denotes a graph.  In contrast, in TriG, {...} 
expressions never occur in RDF, but instead signal a name-graph pairing 
that accompanies the default graph in a dataset.   This is one of the 
reasons I like the GRAPH keyword and hope people begin to use it 
exclusively in TriG as soon as the parsers are updated to allow it.   By 
using GRAPH, we highlight that this is a name-graph pairing, not the 
kind of thing we see in N3.

If this happens -- that people migrate to using the GRAPH keyword for 
all their named graphs, as they must in SPARQL -- then we'll be able to 
deprecate old-style TriG and add N3-like features to the language with 
more freedom.   I think that's probably the best we can do at this 
point, given what's already out there with TriG.

Thanks again for your comment.  If this response is sufficient, please 
reply with "[RESOLVED]" in the subject line.

     -- Sandro   (on behalf of the RDF Working Group)

[1] http://wifo5-03.informatik.uni-mannheim.de/bizer/trig/

Received on Wednesday, 20 November 2013 17:13:29 UTC