Re: summary un/asserted

Hi Peter,

I agree with your initial reply to Thomas. And I agree that your
(strawman) proposal here probably won't hold up.

This form looks like named triples (RDFn). I don't think it would
work. unless RDF graphs are redefined to be `(triple* | (name,
triple))*`. It also imposes some troubling limitations, such as the
impossibility of referring to the relationship between the "name" and
the triple (not only in other triple terms, which may be an edge case;
but, crucially, in vocabulary design; which is needed, as I show in
[4]). And it may lead to the named graphs problem all over again --
what do the names mean in relation to their triple(s)? And indeed,
naming multiple triples like that appears very problematic. (Problems
which the explicit reification of multiple triples by linking them
does not suffer from.)

I suspect that some ongoing confusion is a residual effect of the
original proposal to add triples as subjects. Adding triples as
subjects was *not* reification "done right". It was, IMO, reification
done more wrong. Triples as subjects didn't work at all for real world
LPG uses of many-to-one. With some hyperbole, it was akin to using
literals as subjects naively, with `"20" :currency :USD` to solve the
problem of values with units (structured values), but "with some
limitations" (saying that the integer 20 is in US-dollar currency in
the entire model). But to be more fair, the RDF-star error was far
more subtle.

We've finally all but expunged this error. Now, triples as *objects*
(triple terms) of an appropriate relation on the other hand, have
shown promise of some really powerful benefits.

There is some residue left though, one being some insistence on
allowing it even in non-generalized abstract syntax. But another
problem is sticking to this syntax:

    << <Alice> :bought <SomeComputer> >> :date "2014" .

Which is now a shorthand for:

    _:r1 rdf:reifies <<( <Alice> :bought <SomeComputer> )>> .
    _:r1 :date "2024" .
    _:r1 :cost 20 .
    _:r1 :currency :USD .

and totally fails to make this:

    _:r1 rdf:reifies <<( <Alice> :shoppedAt <ComputerStore> )>> .
    _:r1 rdf:reifies <<( <Alice> :bought <SomeComputer> )>> .
    _:r1 :date "2024" .
    _:r1 :cost 20 .
    _:r1 :currency :USD .

shorten to anything like Turtle, or even legible at all:

    << _:r1 | <Alice> :bought <SomeComputer> >> :date "2014" .
    << _:r1 | <Alice> :shoppedAt <ComputerStore> >> :cost 20 .
    _:r1 :currency :USD .

(In case anyone wants to object to my model design choice here ("use
`_:r1 :seller <ComputerStore>`"!), please read my follow-up to Thomas
[1].)

If we're *serious* about the minimal baseline [2], with `rdf:reifies`
working *equally* well for many-to-one and many-to-many (proper N-ary
relationships, relators, general reification), we need to revisit that
in earnest, as I wrote in [3].

That proposal could shorten the above--if the purchase alluded to is
not also true--along the lines of:

    <Alice> << :bought <SomeComputer> >> ^{_:r1} ;
        << :shoppedAt <ComputerStore> >> ^{_:r1} .

    _:r1 :cost 20 ;
        :currency :USD ;
        :date "2014" .

Which might not be *beautiful* (and could be tinkered with some more),
but is at least more "Turtle" (once you get used to reading the quotes
as being for predicate+object). For the possibly (much) more common
case, remove the quotes to have the regular assertions with
annotations:

    <Alice> :bought <SomeComputer> ^{_:r1} ;
        :shoppedAt <ComputerStore> ^{_:r1} .

    _:r1 :cost 20 ;
        :currency :USD ;
        :date "2014" .

This "extra resource" is *crucial*. And it isn't anything mysterious.
Here, it should be typed: `_:r1 a :Purchase`. In other cases, we have
Marriages, Publications, Pipe connections, or good old Statements,
Snaks, Observations, Utterances, Data Sources or Ingests, or whatever
the nature is of the reifying circumstance of one or more abstract
relationships. Regardless of their type, they relate to these
relationships, uniformly, with `rdf:reifies`. And this is what we
should convey.

I very much value what you wrote regarding "the limited sensory and
cognitive capabilities of humans". Even if my proposed form here is
deemed unsatisfactory, this is the condition for which I think Turtle
should cater. Making wikidata more readable is of great interest to me
too [4]. Again, the detailed polish has to wait until we have a solid,
agreed upon baseline. (There is some interaction though, unless
someone can transmit the pure qualia of the RDF abstract syntax...)

Best regards,
Niklas

[1]: <https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jul/0038.html>
[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/2024Jul/0011.html>
[4]: <https://github.com/Kungbib/wikidatalab/>



On Tue, Jul 9, 2024 at 5:02 PM Peter F. Patel-Schneider
<pfpschneider@gmail.com> wrote:
>
> Here is a proposal that I don't think will go anywhere, and I might not
> totally believe in, but does connect to the working group's activities.
>
> THESIS:  embedded triples are not a good solution to the use cases of the
> working group
>
> EVIDENCE:
>
> The use cases of the working group do not use embedded triples directly but
> instead require a separate resource that is connected to a triple.   These
> separate resources are needed because the information about an embedded triple
> from one use of it has to be separated from the information from other uses.
> Otherwise there is a mix-and-match problem, as shown in representing
> provenance where source from one provenance cannot be combined with time or
> access from another.  This problem affects the "seminal example", all kinds of
> provenance, and nearly all uses of embedded triples in the enoding of n-ary
> predicates.  The need for this extra resource and new linking predicate add to
> the complexity of just about any use of embedded triples in RDF and require
> extra shorthands in Turtle to partly hide this complexity from users.
>
> SOLUTION:
>
> The solution is to do away with the uniqueness of embedded triples and base
> the extension of RDF proposed by the working group instead on non-unique
> occurrences of triples.   If we leave the proposed syntax alone, we get an
> extension of RDF where
>    << :a :b :c >> :d :e , :f :g .
>    << :a :b :c >> :h :i , :j :k .
> does *not* entail
>    << :a :b :c >> :d :e , :h :i .
>
> There are problems with this version of occurrences of triples.   Without some
> way of referencing a particular occurrence of a triple it is not possible to
> represent the above graphs in N-triples and all information about the
> occurence has to use a shorthand syntax in Turtle, making what used to be a
> convenience a necessity.   The solution to this problem is to in effect give
> these resources an identifier, so that a particular occurrence of a triple is
> no longer "anonymous" and can be referred to.
>
> The way to do this is to allow IRIs and blank nodes in RDF to also be a triple
> occurence, with syntax something like (this syntax probably not good at all
> but you should get the idea)
>    <:x< :a :b :c >> :d :e .
>    <_:x< :a :b :c >> :d :e .
> in both N-triples and Turtle.  This is a varation of a recent syntax proposal
> but is not just syntax and instead is the extension to the RDF data model to
> support quoted triples.
>
> A big problem (and one reason that I don't totally believe this proposal) is
> using the same IRI or blank node for multiple triple occurrences as in
>    <:x< :a :b :c >> :d :e .
>    <:x< :f :g :h >> :d :e .
> has to be handled by either forbidding it or allowing a node to have multiple
> triple occurrences.
>
> peter
>

Received on Tuesday, 9 July 2024 19:12:43 UTC