Re: Consolidating triple/edges

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