Hi Irene & Holger, Thank you for the explanation. It is definitely my mistake in how I modeled the constraint in SHACL. I missed the mark as I was intending to say edg:output "all values from <this union of classes>. I will fix this.
With respect to using the same property to point to different things from the same class/node shape, I see a number of uses for such a pattern. Consider membership in an organization where we have, say, three types of organizations: Religious, Professional, and Social. My first modeling attempt would be to create a class hierarchy with Religious, Professional and Social being subclasses of Organization. I would create a memberOf property and use it to associate a person with their organizations. For user interaction, I would want the user to be able to enter their memberships by class, much like the career vs education section of a resume. The form would need a section for each type of organization and a constraint that limited the user's selection to the relevant type of organization. What I've learned from this thread is that I would need a property tree that essentially mirrors the class tree to be able to do this in EDG which removes one of the benefits of using upper ontologies that contain properties that work in a number of different contexts. Regardless, I will create properties to support my device/output use case. *So one final question...* I chose to use edg:output because it is semantically correct but also because lineage diagrams respond to this property as well as the calculation of upstream and downstream dependencies.. How do I ensure my properties will be used in lineage diagrams as well as up/downstream calculations? I believe Ralph has said that creating properties as subproperties of edg:output will have the intended effect but I wanted to confirm. Are there other properties that I can use as a root element to achieve the same result in the cases where input and output are not semantically correct? Thanks, Tim On Tue, Jul 7, 2020 at 11:57 PM Holger Knublauch <[email protected]> wrote: > Just to add a tiny bit of info in case it's not clear: > > If you have multiple property shapes on the same property (anywhere in the > superclass hierarchy) the semantics of them will be merged together. It > doesn't matter if the PropertyShape instance is different - the constraints > are simply all treated the same. This also means all sh:class constraints > would be checked together and the instances need to fulfill them all. This > usually only works if there is a subclass relationship between those. > > Holger > > > On 8/07/2020 13:47, Irene Polikoff wrote: > > Hi Tim, > > It would be highly irregular to create, for the same class/node shape, > multiple property shapes with the same path and give them different > sh:name. It would be misleading as, in the data, these will be the same > properties. > > Further, what you are defining below is contradictory > > pgont:FVNR >>> a edg:CustomAssetClass ; >>> a sh:NodeShape ; >>> edg:acronym "FVNR" ; >>> edg:description "To Be Determined" ; >>> rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ; >>> rdfs:label "FVNR" ; >>> rdfs:subClassOf pgont:ElectricMotorStarter ; >>> sh:property pgont:FVNR_Sts_Overload-output ; >>> sh:property pgont:FVNR_Sts_Running-output ; >>> . >>> pgont:FVNR_Sts_Overload-output >>> a sh:PropertyShape ; >>> sh:path edg:output ; >>> rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ; >>> sh:class pgont:FaultCondition ; >>> sh:description "FF: Control Overload" ; >>> sh:group edg:TraceableGroup ; >>> sh:maxCount 1 ; >>> sh:name "Sts_Overload" ; >>> sh:order "25"^^xsd:decimal ; >>> . >>> pgont:FVNR_Sts_Running-output >>> a sh:PropertyShape ; >>> sh:path edg:output ; >>> rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ; >>> sh:class pgont:RunningStatus ; >>> sh:description "FF: Running Status" ; >>> sh:group edg:TraceableGroup ; >>> sh:maxCount 1 ; >>> sh:name "Sts_Running" ; >>> sh:order "25"^^xsd:decimal ; >>> >>> > The first property shape says that an instance of pgont:FVNR can have at > most one value for edg:output and the value must be a member of > pgont:FaultCondition class. > > The second property shape says that an instance of pgont:FVNR can have at > most one value for edg:output and the value must be a member of > pgont:RunningStatus class. > > The only way this could be true is if:either pgont:RunningStatus is a > subclass of pgont:FaultCondition or pgont:FaultCondition is a subclass of > pgont:RunningStatus AND, of course, these shapes say that you would not > have more than one triple with a given subject and edg:output as a > predicate. > > Qualified value shapes will solve this problem, but on the form it is the > same path and there is no way to separate these triples. Ultimately, you > would have in the data: > > :R1 edg:output :R2, :R3 and so on. > > And the UI will display them together. The edit form is not going to be > able to figure out that {:R1 edg:output :R2} corresponds to the property > shape 1 while {:R1 edg:output :R3} corresponds to the property shape 2 and > therefore it should, somehow, display them separately and let you enter and > modify them separately. > > This addressed the common OWL use case where the same property pointed to > instances of different classes > > > Yes, you can do this with SHACL by either having all these classes be a > subclass of a common parent or by using qualified value shapes. > > and it was pertinent to the user to show them the class of the instance to > tell them what they were seeing. > > > This does not change the nature of the property in the data, so the field > name itself is the same. The values would have different types. > > If this is for display only (basically a report) and not for editing, you > could generate a view that would display whatever you want e.g., display > the class they belong to in parenthesis after each resource. > > You could, for example, create another property e.g., :typedOutput and > back it by sh:values rule that would generate its values by taking labels > of the resources that are values of edg:output and appending the class > label to them. > > > On Jul 7, 2020, at 9:14 PM, Tim Smith <[email protected]> wrote: > > Hi Holger, > > Thank you for the tip on QualifiedValueShapeConstraintComponent. I'm not > deep enough into SHACL to reliably make the best choice. Time is the best > teacher! > > Regarding sh:name... I was specifically trying to avoid "property > proliferation" as I already have "class proliferation" when capturing the > different types of outputs for the 128 device types in my model. One of my > perceived benefits of SHACL was to be able to reuse properties but give > each use a different semantic meaning by naming the property shape > accordingly. This addressed the common OWL use case where the same > property pointed to instances of different classes and it was pertinent to > the user to show them the class of the instance to tell them what they were > seeing. > > Prior to today, I thought the forms just pulled the name from sh:name but > I see now that it does something like pulling the first sh:name it > encounters for a specific sh:path and re-uses it. I noticed this artifact > when looking at more complicated device types that have numerous outputs > like a Flow Controller. FVNR is a simple case. Is there a reason that the > form doesn't just display the sh:name to the user, regardless of the > property? I'm trying to determine if the user interface is about to drive > the modeling or if there is some underlying aspect of SHACL that I'm > missing. If it's the former, is there a possibility to re-visit the > implementation? I have 128 classes that have this problem. (note that it > won't take 128 properties to fix it but it is a common modeling pattern in > my domains) > > Thanks, > > Tim > > > On Tue, Jul 7, 2020 at 8:43 PM Holger Knublauch <[email protected]> > wrote: > >> Hi Tim, >> >> if you want to use the same property I think you're rather looking at >> >> https://www.w3.org/TR/shacl/#QualifiedValueShapeConstraintComponent >> >> to say that "one of them needs to be running indicator" and "one of them >> needs to be fault indicator". >> >> But while that would work on a constraint checking level, it will not >> make sense w.r.t. sh:name and the form editor. The label should be the same >> in both cases, which I believe indicates that you're better off introducing >> separate properties. >> >> Holger >> >> >> On 8/07/2020 10:02, Tim Smith wrote: >> >> Hi Holger, >> >> In this case, that is correct. The FVNR class represents a physical >> device, a type of electric motor starter. These devices have two outputs, >> a running indicator and a fault indicator. These outputs are typically >> wired into a Programmable Logic Controller (PLC). Thus, I've chosen to >> model the outputs as specific types of data elements. This model is >> intended to be able capture and show lineage for all of the data elements >> produced by devices on a manufacturing line. This data typically flows >> into a PLC and out into various OT/IT systems. It will also enable me to >> capture the control loops on the line. >> >> I own the model and am open to better ways of doing it. >> >> Tim >> >> On Tue, Jul 7, 2020 at 7:13 PM Holger Knublauch <[email protected]> >> wrote: >> >>> Hi Tim, >>> are you sure both property shapes are about the same property >>> edg:output? This doesn't look right because they carry different sh:class >>> constraints in both cases. >>> >>> Regards, >>> Holger >>> >>> >>> On 8/07/2020 04:52, Tim Smith wrote: >>> >>> Hi, >>> >>> I am auto-generating classes and property shapes from spreadsheets. I >>> have an issue where EDG is not displaying the name of the property shape >>> correctly in the declared properties section of a class form. In the >>> example below, note that Sts_Overload is displayed as the property name in >>> both cases but sh:name contains Sts_Running for the upper entry. Source >>> code for the class/node shape and property shapes is pasted at the bottom. >>> This is happening for all of my generated classes but does not happen for >>> classes and property shapes I manually create in EDG. >>> >>> Note that when I say generated, I use an insert query in TBC to >>> construct the triples from a spreadsheet and insert them into an empty >>> graph. The graph containing the triples is then imported into an empty >>> ontology in EDG. >>> >>> I'm baffled as to what is different and I'm hoping another set of eyes >>> will see the problem. Thanks in advance for your help, >>> >>> Tim >>> <image.png> >>> pgont:FVNR >>> a edg:CustomAssetClass ; >>> a sh:NodeShape ; >>> edg:acronym "FVNR" ; >>> edg:description "To Be Determined" ; >>> rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ; >>> rdfs:label "FVNR" ; >>> rdfs:subClassOf pgont:ElectricMotorStarter ; >>> sh:property pgont:FVNR_Sts_Overload-output ; >>> sh:property pgont:FVNR_Sts_Running-output ; >>> . >>> pgont:FVNR_Sts_Overload-output >>> a sh:PropertyShape ; >>> sh:path edg:output ; >>> rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ; >>> sh:class pgont:FaultCondition ; >>> sh:description "FF: Control Overload" ; >>> sh:group edg:TraceableGroup ; >>> sh:maxCount 1 ; >>> sh:name "Sts_Overload" ; >>> sh:order "25"^^xsd:decimal ; >>> . >>> pgont:FVNR_Sts_Running-output >>> a sh:PropertyShape ; >>> sh:path edg:output ; >>> rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ; >>> sh:class pgont:RunningStatus ; >>> sh:description "FF: Running Status" ; >>> sh:group edg:TraceableGroup ; >>> sh:maxCount 1 ; >>> sh:name "Sts_Running" ; >>> sh:order "25"^^xsd:decimal ; >>> . >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLc5O0h1Q29OB5ZAqPfmYkT0KbrfVkyJmy7z8-iZdqBsA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLc5O0h1Q29OB5ZAqPfmYkT0KbrfVkyJmy7z8-iZdqBsA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/topbraid-users/f9493d61-59fe-b295-373c-899efeffb5e6%40topquadrant.com >>> <https://groups.google.com/d/msgid/topbraid-users/f9493d61-59fe-b295-373c-899efeffb5e6%40topquadrant.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/CAF0Wbn%2BYFYEp-1aMyt6tKB_ajJHBCbjNA2MRZ-xsdXV_FwcRsw%40mail.gmail.com >> <https://groups.google.com/d/msgid/topbraid-users/CAF0Wbn%2BYFYEp-1aMyt6tKB_ajJHBCbjNA2MRZ-xsdXV_FwcRsw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/87b2543a-36c1-0dca-6901-30b5faa0b7b3%40topquadrant.com >> <https://groups.google.com/d/msgid/topbraid-users/87b2543a-36c1-0dca-6901-30b5faa0b7b3%40topquadrant.com?utm_medium=email&utm_source=footer> >> . >> > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLigyhpXZEnwUhdccdjURmYKF%2BbrnSb84ReJW1RLEcC%2BA%40mail.gmail.com > <https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLigyhpXZEnwUhdccdjURmYKF%2BbrnSb84ReJW1RLEcC%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/35C166CF-900B-4FFB-9766-C911F10EFB2A%40topquadrant.com > <https://groups.google.com/d/msgid/topbraid-users/35C166CF-900B-4FFB-9766-C911F10EFB2A%40topquadrant.com?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/20eb8f08-cdb4-7617-e9c2-fe80f872949e%40topquadrant.com > <https://groups.google.com/d/msgid/topbraid-users/20eb8f08-cdb4-7617-e9c2-fe80f872949e%40topquadrant.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJx_rRVJ2FuO%2BZimmXNp7fLh2%3DEW_ZrQx8pX-pTj88P7w%40mail.gmail.com.
