Re: summary un/asserted

No.  Syntax is syntax.  A proposal for a change to RDF graphs has to instead 
talk in the language of sets and triples - not syntax.   As an example of the 
difference, in your abstract syntax a graph is a sequence of triples and there 
is no notion there that a graph is instead a set of triples.

This is similar to the difference between the syntax of JSON and the majority 
meaning of JSON - the syntax doesn't say anything about repeated names in 
objects but the majority meaning is that an object is a finite map and keeps 
only the last object member with a given name.

The syntax you provide looks to be adequate for this notion of RDF graphs 
(aside from unused atomicTerm production) but could be used for lots of 
different structures.

peter


On 7/10/24 09:29, Franconi Enrico wrote:
> Peter,
> sure, but would you agree that your idea would be captured exactly by the ABSTRACT syntax for RDF graph I wrote?
> —e.
> 
>> On 10 Jul 2024, at 14:02, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>> 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 13:50:15 UTC