Re: [External] : Re: new proposal

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.

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 11:40:21 UTC