-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
N-Triples* #16
Comments
Are you suggesting to add another section into the draft, parallel to the section that defines Turtle*? |
Should probably extend to N-Quads* and TriG*, given the dataset implications. Don't know that a separate sub-section for each is warranted. |
N-triples* and N-quads* do indeed make sense, as they are "raw" syntaxes, that could be used in test suites, as @afs points out. TriG* could be left "as an exercice for the reader", IMO, although of course it would be nicer to specify it explicitly. |
Only if we can rely on N-Quads to specify if a quoted triple used with a named graph is asserted to be in the same named graph, or in the default graph. And, that there is no such thing as a quoted quad, or not. |
In the current proposal, SA mode is the norm, i.e. |
Even in SA mode, it’s important to know what triple is asserted, as it may appear (or not appear) in multiple graphs. |
SA would be restricted to same-graph triples. |
@afs I completely agree that ntriples-star should be specified in the spec. But it's not obvious to me what do you propose for syntax. Could you give an example? |
The |
I think it's basically the restriction on Turtle* to have only
Note that this does allow for recursion on Arguably, embedded triples could have their own identifiers, to keep N-Triples* as a true triples format, but the added complexity this entails is probably not worth it. |
If N-Triples* preserves the "one-triple, one line" feature, then it is like SA mode. A recursive |
The N-Triples* grammar could be extended for N-Quads*, but it would still contain |
Sorry @gkellogg, but I don't see what you mean. Recall that we settled on SA mode for the In other words, in TriG*, the two graph below make assertions about the same triple, which does not "belong" to any graph in particular.
At least, that's how I see things, given the way the abstract syntax of RDF* datasets is defined. |
This is precisely why this needs to be clarified. The only way to satisfy your assertion, which makes sense, is that the triple is asserted in the default graph. That had been my interpretation, but seems at odds with other comments in the thread. It also means that there is no way to assert anything about a triple within a named graph. |
The main characteristics of ntriples that make them useful for command line processing are
Is there a way to design ntriples-star to conform to the same? |
I'm assuming that Trig* will have the |
There is a defined canonical form TR/n-triples/#canonical-ntriples. If |
Totally agree with @afs . However, it is true that parsing N-Triples*, even in canonical form, is significantly more complex than N-Triples. In particular, the recursive nature of embedded triples rules out regular expressions, I believe. |
N-Triples fulfills the role of database dump format. As such it might be useful to define N-Triples* as exactly what is in the database, with only the
<< >>
syntax (no annotation support as in issue #9) and without the automatic generation of the implied triple for<< >>
. This preserves the one line - one triple feature of N-Triples found in the wild.This would also make it a format for writing tests for Turtle*.
The text was updated successfully, but these errors were encountered: