Making SHACL Work For Industry

To whom it may concern,

As any early adopter of semantic technologies in a large corporate environment knows, the promise of semantic technology has been great but the functionality behind the promise has been slow in coming.  Only in recent years, have industry use cases been supported by evolving standards and strong, scalable product offerings.

Over the last five years or so, we have addressed dozens of use cases (100+ now, I believe) using one form or another of semantic technology.  We have been most successful in gaining adoption of technologies and approaches that have their root in a global standard.  We have also, however, been early adopters of approaches that we feel have potential to provide tremendous benefit that outweighs the risk of proprietary solutions.  To that end, it has been with great hope that we have watched the evolution of the SHACL standard.

Early on, we recognized the limitations of OWL restrictions as a constraint language and began searching for more flexible alternatives.  Our use cases include the typical object-centric needs (cardinality, type, range, etc....) however, the vast majority fall into two categories- "finding similar things" and "multi-object, layered constraints".  Finding similar things is all about finding things that are different in words but similar in meaning such as finding products that have similar safety and regulatory profiles across geographies or customers that have similar order and shipping patterns.  Our on-going work with SHACL suggests that the standard has nice support for these use cases and we hope this continues.

"Multi-object, layered constraints" goes far beyond the basics of type, range, etc... Here we are able to express constraints that span multiple objects using the SPARQL/SPIN component of the SHACL standard.  For example, this flexibility has allowed us to define the constraints necessary to see if a given product can be shipped using a specific type of pallet (constraints between Product and Pallet).  This is then extended to the "Truck" class so we can determine if the Pallet with the Product can fit properly in the specified Truck, which leads to another layer of constraints by saying "can this Shipment (Product + Pallet + Truck + Customer + Shipping Lane) be shipped to this Customer from this Location on this Date?  This is only one of many such multi-object, layered use cases.

As you can see by the example above, having the flexibility to define business rules and constraints far beyond the object-centric templates is key to making SHACL a useful and productive technology for my organization.  While SHACL is a tremendous leap beyond OWL restrictions, removing the support for flexible SPARQL-based extensions will severely limit the utility and adoption of the standard.  No standard can address all use cases, especially in version 1.0 but it can and should provide a mechanism for practitioners of the standard to explore the infinite number of real-world use cases, which ultimately become the basis for version 1.1, etc...

It is my sincere hope that through my brief examples above, the hard working members of this group can see the utility and essential nature of supporting SPARQL/SPIN within the SHACL standard.

Regards,

Tim Smith

The Procter & Gamble Company
1 P&G Plaza
Cincinnati, OH 45202
1-513-983-1100