#300: Added support for RDF 1.2 triple terms #368

bergos · 2025-04-21T18:31:22Z

This PR adds support for RDF 1.2 triple terms, as discussed in #300.

Since this is the first RDF 1.2 feature PR, I want to discuss in the next meeting how to handle RDF 1.2 features before merging it.

Closes #300

See this document rendered online here

shacl12-core/index.html

shacl12-test-suite/tests/core/node/reifiableBy-001.ttl

afs · 2025-04-21T21:18:13Z

shacl12-core/index.html

+					<h4>sh:reifiableBy, sh:reificationRequired</h4>
+					<p>
+						<code>sh:reifiableBy</code> can be used to link a <a>property shape</a> with one or more <a>node shapes</a>.
+						Any reified statement must conform to these node shapes.


{| |} is surface syntax for the triples.

I think SHACL needs to define validation for the basic forms then work up from there. This PR seems to be for an annotation usage pattern but that isn't the only way to use RDF 1.2.

Starting with:

ex:ValidResource1 ex:propertyA "valid" {| ex:propertyB true ; |} .

{| |} is syntax to both reify a triple and provide triple about the reification. It is only syntax and is not retained in the RDF graph.

ex:ValidResource1 ex:propertyA "valid" . << ex:ValidResource1 ex:propertyA "valid" >> ex:propertyB true .

and << >> (an occurence - a use of a triple term) is in turn surface syntax for rdf:reifies
so the whole thing three triples:

ex:ValidResource1 ex:propertyA "valid" . _:b0 rdf:reifies <<( ex:ValidResource1 ex:propertyA "valid" )>>; ex:propertyB true .

<<( ... )>> is a triple term.

I think the intent is to apply a shape to the structure and also the triples insided {| |}.
Is that right?

Only Turtle/TriG have this annotation syntax.

Data does not have to use {| |} and it does not exist graph / triple store.

Sometimes, there may not be an asserted triple:

<< :s :p :o ~ _:reif1 >> :added "2025-04-01" . << :s :p :o ~ _:reif1 >> :deleted "2025-05-01" .

which is 3 triples:

_:b0 rdf:reifies <<( :s :p :o )>>; :added "2025-04-01" . rdf:reifies <<( :s :p :o )>>; ## Duplicate - same as the first triple. :deleted "2025-05-01" .

Note the shared blank node.

Yes, it's for the use case where an asserted triple can be used to traverse into the triple term. The text definition says that the reifier will become the focus node for that validation.

Based on the discussion in #300, I thought we don't need to cover the use case without asserted triples. Node Expressions, or SPARQL-based targets can be used for that use case.

Co-authored-by: Andy Seaborne <[email protected]>

shacl12-core/index.html

afs · 2025-04-22T15:15:56Z

shacl12-core/index.html

+					<div class="def def-text">
+						<div class="def-header">TEXTUAL DEFINITION of sh:reificationRequired</div>
+						<div class="def-text-body" data-validator="ReificationRequired">
+							If <code>$reificationRequired</code> is set to <code>true</code>, a failure MUST be produced when there is no reified statement for the <a>triple term</a> <code>t</code> in the <a>data graph</a>.


There can be zero or more groups of triples

## Reifier, no triple with that as subject :s :p :o1 ~:r . ## Same as :s :p :o1 ~:r {} .

## Two reifiers, each with triples. :s :p :o2 {| ex:signedOffBy "A" |} {| ex:signedOffBy "B" |} .

In this example, reificationRequired is more count-like. This includes 0 -- the first example above -- here the reifier is allocated for later use.

Node Expressions, or SPARQL-based targets can be used for that use case.

How? SPARQL-based constraints can do many things but what would node expressions look like?

General observation: Pushing things onto node expressions may work technically but they aren't necessarily a friendly way to express things. If the WG decides to publish core as a REC ASAP, then core is then fixed and unchangeable. The WG needs to be certain that pushing out things out to phase2 actually ends up with the best outcome.

We can handle that change in a separate PR. That's why I've moved the discussion back to the issue.

Co-authored-by: Andy Seaborne <[email protected]>

TallTed

A few changes, which I hope improve clarity and readability.

shacl12-core/index.html

Co-authored-by: Ted Thibodeau Jr <[email protected]>

afs · 2025-04-28T09:40:58Z

This PR is motivated to the annotation pattern/syntax in RDF 1.2 Turtle.

