Re: Adjusting the suggested RDF-star naming notation

On 22/04/2024 15:22, Niklas Lindström wrote:
> Since adding named occurrences to the RDF-star syntax is fairly agreed
> upon (arity aside), I've raised the above issue at [1].
> 
> Now that we see implementers beginning to adjust to it [2], is it time
> to begin finalizing syntax before it becomes too costly to fix?

We need to make a good attempt to change it once.

> I know
> we have important semantic questions to solve, but if we let this
> "detail" slide, usability and comprehension will be hurt anyway. (And
> some of us "comprehend" just as much through syntax, so every change
> can hurt communication.)

We also need to reassure ourselves that all the intermediate decisions 
and compromises still hold. We didn't all have the same viewpoint at 
various gating points.

> 
> Best regards,
> Niklas
> 
> [1]: <https://github.com/w3c/rdf-star-wg/issues/116>
> [2]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Apr/0138.html>

is about Turtle.

> 
> On Thu, Jan 18, 2024 at 11:28 AM Niklas Lindström <lindstream@gmail.com> wrote:
>>
>> Given the possible convergence on named occurrences (as reification),
>> adding naming to the RDF-star syntax is great.
>>
>> Unfortunately, the naming notation doesn't work well in SPARQL, as it
>> collides with the use of `|` as the AlternativePath operator [1]:
>>
>>      SELECT * { ?s ?p ?o {| dct:issued | dct:modified "2023" |} . }
>>
>> (The above already means "select any triples with annotations issued
>> or modified in 2023", and thus cannot be used for "with the annotation
>> denoted by dct:issued, modified in 2023". Try it out in [2].)
>>
>> Of course Turtle is not SPARQL. But it has been designed in part with
>> the intent of being easy to copy-paste from when writing SPARQL (hence
>> the added support for SPARQL-style prefixes and base when Turtle was
>> standardized).
>>
>> (I also wouldn't rule out a future SPARQL specification adding
>> "alternative subject and object" support either, for shortening
>> sometimes tedious unions.)
>>
>> A small adjustment would be to use (an ASCII version of) the "left tack":
>>
>>      :s :p :o {| :e -| :a :b |} .
>>
>>      :s :p :o {| :e -|} .
>>
>>      << :e -| :s :p :o >> :a :b .
>>
>>      SELECT * { ?s ?p ?o {| ?annot -| dct:issued | dct:modified "2023" |} . }
>>
>> (This reverse turnstile symbol [3] has also been used e.g. in
>> mathematics [4] and APL (ambivalent left identity).)
>>
>> (Options working more or less well: `:=`, `:-`, `|-`, `->`, etc. Needs
>> more consideration and testing on real data.)
>>
>> Whatever is chosen *could* also be added for naming nestable blank node blocks:
>>
>>      :s :p :o [ :e -| :a :b ] .
>>
>> (I'm not necessarily in favour of that [5], but I wouldn't argue
>> against it if the popular argument is its ease of use in authoring.)
>>
>> (Note: N3 used to have the `:-` "iso" operator for this [6]. It was a
>> "pseudo-predicate" though, which might work less well.)
>>
>> Best regards,
>> Niklas
>>
>> [1]: <https://www.w3.org/TR/sparql11-query/#pp-language>
>> [2]: <https://sparql.org/query-validator.html>
>> [3]: <https://en.wikipedia.org/wiki/Turnstile_(symbol)>
>> [4]: <https://www.mathematics-monster.com/symbols/Left-Tack.html>
>> [5]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Dec/0130.html>
>> [6]: <http://infomesh.net/2002/notation3/>
>

Received on Monday, 22 April 2024 19:14:39 UTC