Asserting inverse properties (skos:topConceptOf)

[Dan Segal]

Is there a way to assert an inverse property into the source code of a concept?

For example, where we have:

conceptScheme skos:hasTopConcept concept

we want to assert:

concept skos:topConceptOf conceptScheme

Since skos:topConceptOf is defined as the inverse of skos:hasTopConcept, the relationship displays in the form view.   However, we want to assert the statement so that the triple concept skos:topConceptOf conceptScheme is written to the RDF.

Have tried a property rule, as well executing inference rules.  Neither results in the inverse relationship being written to RDF.

Thank you

[Holger Knublauch]

Hi Dan,

yes this can be achieved through a dash:ChangeScript, see https://archive.topquadrant.com/doc/latest/ext/points.html#change-and-commit-scripts

Basically, such scripts are triggered after every change and may perform additional changes. In this case, whenever a skos:hasTopConcept gets asserted, it would need to assert the corresponding inverse triple. And the same for deleting triples. To work consistently, it would need to operate in both directions.

Note that in contrast to ChangeScripts, inference rules such as sh:values rules are only computed on demand and not persisted. They are only computed to populate the user interface, for example when you look at the narrower concepts that render as inverse of skos:broader triples. We only store these in one direction, and do so intentionally because having an inverse triple is just adding extra costs and drive up the maintenance burden as it is easy to get into situations where the two directions become out of synch. Therefore we strongly discourage using explicit inverse triples, instead preferring sh:inversePath declarations.

In my personal opinion, introducing inverse properties with OWL was a major mistake, and it got unfortunately propagated into SKOS too. As RDF triples are symmetric between subjects and objects, and graphs can be walked in both directions equally.

Do you have downstream tools that require these explicit inverse triples?

Holger

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c4724215-481a-4c08-960b-7c29ffb16169n%40googlegroups.com.

[David Price]

On 17 Apr 2024, at 09:18, Holger Knublauch <hol...@topquadrant.com> wrote:

Hi Dan,

yes this can be achieved through a dash:ChangeScript, see https://archive.topquadrant.com/doc/latest/ext/points.html#change-and-commit-scripts

Basically, such scripts are triggered after every change and may perform additional changes. In this case, whenever a skos:hasTopConcept gets asserted, it would need to assert the corresponding inverse triple. And the same for deleting triples. To work consistently, it would need to operate in both directions.

Note that in contrast to ChangeScripts, inference rules such as sh:values rules are only computed on demand and not persisted. They are only computed to populate the user interface, for example when you look at the narrower concepts that render as inverse of skos:broader triples. We only store these in one direction, and do so intentionally because having an inverse triple is just adding extra costs and drive up the maintenance burden as it is easy to get into situations where the two directions become out of synch. Therefore we strongly discourage using explicit inverse triples, instead preferring sh:inversePath declarations.

Holger is 100% right on the “discourage using explicit inverse triples” idea. They are nearly impossible to keep synch’d and we have recent customer situations where we had to “undo” that mistake as part of a data model V2 and related data migration.

In my personal opinion, introducing inverse properties with OWL was a major mistake, and it got unfortunately propagated into SKOS too. As RDF triples are symmetric between subjects and objects, and graphs can be walked in both directions equally.

From a modeller’s perspective the main “good” reason to include inverse properties in SHACL it is so that the reverse property can have cardinality constraints. That need does pop up, so almost all data modelling languages/standards support the idea of inverse relations with cardinality. It’s not specific to RDF-land.

Cheers,

David

Do you have downstream tools that require these explicit inverse triples?

Holger

On 16 Apr 2024, at 8:03 PM, Dan Segal <dan.seg...@gmail.com> wrote:

Is there a way to assert an inverse property into the source code of a concept?

For example, where we have:

conceptScheme skos:hasTopConcept concept

we want to assert:

concept skos:topConceptOf conceptScheme

Since skos:topConceptOf is defined as the inverse of skos:hasTopConcept, the relationship displays in the form view.   However, we want to assert the statement so that the triple concept skos:topConceptOf conceptScheme is written to the RDF.

Have tried a property rule, as well executing inference rules.  Neither results in the inverse relationship being written to RDF.

Thank you

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c4724215-481a-4c08-960b-7c29ffb16169n%40googlegroups.com.

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/67C9D2F5-C581-4F8E-AB40-CEB3A897DCBB%40topquadrant.com.

[Steve Ray]

Actually, David, you don't need the explicit inverse even for cardinality constraints. Here's a snippet from a standard I'm working on:

sh:property [

sh:path [

sh:inversePath s223:observes ;

] ;

rdfs:comment "An instance of s223:Property must not be observed (set) by more than one entity." ;

sh:maxCount 1 ;

sh:message "s223: An instance of s223:Property must not be observed (set) by more than one entity." ;

] ;

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/B22B3DED-5DAF-4EFA-8363-9844EF1D3CD8%40topquadrant.com.

[David Price]

Sure Steve, that’s exactly what I was talking about …  I guess I did not word my reply very weill if it was confusing to you or anyone else.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep87FP4RUijLaRXwNED3yWCjf_AzTf_0KCRRMo8gtg5bf7g%40mail.gmail.com.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Steve Ray]

OK, fair enough. I did think that you were saying that was a case where you needed an explicit inverse relation.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/ABFA60BB-6A24-4705-B0A7-4E57A13578C6%40topquadrant.com.