- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 20 Nov 2013 12:13:21 -0500
- To: Richard Smith <richard@ex-parrot.com>, public-rdf-comments Comments <public-rdf-comments@w3.org>
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