W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > August 2014

Re: summarizing proposed changes to charter

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 19 Aug 2014 10:15:58 +0200
Message-ID: <53F307BE.8050804@few.vu.nl>
To: <public-rdf-shapes@w3.org>
Hi everyone,

I'd like to congratulate the group for coming with this new version. No little feat, after such discussion...

While I was reading it, I noted two points in the into. Pure nitpicking, but since I noted them I thought I'd send them:
- "value constraints of a nodes in an RDF graph" -> value constraints of a set of nodes in an RDF graph
- perhaps you could make more explicit that the first occurrences of 'interface' are about data, not 'user interface' (as the latter is also mentioned in the charter).

Best regards,

Antoine

On 8/15/14 8:32 PM, Arnaud Le Hors wrote:
> Thanks Eric.
>
> For those who might be looking for it, here is the link to the proposed charter:
> http://www.w3.org/2014/data-shapes/charter
>
> Just make sure your AC rep supports it when it comes up for review!
>
> Thanks all for a difficult but fruitful discussion. I look forward to the WG getting started and meeting you at TPAC.
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - IBM Software Group
>
>
> "Eric Prud'hommeaux" <eric@w3.org> wrote on 08/15/2014 11:08:36 AM:
>
>  > From: "Eric Prud'hommeaux" <eric@w3.org>
>  > To: public-rdf-shapes@w3.org
>  > Cc: Arnaud Le Hors/Cupertino/IBM@IBMUS
>  > Date: 08/15/2014 11:08 AM
>  > Subject: Re: summarizing proposed changes to charter
>  >
>  > * Eric Prud'hommeaux <eric@w3.org> [2014-08-12 20:55-0400]
>  > > Hi all, we can have a face-to-face at the W3C Technical Plenary in
>  > > November if we can quickly endorse a good-enough charter.  As it
>  > > stands now, it isn't clear that the group will be able to reach
>  > > consensus within the Working Group, let alone get through the member
>  > > review without objection.
>  >
>  > Many thanks to everyone! I think this will get us to AC review in time
>  > for a F2F at the Technical Plenary.
>  >
>  >
>  > > Please review the proposals that I've culled from the list.  I
>  > > encournage compromise on all our parts and we'll have to suppress the
>  > > desire to wordsmith. (Given the 3-month evaluation period,
>  > > wordsmithing won't change much anyways.)
>  >
>  > For posterity's sake, below is an accounting of how these were
>  > implemented in the charter:
>  >
>  >
>  > > 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.
>  >
>  > +        <li><p><b>Semantics</b>, possibly defined as SPARQL
>  > operations, specifying how shapes are evaluated against RDF graphs.</p></li>
>  >
>  >
>  > > 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.
>  > >   ]]
>  >
>  > -      <p>The WG <strong>MAY</strong> produce a Recommendation for
>  > <strong>graph normalization</strong>.</p>
>  >
>  >
>  > > 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.
>  >
>  > ~        <li><p><strong>OPTIONAL</strong> - <b>Compact, human-
>  > readable, non-RDF syntax</b> for expressing constraints on RDF graph
>  > patterns (aka shapes), suitable for the use cases determined by the
>  > group.</p></li>
>  > -   This syntax might be a variation of an existing standard, such
>  > as templates for SPARQL, or something new, such as ShExC.
>  >
>  >
>  > > 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 thisproposal.
>  >
>  > no change
>  >
>  >
>  > > 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.
>  >
>  > no change
>  >
>  >
>  > I also added ", with some extensibility mechanism for complex use
>  > cases." to the first deliverable. I presume this is non-controversial.
>  >
>  >
>  > > --
>  > > -ericP
>  > >
>  > > office: +1.617.599.3509
>  > > mobile: +33.6.80.80.35.59
>  > >
>  > > (eric@w3.org)
>  > > Feel free to forward this message to any list for any purpose other than
>  > > email address distribution.
>  > >
>  > > There are subtle nuances encoded in font variation and clever layout
>  > > which can only be seen by printing this message on high-clay paper.
>  >
>  > --
>  > -ericP
>  >
>  > office: +1.617.599.3509
>  > mobile: +33.6.80.80.35.59
>  >
>  > (eric@w3.org)
>  > Feel free to forward this message to any list for any purpose other than
>  > email address distribution.
>  >
>  > There are subtle nuances encoded in font variation and clever layout
>  > which can only be seen by printing this message on high-clay paper.
>  >
Received on Tuesday, 19 August 2014 08:16:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:40 UTC