Re: Consolidating triple/edges

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> .

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> .

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>
>
>

Received on Thursday, 21 December 2023 15:51:12 UTC