- From: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Date: Wed, 20 Dec 2023 11:51:35 +0100
- To: Olaf Hartig <olaf.hartig@liu.se>, "gregg@greggkellogg.net" <gregg@greggkellogg.net>
- Cc: "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
- Message-ID: <f250b3b7-723b-43d8-94eb-c93edc16b347@w3.org>
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 >>> >>
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Wednesday, 20 December 2023 10:51:39 UTC