- From: Niklas Lindström <lindstream@gmail.com>
- Date: Fri, 22 Dec 2023 15:18:01 +0100
- To: Andy Seaborne <andy@apache.org>
- Cc: public-rdf-star-wg@w3.org
On Thu, Dec 21, 2023 at 10:24 PM Andy Seaborne <andy@apache.org> wrote: > > > > On 21/12/2023 18:28, Niklas Lindström wrote: > > On Thu, Dec 21, 2023 at 5:00 PM Andy Seaborne <andy@apache.org> wrote: > >> > >> > >> > >> On 21/12/2023 15:50, Niklas Lindström wrote: > >>> On Thu, Dec 21, 2023 at 12:42 AM Gregg Kellogg <gregg@greggkellogg.net> wrote: > >>>> > >>>> I created a Draft PR [1] with some Turtle Grammar changes based on my interpretation of Andy’s concept. You can see the rendered version of the EBNF via GitHack [2]. > >>>> > >>>> As I noted, the change to the “annotation” production makes it context-sensitive, as an LL(1) parser would get confused when seeing the IRI/BlankNode that could either identify the triple occurence or be a predicate annotating the annotation, which requires the parser be able to backtrack. Not really a problem for more modern parsers, but a notable divergence. Other alternatives in the grammar could eliminate this at the cost of being less intuitive. > >>> > >>> For naming annotation occurrences, I think it's best to allow either > >>> predicateObjectList: > >>> > >>> <s1> <p1> <o1> {| dct:source <x> |} . > >>> > >>> or iri or BlankNode. Not sure how to do that nicely; I've previously > >>> suggested [1] (some use case examples at [2]): > >>> > >>> <s1> <p1> <o1> {_:a1} . > >>> _:a1 dct:source <x> . > >> > >> Have an explicit name in annotation syntax is covered by > >> > >> :liz :spouse :dick {| id:1 | :start 1964; :end 1974 |} . > >> > >> (it's ambiguous for a lookahead of one in LL but it seems to me to be > >> more consistent in style c.f. << N | :s :p :o >> > > > > Yes; but it's this that I think is inconsistent with how Turtle > > doesn't allow both BlankNode and blankNodePropertyList, but either/or. > > The explicit name for triple terms is another thing, and I see the > > need for it there (it's more like naming a graph, but really not, I > > know). > > Yes, we could drop having an accessible name in annotation syntax. We could, but I do think there is a huge value in being able to name the occurrences using its terse form of both asserting and annotating. I did a short writeup of an example scenario with an analysis of where I think we are at with syntax, and what could perhaps be improved: https://gist.github.com/niklasl/94df648c0767e206456cc4857baecac0 Best regards, Niklas > Andy > >
Received on Friday, 22 December 2023 14:18:34 UTC