The future of SHACL

To whom it may concern,

Over a year ago SHACL came to my attention as a possible way to support interoperability between systems employing different ontologies. I thought it interesting but it didn't become critical until I started developing constraints that couldn't provide the kind of integration with our models that I required; SHACL did. In the past 8 months we have embraced the use of SHACL, and in particular SHACL SPARQL constraints, to develop inter-model constraints that the specification doesn't provide templates for. Without SPARQL support within SHACL, I am not convinced that SHACL would have much value for our work. Certainly the base set of constraints that handle object-specific support (type, value, cardinality, and range) are helpful, but it is the inter-object dependencies that really show the value of SHACL constraints to customers, and these require custom SPARQL queries attached to the constraint parameters (and of course complex SPARQL queries are always made more tractable with the inclusion of SPIN functions).

At this point I have been spreading the word of SHACL across the Siemens ontological community and it has filtered into work we are doing with the California Energy Commission on Demand Response. As our use of it continues, others are hearing about it from the pool of collaborators we are working with, and they will be wanting to develop their own custom inter-object constraints that will require both SPARQL and SPIN support.

I do not think of myself as an early adopter of SHACL, as it took me many months after the first drafts to start working with it, but I have found it exceedingly helpful, as it currently stands and, as I mentioned, it has worked its way into work we are doing for the government outside of our internal (as well as within our internal) semantic technology projects.

I have yet to use SHACL in the manner I originally saw it being useful for, to defining shapes to promote interoperability, but I see no end to its usefulness in supporting constraint validations on complex ontologies.

Every language has its initial growing pains. In the past 6 months the SHACL model has undergone some changes that caused us to rework how we use it a bit, but that is to be expected, and the changes seem to have been for the better, more or less. The semantics seem to be well defined, certainly well enough that using it is possible (which is much more than can be said of similar technologies).

In the interests of moving SHACL toward its widespread acceptance and use I encourage the working group to move forward with the definition as it currently stands without removing support for SPARQL/SPIN from the specification. I would have to find another way (if such a way even exists) were the language less flexible that SPARQL/SPIN allow.

Best regards,

Jack Hodges, Ph.D.

Siemens Corporation
CT RDA NEC WOS-US
2087 Addison St., 2nd Floor
Berkeley, CA 94704-1074, USA
Mobil: +1 510 289-2982
mailto:jack.hodges@siemens.com

Your organization is currently not activated for using SCMS (e-mail signatures). Please contact the IT Support or help.scf@siemens.com


This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation