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 >>> <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 >>> <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 >>> <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] > <mailto:[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 > <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] >> <mailto:[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 >>> <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 >>> <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 >>> <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] >>> <mailto:[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] >> <mailto:[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] >> <mailto:[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] > <mailto:[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] > <mailto:[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.
