Pragmatic Proposal for the Structure of the SHACL Spec

At present we are witnessing a burst of creative activity. It is great
to see such energy in a WG. However, the result is that we have too
many specs and I doubt that most members can give all these documents
adequate review. We need to focus our resources on fewer specs.

There has also been extended discussion on the role of SPARQL, on
profiles of SHACL, and on who the target audience is. I'd like to
propose a pragmatic structure that will enable us to package the
material in a way that will address our audiences, enable us to divide
the work better, and create a sequence of deliverables.

I propose three levels of content. I'll refer to these as Parts 1, 2,
and 3 in order to defer word-smithing of the titles.

1. SHACL Part 1. The audience is people who want to use a simple,
high-level language that can express common constraints. This document
should use precise, natural language to describe the semantics of
those common constraints that can be expressed using the high-level
vocabulary of SHACL. It should also include simple examples to
illustrate concepts. It should be readable by people who do not know
SPARQL. It should not refer to SPARQL. It should not define formal
semantics. It should be possible for this part of SHACL to be readily
implemented in SPARQL or Javascript. We therefore need to limit the
expressive power of this part of SHACL.

2. SHACL Part 2. The audience is people who want to write custom
constraints using an executable language. This part defines the
template/macro mechanism. It also provides normative SPARQL
implementations of the high-level SHACL language introduced in Part 1.
This part should not contain other formal specifications. The SPARQL
implementations can be regarded as executable formal specifications.

3. SHACL Part 3. The audience is people who want to implement SHACL.
This part should contain a formal specification. We can defer the
choice of formalism. If we have multiple candidates and willing
authors, let's do a bake-off.

-- Arthur

Received on Wednesday, 18 March 2015 22:35:26 UTC