inheritance & reuse

Howdy.

I have started looking at the current draft spec from the point of view of a shape designer (‘shapist’, ’shacler’?).

I am using the spec to think through a current project, which is essentially an enterprise level information model abstraction using OWL. Adding shapes into the mix brings in many of the issues described in https://www.w3.org/2014/data-shapes/track/issues/44, among others. This is allowing me to understand what you have done, and test some of the ideas in an applied setting. I am using Holger’s test harness (https://github.com/TopQuadrant/shacl) as a way to explore this.

Anyone wanting to implement shapes will find managing them a major challenge.  Much more so than ontologies, the number of different sets of constraints a reasonably sized enterprise might need to implement will lead to a large number of shapes applicable in different scenarios, and at different points in enterprise workflows. Start exposing these alongside open data, and it will get worse. As a result, there will be lots of shape graphs with some degree of variation between them, but also with much in common. Even within a given shapes graph, there will be many shapes that share the same characteristics. In the same way that we build reusable code libraries, we will want to build reusable shapes and shape parts. One could even foresee some of these served up through open data shape repositories.

For the moment, I am looking at what I can do within a given shapes graph. I am limited in terms of what I can test with owl:imports, as this would really require the test harness to support something like TriG (or JSON-LD) so that I could define multiple graphs and explore the ramifications of merging triple sets between them (I think jena supports this, though WGTest seems hard coded to turtle). However, I can explore most of the implications from within a single shapes graph.

I have written a series of test cases to validate my interpretations of what you have written. I am hopeful that this may actually serve to reduce some of the ambiguities in the spec, in particular how SHACL relates to RDFS and OWL from a practical standpoint, which is far from clear (to me at least). If this useful to you, I am happy to create a pull request to add the tests to the test bank – it doesn’t look like I am overlapping with the current set. I am also happy to work on other similar scenarios. If this is not useful to you, it’s still a good learning experience for me. Happy to discuss as well.

  1.  Reusing the same constraint definitions (reuse-001, OK)
  2.  Having a shape use another shape definition:
     *   By explicitly referencing it* (reuse-002, the test that fails is a possible enhancement to the spec)
     *   Through shape class inheritance (inheritance-001, this test fails – not sure if it’s a bug in the test or this is what is supposed to happen)
  3.  Having a shape apply to data graph subclasses of a class in its scope (inheritance-003, OK).
  4.  The ramifications of shape merging through reuse, inheritance, and owl:import.
     *   The same shape with overlapping constraints (inheritance-002, fails for the same reason inheritance-001 fails)
     *   Different shapes with the same scope and overlapping constraints (inheritance-004, OK)
     *   Duplicated triples in data graphs (e.g. If there are instances of shape classes in the owl:import) (duplication-001, OK)
  5.  The effect of uniqueLang when language is not specified (uniqueLang-001, fails)

*I think this is something missing from the spec. I should be able to use sh:shape from one shape to another: ex:Shape1 sh:shape ex:Shape2. Compare ex:Shape2 with ex:Shape3 in the enclosed reuse-002.ttl. Of course, similar effects could be achieved with rdfs:subClassOf on shapes, though this doesn’t appear to work currently.

(A minor request on the test harness: it would be useful if it spat out a positive message with the filename on a successful test result. It’s sometimes hard to work out what you’re testing. It’s not a big deal, though.)

Chz
Patrick Johnston (magyarblip)