Re: The way forward

Ora,

You are right. There is no structural difference. We would need something
more. If we humor the singleton property pattern for the sake of argument:
it, exactly like RDF lists, hinges upon a well-formedness condition for
blank nodes used with special properties; for lists: rdf:first and
rdf:rest; for singleton properties: rdf:singletonPropertyOf.

Note that rdf:singletonPropertyOf is defined as a subproperty of rdf:type
in the original paper [1]; *not* of rdfs:subPropertyOf. This is *crucial*,
as it does not assert the property type (that has to be separately
asserted), and also makes it isomorphic to LPG edges (well, apart from the
SA vs PG mode; which is already off the table; we have only "SA mode" and
the annotation sugar for ease of use). This is also why it has to be the
predicate that is special (and not specializations of subject or object,
which is just "regular" specialization of identity).

Now, *naming* those cons nodes or singleton properties breaks that
condition. Syntax *could* be invented to still mark them as "owned" by
something; that something being a triple relating the owned identifiers by
using the aforementioned special properties as predicates. Well, we already
have naming syntax in the works for RDF-star.  (And I really doubt that
anyone wants to name cons nodes in shorthand RDF lists. Of course,
well-formed syntax for lists using blank nodes is built-in into RDF/XML
(barring literals), Turtle and JSON-LD.)

It might even be added as a syntax hint in N-triples, by marking names as
"owned", telling a streaming processor that these are intentionally tied to
the special properties used as predicates. Then the reliance on blank nodes
isn't even necessary. (Please humor me here; this is still a strawman, and
I'm still for many-to-many reifiers of triple terms.)

To illustrate, the singleton property is marked as "owned" here, by using
`@` as a prefix:

    # Predicate marked as owned, don't just insert as a regular triple:
    <http://example.org/s1> @_:sp1 <http://example.org/o1> .
    # ... two million other triples from multiple parallel streams...
    # Then (or before) comes the definitive meaning of the name (and
optimizations can apply):
    _:sp1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#singletonPropertyOf> <
http://example.org/ns#p1> .

Well-formedness is broken if either of these are also asserted (before or
after the above):

    _:sp1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#singletonPropertyOf> <
http://example.org/ns#p2> .
    <http://example.org/s1> _:sp1 <http://example.org/o2> .
    <http://example.org/s2> _:sp1 <http://example.org/o1> .

That's *just* a syntactic marker, and only needed for efficient triple
stream processing. In the abstract syntax that is reasonably *not* needed.
Instead, well-formedness precisely defines rules for how the special
properties own subject and/or object identifiers when used as predicates in
the graph. Any other use of them will break that; and demote them to
"regular" use (or be unceremoniously dropped). (We've had that situation
for RDF lists, non-normatively specified, for a long time now.)

But again, please note that I'm not saying we should go here; just that
it is an option.

I still think rdf:reifies with triple term objects, used with many-to-many,
is a potential game changer. It makes meta-relationships more natural to
express (as I illustrate in [2]). Granted, it does come at a possibly high
cost for the existing ecosystem and knowledge thereof (by adding triple
terms to RDF). But by having reifiers be *whatever you need them to be*
(rather than the old, "myopic" rdf:Statement many-to-one model), we can
avoid forcing users to have this excruciatingly detailed discipline for
using them correctly (i.e. not having to say things like "no, it's not an
event or situation, it is a token of the simple abstract, directed
relation"). With LPG edge restrictions, or singleton properties, or
old-school reification, we still have one hop from that to those situations
or events (unless punning on a marriage-as-a-triple-statement is deemed
sensible...). The implementation costs are different, the requirements for
proper usage are different.

Best regards,
Niklas

[1]: <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4350149/>>
[2]: <
https://niklasl.github.io/ldtr/demo/?url=../test/data/reifiers-misc-m2m.trig
>



On Tue, Apr 30, 2024 at 2:07 PM Lassila, Ora <ora@amazon.com> wrote:

> Maybe I am missing something, but I don’t see how this would work.
>
>
>
> Kurt says that something like
>
>
>
>                 :s [:b | :p1 :o1 ] :o .
>
>
>
> “expands” to
>
>
>
>                 :s :b :o .
>
>                 :b :p1 :o1 .
>
>
>
> But how is this expansion structurally any different from
>
>
>
>                 :c1 rdfs:subClassOf :c2 .
>
>                 rdfs:subClassOf rdfs:domain rdfs:Class .
>
>
>
> and since nothing else has been said, how would any RDF processor know to
> treat it differently? This is nothing but what we already have in RDF where
> we make statements about “property types”. In Kurt’s example, there is no
> way to know that :b is not a property type but is intended to be a
> singleton property.
>
>
>
> Ora
>
>
>
>
>
> *From: *Kurt Cagle <kurt.cagle@gmail.com>
> *Date: *Monday, April 29, 2024 at 5:10 PM
> *To: *Niklas Lindström <lindstream@gmail.com>
> *Cc: *"Thompson, Bryan" <bryant@amazon.com>, "Peter F. Patel-Schneider" <
> pfpschneider@gmail.com>, "public-rdf-star-wg@w3.org" <
> public-rdf-star-wg@w3.org>
> *Subject: *RE: [EXTERNAL] The way forward
> *Resent-From: *<public-rdf-star-wg@w3.org>
> *Resent-Date: *Monday, April 29, 2024 at 5:09 PM
>
>
>
> *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.
>
>
>
> 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
>
>
>
>
>
> 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
> > >
>
>