Proposal by Kurt

Hi Kurt,
I’m still waiting for a reply to my comments from two months ago about your proposal (Word document attached), which you presented again at our last meeting.
I have seen that you have posted<https://www.linkedin.com/feed/update/urn:li:activity:7219457379564670976/> now your proposal in LinkedIn.
Let me rephrase the comments again, hoping you will react to them.

Named Node in the Predicate Position

Your example:

:liz [_:married1 => rdf:subPropertyOf :married ;
                    :hasInterval [ _:interval1 => :start 1964 ; :end 1974]]
     :richard .

:married1 must be a *singleton* property.
This option which has been discussed and dismissed some time ago in the RDF-star WG.
This introduces owl:sameAs, leading to serious implementation problems.
Indeed, the following equivalence pattern holds:

A1 owl:sameAs A2 .
<—>
A1 [ B  => C1 D1 ] E .
A2 [ B  => C2 D2 ] E .

Moreover, the singleton property does not express directly the multi-edge case, since you have to name each edge of the same type with a distinct name.

From the current RDF-star baseline, the example can be written in Turtle:

<< _:marriage1 | :liz :married :richard >>
   a :marriage ;
   :hasInterval [:start 1964 ; :end 1974] .

This corresponds to the following in N-Triples:

_:marriage1 rdf:reifies <<( :liz :married :richard )>> .
_:marriage1 rdf:type :marriage .
_:marriage1 hasInterval  _:interval1 .
_:interval1 :start 1965 .
_:interval1 :end 1974 .

Reifier Expression

This is just a rephrase of "option 1” (old style 1.1 reification) we discussed and and dismissed some time ago in the RDF-star WG.
It has severe drawbacks, e.g., in reconstructing the reifier back from the three reification triples.

cheers
—e.

On 24 May 2024, at 15:55, Franconi Enrico <franconi@inf.unibz.it> wrote:

Hi Kurt,
It seems to me that your proposal is a rephrase of various discussions we already had, and ruled out.

Named Node in the Predicate Position: this seems to be just a rephrase of the singleton property - once you try to give semantics to it. Observe that, wrt the current status of the discussion, your proposal does not express directly the multi-edge case, since you have to name each edge of the same type with a distinct name.

Reifier Expression: this is just a rephrase of "option 1" we discussed and ruled out some time ago. It has severe drawbacks in reconstructing the reifier back from the three reification triples.

cheers
—e.


On 23 May 2024, at 19:24, Kurt Cagle <kurt.cagle@gmail.com<mailto:kurt.cagle@gmail.com>> wrote:

I've attached a document that covers YET ANOTHER proposal (more properly a recommendation I've made before).

There are two issues that we seem to be rehashing here. The first is the question of reificational notation, while the second has to do with LPG harmonization. My contention is that these are different issues, though we can use similar notation for both.

Reification

A named reification is simply a set of statements:

:r rdf:subject :s; rdf:predicate :p; rdf:object :o .

This is not a triple. It is three statements about the state that a triple can be in. It does not introduce a triple into the system,it makes no assertions about the truthiness or even, by itself existence of that triple. It is simply a statement about the components that a triple might have. You cannot reason with it directly, though you can use other processes (SPARQL, SHACL, etc.) to construct or verify the existence of triples for which these assertions are true. Properly speaking, the above itself should probably be qualified:

:r rdf:subject :s; rdf:predicate :p; rdf:object :o ; a rdf:Reification .

The notation << :r | :s :p :o >> makes the above statement more compact, but the reification can apply to any triples within a system, or none at all, regardless of the values.

Named Node Expressions

I propose, in the attached, that we use a similar nomenclature for what I'm turning named node expressions, to whit:

[ ?nn | :p1 :o1 ; :p2 :o2 ]

where ?nn is replaced by a formal (not blank) IRI.

This is a Turtle (not RDF) syntactical amendment. The above takes what would ordinarily be a blank node and replaces it with a named node:

For instance:

:liz :hasMarriage [ :marriage 1 | :to :Ricard, :start "1965" ; :end "1975" ].

which expands to:

:liz :hasMarriage  :marriage 1 .
:marriage 1 :to :Richard .
:marriage 1  :start "1965" .
:marriage 1   :end "1975" .

Why is this important? Because the blank node is a pointer to a data structure, but use of the [] notation makes it impossible to reference that data structure from within Turtle. By adding in a named node as the referencing node, you gain that ability, and it is a key ability for modeling.

For instance, I can use the expression:

:liz :hasMarriage [ :marriage 1 | :start "1965" ; :end "1975"; :to :richard ], [ :marriage 2 | :start "1975" ; :end "1985"; :to :john].

This is semantically equivalent to the JSON

{"liz":{"hasMarriage":[{"marriage1":{"start":"1965", "end":"1975","to":"richard"}},"marriage1":{"start":"1965", "end":"1975","to":"richard"}}]}}

The same thing can be done with both predicate-positioned named node expressions and subject-oriented ones.

This addresses the LPG equivalency relationship, and does so without ever touching reifications.

Note that this also highlights an important point. Blank nodes are useful because they are unique and system-assigned. However, they are not referenceable. The Turtle notation:

:liz :hasMarriage _:b1, _:b2 .
_:b1 :start "1965" ; :end "1975"; :to :richard .
_:b2 :start "1975" ; :end "1985"; :to :john .

is simply a preprocessor directive to replace the "named" nodes with anonymous IRIs in the final indexing.  You still have to make _:b1 and _:b2 unique, or the data structures disintegrate.

Anyway, I ask the chair for time during our next meeting to discuss this proposal.

Kurt Cagle
Editor in Chief
The Cagle Report
kurt.cagle@gmail.com<mailto:kurt.cagle@gmail.com>
443-837-8725