- From: Andy Seaborne <andy@apache.org>
- Date: Thu, 21 Dec 2023 21:24:37 +0000
- To: public-rdf-star-wg@w3.org
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. Andy
Received on Thursday, 21 December 2023 21:24:45 UTC