Nested descriptions in Turtle (Re: Consolidating triple/edges)

On 21/12/2023 19:28, Niklas Lindström wrote:
> On Thu, Dec 21, 2023 at 5:00 PM Andy Seaborne<andy@apache.org>  wrote:
>> 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).

I don't consider Turtle's inabiliy to nest the descriptions of /named/ 
resources as an intended feature of the language, but more as an 
oversight. JSON-LD allows it. RDF/XML allows it, for crying out loud!

While we are at changing the syntax of Turtle, I would be happy to add 
this possibility, if only for catching up with other syntaxes... but I 
don't want to distract us from the more pressing issues here!

But anyway, I would not shy away from allowing named annotations just 
because

But I would still allow  both named and anonymous annotations.

   pa

>
> (There is the N3 way of allowing e.g. = to assign a name to blank
> nodes, but that's using owl:sameAs. I think you proposed := more
> recently though, in relation to graph terms (just in a github thread
> as I recall it)? I'm not necessarily in favour of it, but it's more
> generally applicable than just being able to both name and describe
> occurrences embedded in the annotation syntax. Just a thought.)
>
>> Generally, keeping away from single-character { } because of the use in
>> SPARQL and possible for a graph-solution is probably a good hope.
> Yes, those are good and important points. (Just noting that I have
> implemented my previous suggestions, using a EBNF-based PEG parser. So
> the annotation shorthand *can* use just curlies around IRI:s and any
> form of blank nodes. But I agree it's too easy to mix up with graph
> blocks.)
>
> I wonder if something like what I wrote below (inspired by [3]) might
> be more promising (meaning having another syntax for the annotation
> syntax; which I do personally like but I know its syntax has been
> criticized before (again, see [3]).).
>
>>> Whatever exact syntax we end up with, that design follows the regular
>>> "flat" Turtle design of allowing nested descriptions only for
>>> unlabelled blank nodes (as in blankNodePropertyList), and otherwise an
>>> identifier (iri or BlankNode) with a regular description of that
>>> occurrence.
>>>
>>> We might "bikeshed" some more going forward. Noting the old thread on
>>> this, particularly the actual *star* alternative [3]; not sure if this
>>> would work, but it could be nice:
>>>
>>>       <s1> <p1> <o1> *_:a1 .
>>>       _:a1 dct:source <x> .
> (Of course, we should land the abstract and semantics first. I just
> want to ensure it's not too late to look at syntax alterations once
> that's done.)
>
> Best regards,
> Niklas
>
> [3]:https://lists.w3.org/Archives/Public/public-rdf-star/2021Jan/0027.html

>
>
>>> Best regards,
>>> Niklas
>>>
>>> [1]:https://gist.github.com/niklasl/4f52c32ef2d888c172c8584e36c24610#proposal-rdf-star-annotation-occurrences

>>> [2]:https://gist.github.com/niklasl/2d02902b81e215b1795981df31927e9b

>>> [3]:https://lists.w3.org/Archives/Public/public-rdf-star/2021Jan/0027.html

>>>
>>>
>>>> Gregg Kellogg
>>>> gregg@greggkellogg.net
>>>>
>>>> [1]https://github.com/w3c/rdf-turtle/pull/51

>>>> [2]https://raw.githack.com/w3c/rdf-turtle/triple-term-occurance/spec/turtle-bnf.html

>>>>
>>>> On Dec 20, 2023, at 2:51 AM, Pierre-Antoine Champin<pierre-antoine@w3.org>  wrote:
>>>>
>>>> Just to concur 100% with Olaf's interpretation of Andy's email.
>>>>
>>>> On 20/12/2023 10:26, Olaf Hartig wrote:
>>>>
>>>> On Tue, 2023-12-19 at 16:39 -0800, Gregg Kellogg wrote:
>>>>
>>>> On Dec 18, 2023, at 12:47 PM, Andy Seaborne<andy@apache.org>
>>>> wrote:
>>>>
>>>> [...]
>>>>
>>>> So we have:
>>>>
>>>> Occurrence:
>>>>     << :s :p :o >>
>>>>     <<| N | :s :p :o >>
>>>>
>>>> Triple term:
>>>>    <<( :s :p :o )>>
>>>>
>>>> To be clear, a Triple term would be a type, while an occurrence is a
>>>> token?
>>>>
>>>> That's my reading as well. However, maybe someone with a more intimate
>>>> understanding of the subtleties* of the notions of a token and an
>>>> occurrence should look at this question.
>>>>
>>>> *https://plato.stanford.edu/entries/types-tokens/#Occ

>>>>
>>>> Are these fundamental in the abstract syntax? Or is the token
>>>> considered syntactic sugar for something like [] rdfx:occurrenceOf
>>>> <<( :s :p :o >>?
>>>>
>>>> When I read Andy's email, I was assuming the latter, and that's also
>>>> what my immediate reaction would be, now that you ask this question
>>>> explicitly.
>>>>
>>>> The options that I can currently think of to make tokens/occurrences an
>>>> explicit concept in the abstract syntax, would mean that we have to add
>>>> another new type of term or introduce some additional mathematical
>>>> structure that the notion of an RDF graph would have to be accompanied
>>>> with. I don't think these are very attractive options. Yet, if it
>>>> appears that there is a use for treating tokens/occurrences in a
>>>> special way in SPARQL (e.g., dedicated operators or build-in
>>>> functions), then we may have to capture them explicitly in some way
>>>> (but I don't see a need for that at the moment).
>>>>
>>>> Can a term contain an occurrence, or visa-versa? E.g. <<( << :s :p :o
>>>>
>>>> :o1 :o2 )>> or << <<( :s :p :o )>> :o1 :o2 >>?
>>>>
>>>> The latter is probably not particularly controversial, in particular if
>>>> we understand expressions of the form
>>>>
>>>>     << :s :p :o >>
>>>>
>>>> as syntactic sugar as suggested in Andy's email. Then, the shorthand
>>>>
>>>>     << <<( :s :p :o )>> :o1 :o2 >>
>>>>
>>>> expands to
>>>>
>>>>     [] rdfx:occurrenceOf <<( <<( :s :p :o )>> :o1 :o2 )>> .
>>>>
>>>> (plus, the blank node in the subject of this triple would then also be
>>>> in the subject / the object of the triple in which the shorthand is
>>>> used).
>>>>
>>>> Regarding the former, i.e.,
>>>>
>>>>     <<( << :s :p :o >> :o1 :o2 )>>
>>>>
>>>> perhaps this can also be considered (and, thus, defined) as a shorthand
>>>> notation for
>>>>
>>>>     <<( _:b :o1 :o2 )>>
>>>>
>>>> together with the addition of
>>>>
>>>>     _:b rdfx:occurrenceOf <<( :s :p :o )>> .
>>>>
>>>> into the same graph in which the shorthand is used as subject or object
>>>> of a triple. (Note that _:b is meant to be a fresh blank node
>>>> identifier that is not yet used in the document in which these things
>>>> are written).
>>>>
>>>> Would N-Triples contain both variations, or just the triple term?
>>>>
>>>> I can see how supporting both variations in N-Triples maybe appreciated
>>>> for some use cases, but it may also be confusing because it would
>>>> diverge from the current principle that every line in an N-Triples file
>>>> is a serialization of a single triple only.
>>>>
>>>> (Note that my assumption here is, again, that an expression of the form
>>>>
>>>>     << :s :p :o >>
>>>>
>>>> is really just syntactic sugar.)
>>>>
>>>> And, to James’s point, can you say << :s :p :o >> a <<( :s1 :p1 :o1
>>>> )>>; if so, would this be the same as rdfx:occurrenceOf?
>>>>
>>>> Well, by resolving the syntactic sugar as suggested in Andy's email,
>>>> this would expand to
>>>>
>>>>     _:b rdfx:occurrenceOf <<( :s :p :o )>> .
>>>>     _:b rdf:type <<( :s1 :p1 :o1 )>> .
>>>>
>>>> where, again, _:b is a fresh blank node identifier. So, the predicate
>>>> "a" (or, rdf:type) in James' triple is not necessarily the same as rdfx
>>>> :occurrenceOf.
>>>>
>>>> Annotation:
>>>>    :s :p :o {| :p :z |}
>>>>    :s :p :o {| N | :p :z |}
>>>> (the last one is fiddly in the grammar because simply writing in
>>>> ABNF is ambiguous for some parsers)
>>>>
>>>> Presumably, an annotation is on an occurrence and not on a triple
>>>> term/type?
>>>>
>>>> I assume that's what Andy is suggesting here.
>>>>
>>>> Best,
>>>> Olaf
>>>>
>>>>
>>>> Gregg
>>>>
>>>>       Andy
>>>>
>>>>
>>>> <OpenPGP_0x9D1EDAEEEF98D438.asc>
>>>>
>>>>