Re: [External] : Re: new proposal

On 02/07/2024 12:39, Niklas Lindström wrote:
> On Tue, Jul 2, 2024 at 12:35 PM Andy Seaborne <andy@apache.org> wrote:
>>
>>
>>
>> On 02/07/2024 05:45, Souripriya Das wrote:
>>> The following type of nesting allows reifying the association between a
>>> reifier and what it reifies:
>>>           :r2 rdf:reifies  <<( :r1 rdf:reifies <<( :s :p :o )>> )>> .
>>> Here the nesting is: "rdf;reifies -> rdf:reifies" (i.e., in the ordering
>>> of predicates, rdf:reifies immediately follows another rdf:reifies).
>>>
>>> Nested beliefs are different than above and can be expressed as follows:
>>> Using 4^th  component as the reifier:
>>>           :s :p :o :r1 .
>>>           :bob :believes :r1 :r2 .
>>>           :alice :believes :r2 .
>>> The same can be expressed using rdf:reifies as follows:
>>>           :r1 rdf:reifies <<( :earth :hasShape :cube )>> .
>>>           :r2 rdf:reifies <<( :bob :believes :r1 )>> .
>>>           :alice :believes :r2 .
>>
>> We can have a standalone clause in the "agreed syntax" to have a
>> standalone reification in consistent style with inline use:
>>
>> << :r1 | :earth :hasShape :cube >> .
> 
> Or we could support grouping "quoted" predicate-object-pairs with the
> same subject, add naming to the annotation syntax [1], and use that
> same form for both asserted and unasserted triples:
> 
>      :earth << :hasShape :cube >> {| @ :r1 |} ;
>        :hasShape :sphere {| @ :r4 |} .
> 
> I've waited for months to discuss syntax revisions in earnest. Alas, I
> don't think we're on stable ground yet, but I need to mention now what
> I see is needed for transparent many-to-many [2], if that's what we'll
> end up with.
> 
> If we arrive at that, we need a syntax that concisely can: 1) use
> multiple reifiers per triple; 2) name reifiers (and have multiple
> triples reified by the same reifier);  3) reify reifications (to be
> able to describe a reifier which states that some triple is reified by
> some reifier, the need for which is exemplified in [3]); 4) group
> multiple non-asserted statements under the same subject.

"need" is a high barrier for syntactic sugar.

A design should support usage, not aim to directly provide every usage.

Terse is barrier to use - the needs of the "general data author" and 
"general data reader" should come first that means simple expression.

This is putting complex syntax forms into Turtle for specific RDF-star 
usage.

Syntax is precious.
Syntax is a value-judgement.

The risk is that choices will burden Turtle and Turtle implementation 
for the future with little used features. Feature need more 
justification than some use case.

We should leave open the possibility of graphs-in-graphs.

> The current syntax suffers here. If we ignore inertia for a moment, a
> syntax along these lines may be a wiser choice, since it handles all
> four:
> 
>      :earth << :hasShape :disc >> ^{:r1, :r2 ^{:r3}} ;
>        << :hasShape :cube >> ^{:r1} ;
>        :hasShape :sphere ^{:r4} .
> 
> Which would expand to:
> 
>      :earth :hasShape :sphere .
>      :r1 rdf:reifies <<( :earth :hasShape :disc )>> .
>      :r1 rdf:reifies <<( :earth :hasShape :cube )>> .
>      :r2 rdf:reifies <<( :earth :hasShape :disc )>>
>      :r3 rdf:reifies <<( :r2 rdf:reifies <<( :earth :hasShape :disc )>> )>> .
>      :r4 rdf:reifies <<( :earth :hasShape :sphere )>> .
> 
> In fact, if we dared to invalidate the << ... >> form in the subject
> position syntax-wise (on the grounds that it gives the wrong
> impression), I might even dare to go back to using that form for the
> triple terms themselves. And if we disallowed those as subjects in all
> cases (apart from generalized RDF for the "entailment space"), we
> could skip the "well-formedness" part and allow "bare" triple terms in
> the object position. I'm quite *nervous* about that, but not *adverse*
> to it.
> 
> But we don't need to debate the merits or alternatives more until we
> agree on the numbered points above, based on use case requirements in
> relation to a given baseline. Such as [3] in relation to [2].
> 
> (For anyone actually eager for the syntax debate: Of course I've
> written the EBNF and implemented this, and some variations; to see
> what technically works. I added a marker before the braces mostly in
> case a future RDF adds some form of graph literals to the mix. It
> isn't strictly necessary. I do think, since it is used as the inverse
> operator on predicates in SPARQL, that it also signals an "arrow" to
> the previous (or above) statement, signifying that the rdf:reifies
> goes from the reifier to the triple.)
> 
> Best regards,
> Niklas
> 
> [1]: <https://github.com/w3c/rdf-star-wg/issues/116>
> [2]: <https://github.com/w3c/rdf-star-wg/wiki/RDF-star-%22minimal-baseline%22>
> [3]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jun/0052.html>
> 
> 
>>       Andy
>>
>> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0095.html
>>

Received on Tuesday, 2 July 2024 20:21:21 UTC