Annotation hides the reifier although the reifier can be explicitly given.

The property shape object of sh:reifiableBy is applied to asserted triples whose subject is the reifier.

sh:reifiableBy could instead be named sh:describedBy or sh:tripleDescribedBy or sh:annotatedBy.

With explicit reifier:

:s :p :o ~:r {| ex:signedOffBy "A" |}

then the name sh:reifiableBy could be used to get the reifier (node shape).

TallTed · 2025-04-28T11:34:15Z

The property shape object of sh:reifiableBy is applied to asserted triples whose subject is the reifier.

sh:reifiableBy could instead be named sh:describedBy or sh:tripleDescribedBy or sh:annotatedBy.

I must be missing something somewhere. Why not sh:reifiedBy?

HolgerKnublauch · 2025-04-28T15:16:13Z

@TallTed the name probably was copied from dash:reifiableBy. The reason is that reifiedBy would mean that reification is required, while reifableBy means that if a reification exists then it must have the given shape.

TallTed · 2025-04-28T16:14:45Z

sh:reifableBy means that if a reification exists then it must have the given shape

Fair enough.

afs · 2025-04-28T19:34:46Z

I think Ted has a point.

To get to the focus node for the annotations (data graph traversal), there must be a connection between the reifier (blank node or the :r above) and the current triple as a triple term. This is the rdf:reifies triple(s) with this focus triple as a triple term in the object position.

The annotation syntax checking resides in ex:ProvenanceShape.

The focus node of ex:ProvenanceShape is the reifier.
If it has no other constraints, it becomes a test for the existence of rdf:reifies.
(implicitly it has sh:property [ sh:path rdf:reifies ])

Suggestion: rename sh:reifiableBy as

sh:reifierShape -- "The [node shape] that a reifier for this triple must conform to."

ex:PersonShape-age
  a sh:PropertyShape ;
  sh:path ex:age ;
  sh:datatype xsd:integer ;
  sh:maxCount 1 ;
  sh:reifierShape ex:ProvenanceShape ;
  .

ex:ProvenanceShape
    sh:property [ 
      sh:path rdf:reifies ;
      sh:nodeKind sh:IRI ; ## e.g. requires the reifier to be an IRI
    ] ;
    sh:property [
      sh:path ex:author ;
      sh:nodeKind sh:IRI ;
      sh:maxCount 1 ;
    ] .
] .

There can be multiple reifiers, each with an annotation blocks in the syntax. I'm not sure what that is going to look like.

bergos · 2025-05-12T19:59:09Z

I've renamed sh:reifiableBy to sh:reifierShape. Also, "reified statement" has been replaced with "reifier" to match the RDF Concepts specification.

@afs
Did you mean the inverse of rdf:reifies?

ex:ProvenanceShape
    sh:property [ 
      sh:path rdf:reifies ; # inverse?
      sh:nodeKind sh:IRI ; ## e.g. requires the reifier to be an IRI
    ]
] .

bergos · 2025-05-31T06:53:31Z

@afs @TallTed @HolgerKnublauch Can you please review the latest changes?

HolgerKnublauch · 2025-06-02T10:56:36Z

shacl12-core/index.html

+					<p>
+						<code>sh:reifierShape</code> can be used to link a <a>property shape</a> with one or more <a>node shapes</a>.
+						Any <a>reifier</a> must conform to these node shapes.
+						If a property shape contains a <code>sh:ReifierShapeConstraintComponent</code>, <code>sh:path</code> values are constrained to IRIs.


The term "contains" is unclear here and I think it would be better to say "if a property shape has a value for sh:reifierShape...

Also I believe this is a formal constraint and needs to be moved into a data-syntax-rule, i.e. under the parameter definition of sh:reifierShape.

HolgerKnublauch · 2025-06-02T11:00:16Z

shacl12-core/index.html

+						<div class="def-text-body" data-validator="ReifierShape">
+							Let <code>t</code> be the <a>triple term</a> (<a>focus node</a>,  <code>$path</code>, <a>value node</a>).
+							For each <a>reifier</a> for the <a>triple term</a> <code>t</code>, a failure MUST be produced if validating the <a>reifier</a> against the <a>node shape</a> <code>$reifierShape</code> with the <a>reifier</a> as <a>focus node</a> produces a <a>failure</a>.
+							Otherwise, if the <a>reifiers</a> of <code>t</code> do not conform to <code>$reifierShape</code>, there is a validation result with <code>t</code> as <code>sh:value</code>.


