- From: Vivien Kraus <vivien@planete-kraus.eu>
- Date: Mon, 13 Nov 2023 17:19:22 +0100
- To: William Van Woensel <william.vanwoensel@gmail.com>
- Cc: public-n3-dev@w3.org
Thank you for your answer, William! Le lundi 13 novembre 2023 à 08:34 -0500, William Van Woensel a écrit : > > On Nov 12, 2023, at 5:38 PM, Vivien Kraus <vivien@planete-kraus.eu> > > wrote: > > > > Dear Notation-3 authors, > > > > In the process of implementing Solid, I am starting with a > > Notation-3 > > parser. I made good progress, however I am still puzzled about a > > few > > aspects of the specification. > > > > I intended to use the same parser for both Turtle and Notation3, > > but > > the incompatibility between N3 collections and RDF collections is > > worrying me a bit. It is not explicitely incompatible, but I wonder > > what would happen if a N3 PATCH request were to modify a RDF > > collection > > with a N3 syntax. This is a purely hypothetical problem right now, > > as > > Solid won’t accept blank nodes in PATCH requests. > > > Note that in the N3 spec, N3 collections are more than RDF > collections with an easier syntax - they are terms in their own > right. The original member submission describes the latter as a > reification of the former, and shows how extra axioms can make N3 and > RDF collections equivalent. This is not a big problem, but I love the idea of streaming triples. It is at the heart of the Turtle parser. If I have to wait for a large closed collection to be parsed, then it defeats the purpose I guess. > > I am leaning on the Turtle specification to know how to parse a > > stream > > of triples. I believe the parser state and productions described in > > the > > Turtle document could be adapted to Notation3 by simply recording > > the > > current formula and adjusting for pathes, but I may be missing > > something still. > > > (I am assuming you are aware of the N3 grammar and its EBNF format). > Regarding parser state, I used ANTLR to generate an N3 parser for > jen3 (an N3-extended version of Apache Jena) and construct > corresponding “N3Models” in the N3GraphInserter class. Maybe this can > give you some ideas for your own parser (but, possibly some of the > complexity there is no longer needed, as we are now avoiding explicit > quantification(. Note that the spec also has some algorithms for path > parsing, which can be quite tricky IMO - path resolution is also > implemented in that class. > > > I use a yacc/bison-like parser generator. It is possible to produce > > the > > triples (quads if we are working with formulas) in the correct > > order, > > but it requires overloading the IPLSTART, [, ( and { terminals with > > non-terminals (to mint the new node early) and make sure the triple > > with the new node is emitted only once. I also had to create a > > couple > > extra nonterminals to clear the state for path resolution. The > > formulaContent rule is hard to translate to yacc/bison, because of > > the > > separation dot after n3Statements. The rule for a collection is > > also > > hard to translate. I managed to bypass both problems by adding new > > rules. > > Unsure what particular issues you ran into. Maybe the n3.g4 file that > I created for ANTLR can help. I should have started by describing my approach first, sorry. The run-time library of my favorite programming language [Guile] has a built-in parser generator for (PEG and) LALR grammars, but not for LL grammars. I believe the Notation-3 grammar is LL. So, I want to convert the Notation-3 grammar to LALR first. It can be done with a few extra rules. If done naively, the triples that are produced when creating a new IRI / blank node property list / collection are emitted last, rather than first. I would guess that it is linked to the difference between LL and LR parsing, but I am in no way an expert on these subjects. However, the emission order can be fixed by overloading the IPLSTART / [ / ( non-terminals to emit triples early. This trick is described as an alternative to "Mid-Rule Actions" in [Bison]. [Guile] https://www.gnu.org/software/guile/manual/guile.html#LALR_00281_0029-Parsing [Bison] https://www.gnu.org/software/bison/manual/html_node/Mid_002dRule-Action-Translation.html#Mid_002dRule-Action-Translation > > > Other than that, I am not sure what the verb keywords "has > > expression", > > "is expression of" and "=" mean. I guess "is expression of" is the > > same > > as "<-". Maybe "has expression" is the same as "expression"? I > > don’t > > know for "=". > > The “=“ is a shorthand for owl:sameAs (I believe this was copied from > turtle) - you are right that it does not seem to be documented :-( That seems obvious now that you said it, thanks! > The "is … of” production is described in the EBNF grammar section: > > "The original N3 grammar allowed the inverting of a property by using > the @is .. @of construct. But, this construct can be unintuitive when > property names are more verbosely specified (e.g., :hasFather), > leading to statements such as ?x @is :hasFather @of ?y. The is ... > of construct is still supported, but the above statement can now be > represented as follows: ?x <- :hasFather ?y.” That was my guess, but I wanted clarification for the @ prefix. Thank you! What about "has"? I can read that section “C. Changes since the Team Submission” lists the “Removed @has.” item (not renamed to “has”, but really removed, as opposed to @is .. @of which has been renamed). However, “has” is still in the grammar. > > In section Relationship to Other Languages, Turtle (5.1), you write > > about these keywords: > > > > All keywords can be optionally preceded by "@", for consistency > > with the "@prefix" and "@base" keywords. > > > > I am not sure this is reflected in the grammar. > > You are right, this statement is outdated - we chose to leave out the > “@“ prefixes from the grammar. OK. Vivien
Received on Monday, 13 November 2023 16:18:55 UTC