Expected behavior of sh:or on an EDG form and EDG Diagram

[Tim Smith]

Hi,

I have three classes:

Consumer Unit

Inner Pack

Case.

I need a property constraint on Case, using the property ex:contains (an Object Property), to say:

Case ex:contains one or more (Consumer Unit OR Inner Pack) instances.

Following the example found at sh:or, I created the following:

ex:Case
  a owl:Class ;
  a sh:NodeShape ;
  rdfs:label "Case" ;
  rdfs:subClassOf owl:Thing ;
  sh:property ex:Case-contains ;
.
ex:Case-contains
  a sh:PropertyShape ;
  sh:path ex:contains ;
  sh:group ex:ExamplePropertyGroup ;
  sh:minCount 1 ;
  sh:name "contains" ;
  sh:or (
      [
        sh:class ex:InnerPack ;
      ]
      [
        sh:class ex:ConsumerUnit ;
      ]
    ) ;
.

When creating an instance of Case, I thought I would see only instances of InnerPack or ConsumerUnit in the auto-complete.  However, I am seeing everything - instances and classes, etc.  If I select something other than InnerPack or ConsumerUnit, I will see a SHACL constraint violation indicating the selection is not a valid shape so it is reading the constraint.

In addition, there is no "+" sign for the creation of new instances - should there be?  It would be helpful.  Navigating back to Inner Pack to create a new instance is a lot of clicks, especially if Inner Pack needs to be in a different asset collection as happens frequently when using the EDG ontologies.

And finally, placing the class, Case, on an EDG Diagram and using the "Expand Associations" option, Level 1 or Level 2, does not display anything.  If I expand the sh:property relationship manually, I will see the property shape but the sh:or(sh:class) statements are ignored.

What is the expected behavior?  What do I need to do to limit the instances the user sees to the evaluation of the sh:or?  It is also important that the sh:or relationship and target classes are visible on an EDG Diagram otherwise a user cannot see the ontology graphically.

Attached is a zip export of the example ontology and data graph that depicts the above.  I'm using EDG 7.3.

Thank you in advance for your input,

Tim

[David Price]

It’s far simpler to make an abstract superclass of the two classes of interest. Everything mentioned works out-of-the-box and avoid Source Code SHACL editing, etc.

Cheers,

David

--
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/b6dcb60e-4f3a-4296-99f9-2a0bacd14120n%40googlegroups.com.
<sh_or_shape_test.zip>

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Tim Smith]

Hi David,

Yes, that is how I used to do it before SHACL was available.  However, the downside is class bloat that is not easily hidden in the UI.  I will have lots of classes that have no semantic meaning other than to provide a grouping mechanism against which I can write constraints, essentially embedding Boolean logic using inheritance.  I would need to hide them in class trees, EDG diagrams, etc.

The impetus for this work is to create a complete SHACL model of our master data to demonstrate the superiority of using EDG for this task over our traditional modeling tools like Erwin.  So far EDG is more expressive, able to capture a semantically robust representation of the domain resulting in a far superior conceptual model.  But EDG is weak on visualization, especially EDG Diagram (although it is much better than NeighborGram).  If I have to introduce "fake" classes to support constraints, then I will lose for sure.  I'm already spending lots of energy building graph visualizations using Tom Sawyer Software's Perspectives platform to compensate for EDG Diagram's weaknesses.  Tom Sawyer goes live against the EDG SPARQL endpoint and links back to the resource URLs in EDG.  (Now if the endpoint only supported named graphs!!!)

Tim

[David Price]

Hi Tim,

Just a comment or two …

Pet peeve: rdfs:subClassOf is part of SHACL so not going outside it. subClassOf is actually subSetOf and so is just using set theory rather than Boolean logic. 

Rationale: There is not actually any inheritance in rdfs:subClassOf, I know we all pretend there is but what actually happens is the instance is made a member of all superclasses so it gets the properties directly. These are not “fake” classes, they are just giving a URI to something that is anonymous otherwise. I find that easier to show and explain for the union/or case, and that was true with OWL models too. I never understood why the idea that calculating restrictions or now sh:or on-the-fly is somehow better than asserting it (which, for example makes it easily SPARQL-able which is not true otherwise). 

That said, there are certainly improvements that can be made in EDG OR support.  I’ve made 3 tickets in our system for the sh:or items you reported: autocomplete, + and EDG diagram. Hope that helps.

I guess for you the tactical question is whether you can live with things wrt sh:or as-is for a while OR to get the other features today maybe make tactical use of rdfs:subClassOf now with a plan to move off it when the sh:or requirements you mention are met.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1d7fbe6a-24f5-437f-9605-fa6b87c58fcbn%40googlegroups.com.

[Tim Smith]

Thanks for the insight David.  A good user experience is always a trade-off.  The complexity must exist somewhere - in the model or in the UI implementation.  Getting people to adopt new technologies, new ways of thinking is challenging and a well-executed UI can sometimes make or break it.

Tim