Re: summarizing proposed changes to charter

Hi Holger,

The fact that extensibility is explicitly listed as a design goal in the 
scope section [scope] should be enough to assure you that this is 
something the WG is expected to deliver on. If the WG didn't, it would 
fail to deliver on the goals set by its charter.

[scope] http://www.w3.org/2014/data-shapes/charter#scope

Furthermore, the workshop clearly showed strong support for some 
extensibility mechanism so I don't see why you'd think there is a risk the 
WG will then decide to ignore that.

I've asked Eric to see if he could add a mention of extensibility to the 
deliverables to address your concern but quite frankly you could say the 
same should be done about every other goals listed in the scope section. 
Yet, it's simply not practical. As I said before, there is only so much we 
can say in the list of deliverables. That list doesn't stand on its own, 
it is to be taken along with everything else in the charter.

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


Holger Knublauch <holger@topquadrant.com> wrote on 08/12/2014 08:26:12 PM:

> From: Holger Knublauch <holger@topquadrant.com>
> To: public-rdf-shapes@w3.org
> Date: 08/12/2014 08:28 PM
> Subject: Re: summarizing proposed changes to charter
> 
> Hi Arnaud,
> 
> sorry but there is one fundamental issue here. Chapter 3 clearly 
> states that Extensibility is a design goal, but none of the 
> deliverables mentions this. On the recommendation track there is 
> only a vocabulary for "these shapes" and those Shapes are basically 
> the other items from the Scope section, aka the "hard-coded" 
> Resource Shapes such as ranges and cardinalities. Then there is a 
> Not Recommendation Track item for "Relationship to SPARQL" which is 
> not talking about extensibility either.
> 
> So where is extensibility covered? If it is not covered, how sure 
> can we be that the WG will implement the Scope? What happens if 
> people who happen to sit in the WG decide that extensibility is just
> a nice-to-have (even though it has been clearly identified as a 
> requirement in the discussions so far)?
> 
> Thanks,
> Holger
> 
> 
> 
> 
> On 8/13/2014 13:10, Arnaud Le Hors wrote:
> 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.
> >
> 
>