Re: The way forward

I've posted this on Linked In:

https://www.linkedin.com/pulse/rdf-proposal-bind-operator-kurt-cagle-knjvc/?trackingId=jGbDIxVXSvKAHoYkrnKzdw%3D%3D

I'll make the same content here that I did there. I think there is both a
need for an anonymous object binder and a reifer, and the
acknowledgment that a reifer is not in fact a triple from the standpoint of
most triple stores.

Specifically, a reifier :r, whether blank or named, the subject of three
triples within a graph:

{
:r rdf:subject :s .
:r rdf:predicate :p .
:r rdf:object :o .
}

The reification << :s :p :o >> is not itself a triple in the graph unless
it has been asserted elsewhere. Thus, you can say things about the set of
items that collectively make up a triple without actually having such a
triple actually exist in the first place. This is perfectly fine from a
query standpoint, as such a reification may refer to a nonsensical triple
if actually converted. That is to say, you can only an infer such a triple:

construct {?s ?p ?o}
where {
    $r rdf:subject ?s .
    $r rdf:preficate ?p .
    $r rdf:object ?o .
    }

but if that triple is non-sensical, then it will violate OWL or SHACL,
which is as it should do.

An anonymous object binder, on the other hand, names a previously unnamed
triple. It's form is:

:s [ :b | :p1 :o1; :p2 :o2; ....] :o.

and can be stated as: this object, which has the name :b, has these
properties. As with a blank node, this construction is a single node that
expands out into a graph:

 :s :b :o .
:b :p1 :o1 .
:b :p2 :o2 .

It can also occupy either the :s or :o slot.

We have been struggling with a solution to this for a while now, and I'd
argue that this can be found in the following example:

:liz [:marriage1 | a Class:Marriage ; :startDate 1965 ; endDate 1974;
:marriageEnd :divorce ] :richard .

This is the same as:

:liz :marriage1 :richard.
:marriage1 a Class:Marriage;  :startDate 1965 ; endDate 1974; :marriageEnd
:divorce .

This is the Neo4J use case in a nutshell. It is an especially compact
notation that maps very cleanly to JSON and, for that matter, to
OpenCyper CREATE statements.

Please note that we need BOTH of these. The reifier provides a way of
describing statements, but has been shoehorned into trying to also be an
edge in an LPG format, despite the fact that Neo4J works because it's edge
identifier is hidden - the edge is actually a unique GUID  masking a
reference to a label with the titular name. The object bind operator
provides a way to have a named identifier be used and referenced as an
object without having to create multiple assertions. They are not the same
things, and shouldn't be treated as such.








This is not a triple.





*Kurt Cagle*
Editor in Chief
The Cagle Report
kurt.cagle@gmail.com
443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>


On Mon, Apr 29, 2024 at 11:10 AM Niklas Lindström <lindstream@gmail.com>
wrote:

