Re: shapes-ISSUE-122 (no-shapes-file): Should we postpone publishing a SHACL shapes file (indefinitely)? [SHACL Spec]

I understand and appreciate your concerns. I have had similar experiences 
developing the shapes (based on ResourceShapes 3.0) for OSLC core and the 
change management domain. At OASIS, the OSLC TCs are using a shapes 
checker tool along with ReSpec to get greater value out of the shapes and 
automate as much of the validation as possible.

Regarding the increased work, perhaps it could be balanced against the 
risk that something in the spec is incomplete or inconsistent. Developing 
the shapes files along with the vocabularies might help detect these 
otherwise difficult things to detect and assess before implementation.

But I think you are suggesting that having and using the shapes is 
different than incorporating them in the formal, normative specification. 
And that could be a good compromise.

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data

From:   Holger Knublauch <>
Date:   02/15/2016 06:56 PM
Subject:        Re: shapes-ISSUE-122 (no-shapes-file): Should we postpone 
publishing  a SHACL shapes file (indefinitely)? [SHACL Spec]

I anticipate several discussions about the scope of such a shapes file. 
Would it include SPARQL queries (if yes then what about things like the 
$shapesGraph complication). Would it include type checks such as that 
predicates must be IRIs. Would it include warnings or info if sh:class 
is not a class in the shapes graph.

But more importantly, if we publish such a file, we are also expected to 
produce a correct files, and this includes test cases, documentation 
etc. All this feels like churn that we shouldn't commit to given that we 
have other tickets open. Time permitting we could tackle this when 
everything else is done.

And yes I agree why having the shapes file has benefits for testing the 
expressivity, and a lot of feedback that I have given to the group so 
far has actually been based on the shacl shapes file that I am editing 
myself for the open source API. But anyone can do this and similar 
exercises in their spare time. It doesn't require the full WG's attention.


On 16/02/2016 3:04, Arthur Ryman wrote:
> Holger,
> Defining shapes for SHACL has a lot of benefit. It's a good test for
> the expressivity of SHACL. Why do you predict long debates?
> -- Arthur
> On Wed, Feb 10, 2016 at 6:56 PM, RDF Data Shapes Working Group Issue
> Tracker <> wrote:
>> shapes-ISSUE-122 (no-shapes-file): Should we postpone publishing a 
SHACL shapes file (indefinitely)? [SHACL Spec]
>> Raised by: Holger Knublauch
>> On product: SHACL Spec
>> In a previous resolution
>> we decided to publish a (RDFS) vocabulary file plus a separate SHACL 
file with shape definitions. I no longer support the creation of the 
Shapes file, because it may cause long debates about details and thus take 
away resources that are better spent elsewhere. A shapes file is not 
needed by all SHACL engines, and could instead be published as open source 
projects outside of the WG.
>> If the WG has spare time at the end, we could revisit this, but for now 
I think we should get the essential stuff done and postpone this 
deliverable indefinitely.

Received on Tuesday, 16 February 2016 14:47:10 UTC