Re: The future of SHACL

Hi John,
Thank you for your feedback. For what it's worth I don't think there is 
any doubts that something like SHACL is needed. This was agreed upon at 
the workshop we held 3 years ago and this has obviously not changed.

As Karen pointed out we're interested in implementation feedback. Could 
you please tell us more. Are you implementing SHACL? If not, how do you 
use it? If yes, how much do you support: Core, Full (Core+SPARQL)?

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web & Blockchain 
Technologies - IBM Cloud




From:   "HODGES Jr, John" <jack.hodges@siemens.com>
To:     "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Date:   12/12/2016 05:49 PM
Subject:        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