Re: summary un/asserted

The proposal is not about changing the syntax of RDF but instead about 
fundamentally changing the nature of RDF graphs (which will, in turn, require 
a new syntax, but that's not the important part).

Here is a quick stab at the required definition, done for generalized RDF-star 
graphs as that is the simplest version to do.

Generalized RDF-star triples is the smallest set of triples of the form 
subject, predicate, object where a subject, predicate, or object is an IRI, a 
blank node, or a literal, optionally plus a generalized RDF-star triple.

The optional triple might have to instead be a set of triples.

A generalized RDF-star graph is a set of generalized RDF-star triples.


peter




On 7/10/24 04:21, Franconi Enrico wrote:
> If I understand you well, you propose that RDF has the following syntax:
> 
> |graph ::= triple* triple ::= subject predicate object subject ::= 
> NoLiteralTerm predicate ::= iri object ::= term NoLiteralAtomicTerm ::= iri | 
> BlankNode atomicTerm ::= NoLiteralAtomicTerm | literal NoLiteralTerm ::= 
> NoLiteralAtomicTerm | tripleTerm term ::= NoLiteralTerm | literal tripleTerm ::= |NoLiteralAtomicTerm triple
> 
> 
> Am I correct?
> —e.
> 
>> On 9 Jul 2024, at 23:09, Peter F. Patel-Schneider <pfpschneider@gmail.com> 
>> wrote:
>>
>> 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 Wednesday, 10 July 2024 12:02:12 UTC