Re: abstract syntax and syntactic sugar

There is a role for both forms. They need their own names.

As a target for languages, it is describing the various "well-formed" 
conditions that there are, like containers or collections. (Aside: might 
that also relate to SHACL validation?)

A couple of additional points:

The basic abstract data model is the form that SPARQL interacts with at 
the moment.

N-triples has been been "the abstract data model", written down in the 
sense of "the most basic elements". I think we should keep that.

     Andy

On 29/02/2024 09:42, Pierre-Antoine Champin wrote:
> Hi all,
> 
> in another thread [1], Enrico wrote something that got me thinking:
> 
>  > A “macro” has to have anyway a syntactic definition as well in the 
> abstract syntax.
> 
> My first reaction was "of course not!", but then I think I understood 
> where Enrico is coming from.
> 
> If we consider the abstract syntax as the "data model" on which the 
> semantics is defined, then syntactic sugar or macros have no place in 
> it. It should contain only the basic constructs that the (concrete) 
> syntactic sugar and macros expand to. Note that the wording of RDF 
> Concepts 1.1 strongly hints towards this interpretation : "This document 
> defines an abstract syntax (a data model)".
> 
> If, on the other hand, we consider the abstract syntax as a syntax (!), 
> i.e. an abstraction of the different concrete syntaxes that we have, 
> then including macros in it make sense. Indeed, even though some 
> concrete syntaxes have no syntactic sugar (N-Triples), some "macros" 
> exist across multiple concrete syntaxes (collections, a.k.a. lists, have 
> shortcut notations in RDF/XML, Turtle/TriG and JSON-LD). Having a common 
> abstraction for them could be useful. (In fact, this resonates with a 
> discussion Gregg and I had during TPAC 2022 about JSON-LD's internal 
> representation).
> 
> My goal here is not to argue who's wrong or right: as explained above, I 
> see value in both positions. I just wanted to share my realization with 
> others, so that we do not talk/write past each other just because we 
> have slightly different expectations of what the "abstract syntax" 
> should or should not be.
> 
>    best
> 
> [1] 
> https://www.w3.org/mid/C97CE6FB-4CC2-4E94-91E8-6BCEC64CFCD2@inf.unibz.it
>

Received on Thursday, 29 February 2024 11:45:13 UTC