Re: Proposed change to the charter, section 4. Deliverables, Recommendation Track

I do agree that the emphasis in the charter on creating a human-readable
syntax is misplaced and that this deliverable should be made optional.  The
proposal here, however, does very much more than fixing this problem, and I
view most of the other changes in the proposal as undesirable.

Why should the group be required to specify semantics in terms of SPARQL?
There hasn't even been anything to show that SPARQL is adequate for this
purpose.  Why should the group be required to specify two ways of expressing
constraints, and one of them be SPARQL itself?  There hasn't been anything
to show that this division is needed.  Why should a human-readable syntax
for constraints be new?  There hasn't been anything to show that existing
syntaxes are unsuitable for this purpose.  I don't think that it is
appropriate to tie the hands of the working group in any of these ways.

I do agree that the group should be required to define the meaning of
constraints.  This was a peculiar lack in the deliverables.

So my proposal would be to change the recommendation track deliverables to 
something like:

1. A syntax and semantics for shapes specifying how to construct shape
expressions and how shape expressions are evaluated against RDF graphs.

2. An RDF vocabulary for expressing these shapes in RDF triples, so they can
be stored, queried, analyzed, and manipulated with normal RDF tools.

3. OPTIONAL A specification of how shape verification interacts with
inference.

4. OPTIONAL A compact, human-readable syntax for expressing shapes.

I would prefer the third deliverable to be required, but I'm not going to
complain if it is optional.

Although there are three syntaxes mentioned in these deliverables, in keeping 
with the usual RDF situation there is nothing saying that all of these three 
need to be different or even that they are not all the same.  (Well, nothing 
beyond the implausibility of using RDF triples as the basis of a compact, 
human-readable syntax.)

peter


On 08/01/2014 12:44 PM, Arthur Ryman wrote:
> The output of the wg is defined by its deliverables. Here is the current
> text [1]
>
> Recommendation Track:
> 1.      Compact, human readable syntax for expressing constraints on RDF
> graph patterns (aka shapes), suitable for the use cases determined by the
> group. This syntax might be a variation of an existing standard, such as
> templates for SPARQL, or something new, such as ShExC.
> 2.      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.
> The WG MAY produce a Recommendation for graph normalization.
>
> This text is not acceptable to IBM because of the primary emphasis it
> places on defining a possibly new compact, human readable syntax. I
> believe this concern has been expressed repeatedly by many people on the
> mailing list. Many people have indicated a strong preference for building
> on existing standards. However, we have not seen any corresponding
> modification of the charter. I'd therefore like to propose a strawman
> change to this section of the charter and invite comment. Here is the
> proposed new text:
> The WG MUST produce:
> 1. A high-level RDF vocabulary that expresses commonly occurring
> constraints.
> 2. The semantics of the high-level constraints expressed in terms of
> SPARQL.
> 3. An RDF extension mechanism for expressing additional constraints,
> expressed in SPARQL.
> The WG MAY produce:
> 1. A new compact, human readable syntax for expressing constraints with a
> corresponding semantics expressed in SPARQL.
> 2. A specification for graph normalization.
> [1] http://www.w3.org/2014/data-shapes/charter
>
> Regards,
> ___________________________________________________________________________
> Arthur Ryman, PhD
>
> Chief Data Officer, Rational
> Chief Architect, Portfolio & Strategy Management
> Distinguished Engineer | Master Inventor | Academy of Technology
>
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
>
>
>

Received on Friday, 1 August 2014 21:21:59 UTC