Re: Pragmatic Proposal for the Structure of the SHACL Spec

On 3/19/15 1:46 PM, Holger Knublauch wrote:

> The argument about implementation support is not strong enough. As
> stated TopQuadrant will provide an open source implementation of the
> full spec that is tracking the progress as soon as we decide to go to
> FPWD state. In the IRC log, Dimitris has also announced that he will
> work on another implementation. Finally, while I cannot speak for them,
> we have at least one SPARQL database vendor in our group (I am not sure
> what happened to Arthur Keen, I don't see him on the list anymore). This
> sounds like at least 3 implementations from within the group already,
> and we still have 1.5 years to go.
>
> Holger

I don't think it matters greatly how many documents we end up with, but 
it might be convenient to work independently on sections, which could 
later be published as a single document. It would certainly be easier to 
focus a review on smaller segments than on a whole document. I realize 
that requires some coordination, but the same coordination is also 
needed in a large document with more than one person working on it.

kc

>
>
>> --
>> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies
>> - IBM Software Group
>>
>>
>> Arthur Ryman <arthur.ryman@gmail.com> wrote on 03/19/2015 09:15:39 AM:
>>
>> > From: Arthur Ryman <arthur.ryman@gmail.com>
>> > To: Richard Cyganiak <richard@cyganiak.de>
>> > Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
>> > Date: 03/19/2015 09:16 AM
>> > Subject: Re: Pragmatic Proposal for the Structure of the SHACL Spec
>> >
>> > Richard,
>> >
>> > I am fine with these parts being in one document if that in fact
>> > simplifies maintenance. That decision should be delegated to the
>> > editors. However, I think we could stabilize Part 1 soon, publish it,
>> > show a heartbeat, and get some feedback.
>> >
>> > I hope we don't have warring editors. Putting a stake in the ground by
>> > publishing Part 1 might improve our shared understanding of SHACL.
>> >
>> > -- Arthur
>> >
>> > On Thu, Mar 19, 2015 at 8:02 AM, Richard Cyganiak
>> <richard@cyganiak.de> wrote:
>> > > Arthur,
>> > >
>> > > I agree with your analysis regarding different audiences. I am
>> > sympathetic to the notion that there should be three parts.
>> > >
>> > > However, I disagree with your conclusion that there should be
>> > three documents.
>> > >
>> > > Keeping multiple documents in sync is a significant burden on a
>> > working group. It makes sense if the documents describe loosely
>> > coupled components of an overall framework, but that is not the case
>> > here; your proposed split would leave material related to a single
>> > language feature often distributed over three different documents
>> > (and perhaps maintained by three warring editors).
>> > >
>> > > I don’t see why a single specification cannot adequately address
>> > the needs of different target audiences.
>> > >
>> > > The SPARQL 1.1 spec is an example of a specification that delivers
>> > a primer, a thorough language reference, precise semantics, and
>> > guidance for implementers in a single document.
>> > >
>> > > Best,
>> > > Richard
>> > >
>> > >
>> > >
>> > >> On 18 Mar 2015, at 22:29, Arthur Ryman <arthur.ryman@gmail.com>
>> wrote:
>> > >>
>> > >> 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
>> > >>
>> > >
>> >
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 19 March 2015 21:31:09 UTC