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 > On 16 Apr 2024, at 8:03 PM, Dan Segal <dan.segal.w...@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 topbraid-users@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-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@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 > > <https://groups.google.com/d/msgid/topbraid-users/c4724215-481a-4c08-960b-7c29ffb16169n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- The topics of this mailing list include TopBraid EDG and related technologies such as SHACL. To post to this group, send email to topbraid-users@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-users+unsubscr...@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.