> Bryan,
>
> On Mon, Apr 29, 2024 at 7:00 PM Thompson, Bryan <bryant@amazon.com> wrote:
> >
> > Niklas,
> >
> >
> > I am drawing a distinction between making statements about a specific
> statement and making statements about a collection of statements.  I think
> it is a mistake to consider the latter simple a more general version of the
> former.  The ability to have metadata about a specific statement is the key
> enabler (Statements about Statements) for edge properties (for RDF, leaving
> LPG out of this), statement level provenance for RDF, etc.
>
> Would you mind answering my first question, then, so that this mistake
> can be resolved?
>
> > The ability to make statements about statement sets is different.  It
> does not support this basic mechanism of describing a specific statement
> unless a constraint is imposed such that the "Graph" is a single statement.
>
> I (and others, I've gathered) claim that we are not talking about
> graphs even with things reifying multiple triples. Are you claiming
> that we are? Are we *not* with one value for rdf:reifies? Again see
> question 1, about John's set of friends, all of which John knows (he
> does not know the set, he knows each one). How is that different from
> this?
>
> > I think that talking about this as Statements about Statements (SAS) vs
> Statements about Graphs (SAG) highlights the difference.
> >
> >
> > The risk here is that people see SAG as more general, but in fact it is
> unable to support SAS without some constraint (e.g., a well-formedness
> constraint, a profile, etc.).
> >
> >
> > It was these SAS use cases that motivated RDR, RDF*, and the creating of
> this working group.
> >
> >
> > I am happy to see the WG support both, but let's not forget the
> motivating use cases of SAS.
>
> We are not forgetting them. It is because of them we have arrived at
> this. Or am I to assume that by "statement", you mean the abstract
> logical relationship encoded by the triple itself? That is, *not* a
> token occurrence or concrete realization thereof (that which classical
> reifications [1] are about, and call "statements", for better or
> worse)? Not about an utterance, event, situation or other
> concretization which reifies it? I.e. *not* what the Amazon Neptune
> use cases require [2]? If so, which of the use cases [3] are you
> talking about? And what are the properties that you want to assert
> that these abstract logical relationships themselves have (other than
> subject, predicate, object)?
>
> Please provide concrete examples (or direct references to such).
>
> Best regards,
> Niklas
>
> [1]: <https://www.w3.org/TR/rdf11-mt/#reification>
> [2]: <
> https://lists.w3.org/Archives/Public/public-rdf-star/2021Dec/att-0001/rdf-star-neptune-use-cases-20211202.pdf
> >
> [3]: <https://github.com/w3c/rdf-ucr>
>
>
> > Bryan
> >
> > ________________________________
> > From: Niklas Lindström <lindstream@gmail.com>
> > Sent: Friday, April 26, 2024 12:26:45 AM
> > To: Thompson, Bryan
> > Cc: Peter F. Patel-Schneider; public-rdf-star-wg@w3.org
> > Subject: RE: [EXTERNAL] The way forward
> >
> > CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
> >
> >
> >
> > Bryan,
> >
> > 1.How come, given this:
> >
> >     <e1> rdf:reifies <<( <s1> :p1 <o1> )>> .
> >     <e1> rdf:reifies <<( <s2> :p2 <o2> )>> .
> >
> > you say that we're making statements about a graph, whereas with:
> >
> >     <e1> rdf:reifies <<( <s1> :p1 <o1> )>> .
> >
> > we are not? With your notion. how would you make statements about a
> > graph of only one triple?
> >
> > Also, would you say that here:
> >
> >     <john> foaf:knows <jane> .
> >     <john> foaf:knows <mary> .
> >
> > we are making statements about the set of <jane> and <mary>? Does
> > <john> know that set? Does the set contain two persons, or two IRIs?
> >
> > I suspect that in the sentence "making statements about a graph" there
> > is an unwitting change of context, from the domain of discourse to its
> > representation (which are not necessarily different, but quite often).
> >
> > 2. I'm not entirely sure what you mean by "making statements about
> > statements". From [1]: "Asserting an RDF triple says that some
> > relationship, indicated by the predicate, holds between the resources
> > denoted by the subject and object. This statement corresponding to an
> > RDF triple is known as an RDF statement." But then you talk about
> > triples, and graphs, i.e. sets of triples. Do you consistently refer
> > to the triple (the encoding) or the statement denoted by the triple
> > (the expression)? I would say we're making statements about
> > statements, by asserting triples where the object is another triple.
> > Many-to-one or many-to-many does not change that.
> >
> > See also [2]: "An RDF triple encodes a statement—a simple logical
> > expression, or claim about the world. An RDF graph is the conjunction
> > (logical AND) of its triples."
> >
> > Aside: Considering [3]: "An RDF graph is a set of RDF triples", I
> > don't think this working group is in agreement on whether a graph is
> > EXACTLY a set of triples (i.e. by definition, these two names denote
> > the same mathematical concept), or if a graph is a set of triples, but
> > not all sets of triples are graphs. (And here I do not mean "named
> > graphs" at all, which is a pair of a name (IRI or bnode) and this
> > graph notion. Of course, I do not know if that's supposed to mean all
> > such pairs; but that's hopefully beside the point...)
> >
> > We may want to address these matters in today's semantics meeting.
> >
> > Best regards,
> > Niklas
> >
> > [1]: <https://www.w3.org/TR/rdf12-concepts/#resources-and-statements>
> > [2]: <https://www.w3.org/TR/rdf12-concepts/#entailment>
> > [3]: <https://www.w3.org/TR/rdf12-concepts/#section-rdf-graph>
> >
> >
> >
> > On Fri, Apr 26, 2024 at 1:07 AM Thompson, Bryan <bryant@amazon.com>
> wrote:
> > >
> > > I do not believe that you answered my question Peter.   What do you
> want to call that set of Subject Predicate Object tuples?  At any rate, I
> will call it a graph and your proposal is making statements about those
> sets.  E.g., Statements about Graphs.
> > >
> > >
> > > Bryan
> > >
> > > ________________________________
> > > From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
> > > Sent: Thursday, April 25, 2024 4:04:46 PM
> > > To: public-rdf-star-wg@w3.org
> > > Subject: RE: [EXTERNAL] The way forward
> > >
> > > CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender and
> know the content is safe.
> > >
> > >
> > >
> > > This is a fundamental misconception.  Consider complex numbers.  They
> are an
> > > ordered pair of real numbers, but there is no way that every ordered
> pair of
> > > real numbers has to be considered a complex number.  Similarly a set
> of RDF
> > > triples, let alone several RDF triples not collected into a set, is not
> > > necessarily an RDF graph.
> > >
> > > peter
> > >
> > >
> > > On 4/25/24 13:48, Thompson, Bryan wrote:
> > > > What do you call a set of S, P, O tuples?  I call it a Graph.  Your
> proposal is to reify such sets.  Hence, Statements about Graphs.
> > > >
> > > > Bryan
> > >
>
>