Re: summarizing proposed changes to charter

Hi Holger,

It may seem unfair indeed that your proposal wasn't directly addressed in 
Eric's email. However, I hope you will recognize that there is a clear 
overlap between the different proposals and there is only so much we can 
do to accommodate the different suggestions.

Under pressure from about everybody the charter has been significantly 
watered down and made completely technology neutral. As a result the WG 
has now a lot of room to decide exactly what spec to produce and based on 
what technology.

As noted before this is both a gift and a curse because it means we will 
have a lot of work to do to define a clear direction but, at this point, 
as others have pointed out, I think the most productive thing to do is to 
launch the WG.

I do think your interpretation of what charters imply is a bit on the 
conservative side. My experience is that when WGs agree they have a lot of 
leeway with regard to their charter. So, I wouldn't fret too much about 
the details of the charter.

Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - IBM 
Software Group




From:   Holger Knublauch <holger@topquadrant.com>
To:     public-rdf-shapes@w3.org
Date:   08/12/2014 06:33 PM
Subject:        Re: summarizing proposed changes to charter



Hi Eric,

this is a good initiative. I do wonder though why my own proposal which 
is best summarized at

http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Aug/0088.html

is not being discussed? If you are suggesting to follow the splitting of 
the deliverable suggested by Peter, then why not also discuss the 
splitting that I proposed?

Alternatively, let's assume that the WG will redefine the deliverables 
anyway once it has agreed on which base technology to start with. In 
that case, we only need a single vague deliverable outline for now. But 
even then the current prose

"An RDF vocabulary, such as Resource Shapes 2.0, for expressing these
shapes in RDF triples, so they can be stored, queried, analyzed, and
manipulated with normal RDF tools."

does not work because it only highlights Resource Shapes 2.0 and also 
does not say anything about the extension mechanism and fallback to 
something like SPARQL that was identified in section 3. These are not 
"shapes" but meta-shapes and my suggestion was to clarify this into two 
deliverables. Only defining hard-coded Shapes is not an acceptable 
outcome of this WG. It would work for me if the above sentence is 
extended to explicitly mention this extension mechanism, so my 
compromise proposal is:

     An RDF vocabulary for expressing structural constraints (aka 
Shapes) together with
     a definition of their formal semantics that explains how shapes are 
evaluated against
     RDF graphs. Also an extension mechanism that enables the definition 
of new Shapes
     and to fall back to a richer language to express more complex 
constraints.

The part "for expressing these shapes in RDF triples etc" from the 
original proposal can be deleted because it is a consequence of being 
based on RDF.

I also want to note that the deliverable "Relationship to SPARQL" should 
have a similar sentence like the OWL deliverable underneath it, to make 
it unnecessary if SPARQL is already used for the first deliverable.

On 8/13/2014 10:55, Eric Prud'hommeaux wrote:
> separate semantics:
>
>    "Peter F. Patel-Schneider" <pfpschneider@gmail.com> - Message-ID: 
<53E2AFBD.9050102@gmail.com>
>      A syntax and semantics for shapes specifying how to construct shape 
expressions and how shape expressions are evaluated against RDF graphs.
>    "Dam, Jesse van" <jesse.vandam@wur.nl> - Message-ID: 
<63CF398D7F09744BA51193F17F5252AB1FD60B24@SCOMP0936.wurnet.nl>
>      defining the the (direct) semantics meaning of shapes and defining 
the associated validation process.
>
>    opposition: Holger Knublauch
>
>    proposed resolution: include, noting that if SPARQL is judged to be 
useful for the semantics, there's nothing preventing us from using it.

I am not happy with that, and I believe my proposal above covers it more 
pragmatically. I am very much against making this more complicating than 
it needs to be by introducing extra layers of "formal" specifications. 
Just use SPARQL and it becomes both formally specified and immediately 
executable.

The other topics below are fine for me.

Holger


>
>
> make graph normalization optional or use-case specific:
>
>    "Peter F. Patel-Schneider" <pfpschneider@gmail.com> - Message-ID: 
<53E2AFBD.9050102@gmail.com>
>      3 OPTIONAL A specification of how shape verification interacts with 
inference.
>    Jeremy J Carroll <jjc@syapse.com> - Message-Id: 
<D954B744-05CD-4E5C-8FC2-C08A9A99BA9F@syapse.com>
>      the WG will consider whether it is necessary, practical or 
desireable to normalize a graph...
>      A graph normalization method, suitable for  the use cases 
determined by the group....
>    David Booth <david@dbooth.org> - Message-ID: 
<53E28D07.9000804@dbooth.org>
>      OPTIONAL - A Recommendation for normalization/canonicalization of 
RDF graphs and RDF datasets that are serialized in N-Triples and N-Quads. 
opposition - don't do it at all:
>    "Peter F. Patel-Schneider" <pfpschneider@gmail.com> - Message-ID: 
<53E3A4CB.4040200@gmail.com>
>      the WG should not be working on this.
>
>    proposed resolution: withdrawn, to go to new light-weight, focused 
WG, removing this text:
>    [[
>    The WG MAY produce a Recommendation for graph normalization.
>    ]]
>
>
> mandatory human-facing language:
>
>    "Dam, Jesse van" <jesse.vandam@wur.nl> - Message-ID: 
<63CF398D7F09744BA51193F17F5252AB1FD60B24@SCOMP0936.wurnet.nl>
>      ShExC mandatory, but potentially as a Note.
>    David Booth <david@dbooth.org> - Message-ID: 
<53E28D07.9000804@dbooth.org>
>      In Section 4 (Deliverables), change "OPTIONAL - Compact, 
human-readable syntax" to "Compact, human-readable syntax", i.e., make it 
required.
>    Jeremy J Carroll <jjc@syapse.com> - Message-Id: 
<54AA894F-F4B4-4877-8806-EB85FB5A42E5@syapse.com>
>
>    opposition - make it OPTIONAL
>    "Peter F. Patel-Schneider" <pfpschneider@gmail.com> - Message-ID: 
<53E2AFBD.9050102@gmail.com>
>      OPTIONAL A compact, human-readable syntax for expressing shapes.
>
>    proposed resolution: keep as OPTIONAL, not mentioning ShExC, but 
clarifying that it's different from the RDF syntax.
>
>
> report formats:
>    Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
>      provide flexible validation execution plans that range from:
>        Success / fail
>        Success / fail per constraint
>        Fails with error counts
>        Individual resources that fail per constraint
>        And enriched failed resources with annotations
>
>    proposed resolution: no change, noting that no one seconded this 
proposal.
>
>
> test suite/validator:
>
>    Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
>      Validation results are very important for the progress of this WG 
and should be a standalone deliverable.
>    David Booth <david@dbooth.org> - Message-ID: 
<53E28D07.9000804@dbooth.org>
>      Test Suite, to help ensure interoperability and correct 
implementation. The group will chose the location of this deliverable, 
such as a git repository.
>
>    proposed resolution: leave from charter as WGs usually choose to do 
this anyways and it has no impact on IP commitments.
>