Q: EDG - How does display property shapes?

[Tim Smith]

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

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 ;
.

[Holger Knublauch]

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

--
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/CAF0WbnLc5O0h1Q29OB5ZAqPfmYkT0KbrfVkyJmy7z8-iZdqBsA%40mail.gmail.com.

[Tim Smith]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f9493d61-59fe-b295-373c-899efeffb5e6%40topquadrant.com.

[Holger Knublauch]

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

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.

[Tim Smith]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/87b2543a-36c1-0dca-6901-30b5faa0b7b3%40topquadrant.com.

[Irene Polikoff]

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

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.

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

[Holger Knublauch]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/35C166CF-900B-4FFB-9766-C911F10EFB2A%40topquadrant.com.

[Tim Smith]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/20eb8f08-cdb4-7617-e9c2-fe80f872949e%40topquadrant.com.

[Irene Polikoff]

Hi Tim

On Jul 8, 2020, at 12:56 PM, Tim Smith <smith...@gmail.com> wrote:

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?

I would trust whatever information you got from Ralph. He is the expert on how the lineage diagram works.

[Ralph TQ [Gmail]]

Hi Tim,

In the forthcoming TopBraid EDG 6.4 release, rather than sub-properties, the decision has been to use meta-properties. There are 4 meta-properties to take note of:

1. edg:ImpactProperty         — downstream dependents inferencing
2. edg:LineageProperty       — upstream dependents inferencing
3. edg:PartOfProperty         — derivation map nodes use this for composite structure
4. edg:CompositeProperty  — derivation map nodes use this for composite structure

Using these meta-properties makes the lineage diagram, impact diagram and derivation maps more generic.

Ralph

--
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/E7AC2ECA-6C0C-4591-B37D-7016F817BC9D%40topquadrant.com.