Re: summary un/asserted

The point of the proposal is to require that (some) nodes in RDF graphs are of 
the form IRI x triple or BNOde x triple.

Yes, Turtle should be as compact as possible but it is not the thing that most 
users should see why they view RDF graphs.

peter


On 7/9/24 15:12, Niklas Lindström wrote:
> 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 21:09:18 UTC