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 > On 17 Apr 2024, at 14:21, Steve Ray <st...@steveray.com> wrote: > > 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 > > > > > On Wed, Apr 17, 2024 at 4:36 AM David Price <dpr...@topquadrant.com > <mailto:dpr...@topquadrant.com>> wrote: >> >> >>> On 17 Apr 2024, at 09:18, Holger Knublauch <hol...@topquadrant.com >>> <mailto: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.segal.w...@gmail.com >>>> <mailto: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 >>>> <mailto: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 >>> <mailto: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/67C9D2F5-C581-4F8E-AB40-CEB3A897DCBB%40topquadrant.com >>> >>> <https://groups.google.com/d/msgid/topbraid-users/67C9D2F5-C581-4F8E-AB40-CEB3A897DCBB%40topquadrant.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 >> <mailto: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/B22B3DED-5DAF-4EFA-8363-9844EF1D3CD8%40topquadrant.com >> >> <https://groups.google.com/d/msgid/topbraid-users/B22B3DED-5DAF-4EFA-8363-9844EF1D3CD8%40topquadrant.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 > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/CAGUep87FP4RUijLaRXwNED3yWCjf_AzTf_0KCRRMo8gtg5bf7g%40mail.gmail.com > > <https://groups.google.com/d/msgid/topbraid-users/CAGUep87FP4RUijLaRXwNED3yWCjf_AzTf_0KCRRMo8gtg5bf7g%40mail.gmail.com?utm_medium=email&utm_source=footer>. UK +44 (0) 7788 561308 US +1 (336) 283-0808 -- 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/ABFA60BB-6A24-4705-B0A7-4E57A13578C6%40topquadrant.com.