"if the reifiers" is unclear: do you mean any of them or all of them, some etc. Better write it like "For each reifier t that does not conform..."

HolgerKnublauch · 2025-06-02T11:02:08Z

shacl12-vocabularies/shacl.ttl

+
+sh:reifierShape
+	a rdf:Property ;
+	rdfs:label "reifiable by"@en ;


-> "reifier shape"

HolgerKnublauch · 2025-06-02T11:03:26Z

I have approved this for now, but I expect further changes will happen in follow-up tickets. It is important though to get this into the main branch to have a starting point.

#300: Added support for RDF 1.2 triple terms

f8242fc

bergos requested review from HolgerKnublauch, YoucTagh and siwerner April 21, 2025 18:31

HolgerKnublauch reviewed Apr 21, 2025

View reviewed changes

shacl12-core/index.html Outdated Show resolved Hide resolved

HolgerKnublauch reviewed Apr 21, 2025

View reviewed changes

shacl12-core/index.html Outdated Show resolved Hide resolved

afs reviewed Apr 21, 2025

View reviewed changes

shacl12-test-suite/tests/core/node/reifiableBy-001.ttl Outdated Show resolved Hide resolved

afs reviewed Apr 21, 2025

View reviewed changes

bergos and others added 2 commits April 22, 2025 07:27

Update shacl12-test-suite/tests/core/node/reifiableBy-001.ttl

7551c02

Co-authored-by: Andy Seaborne <[email protected]>

Limit path for reification to IRIs

de746c3

HolgerKnublauch reviewed Apr 22, 2025

View reviewed changes

shacl12-core/index.html Outdated Show resolved Hide resolved

afs reviewed Apr 22, 2025

View reviewed changes

shacl12-core/index.html Outdated Show resolved Hide resolved

afs reviewed Apr 22, 2025

View reviewed changes

bergos and others added 2 commits April 24, 2025 09:05

Improved reifiableBy definitions, moved sh:path constraint

345eb4c

Apply suggestions from code review

48bef5e

Co-authored-by: Andy Seaborne <[email protected]>

TallTed requested changes Apr 24, 2025

View reviewed changes

shacl12-core/index.html Outdated Show resolved Hide resolved

shacl12-core/index.html Outdated Show resolved Hide resolved

shacl12-core/index.html Outdated Show resolved Hide resolved

Apply suggestions from code review

c598b86

Co-authored-by: Ted Thibodeau Jr <[email protected]>

afs mentioned this pull request Apr 28, 2025

Support for RDF 1.2 triple terms #300

Open

Renamed to sh:reifierShape

3ced0c9

bergos mentioned this pull request May 12, 2025

Support for RDF 1.2 triple terms (without asserted triple) #379

Open

bergos requested review from afs, TallTed and HolgerKnublauch May 25, 2025 19:54

HolgerKnublauch approved these changes Jun 2, 2025

View reviewed changes

#300: Added support for RDF 1.2 triple terms #368

Are you sure you want to change the base?

#300: Added support for RDF 1.2 triple terms #368

Uh oh!

Conversation

bergos commented Apr 21, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

afs Apr 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bergos Apr 22, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

afs Apr 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

afs Apr 22, 2025

Choose a reason for hiding this comment

Uh oh!

bergos Apr 24, 2025

Choose a reason for hiding this comment

Uh oh!

TallTed left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

afs commented Apr 28, 2025

Uh oh!

TallTed commented Apr 28, 2025

Uh oh!

HolgerKnublauch commented Apr 28, 2025

Uh oh!

TallTed commented Apr 28, 2025

Uh oh!

afs commented Apr 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bergos commented May 12, 2025

Uh oh!

bergos commented May 31, 2025

Uh oh!

HolgerKnublauch Jun 2, 2025

Choose a reason for hiding this comment

Uh oh!

HolgerKnublauch Jun 2, 2025

Choose a reason for hiding this comment

Uh oh!

HolgerKnublauch Jun 2, 2025

Choose a reason for hiding this comment

Uh oh!

HolgerKnublauch Jun 2, 2025

Choose a reason for hiding this comment

Uh oh!

HolgerKnublauch commented Jun 2, 2025

Uh oh!

Uh oh!

afs Apr 21, 2025 •

edited

Loading

afs Apr 22, 2025 •

edited

Loading

afs commented Apr 28, 2025 •

edited

Loading