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

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

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 01 Aug 2014 14:53:15 -0700
Message-ID: <53DC0C4B.7070502@gmail.com>
To: Arthur Ryman <ryman@ca.ibm.com>, public-rdf-shapes@w3.org
All these arguments may be fine, but isn't that up to the working group to decide?

peter


On 08/01/2014 02:42 PM, Arthur Ryman wrote:
> Peter,
>
> Thx for the response. I'm glad that we agree on making the compact,
> human-friendly syntax optional.
>
> Here is my rationale for advocating for the use of SPARQL.
>
> 1. We need to be precise about the meaning of constraints. Therefore, we
> need to select some formalism for expressing the semantics.
>
> 2. The candidates for expressing semantics include:
> 2.1 Natural language
> 2.2 OWL ICV
> 2.3 SPARQL
> 2.4 Z
> 2.5 some other existing formal language
> 2.6 a new specification language that the wg invents
>
> Pros and Cons
>
> 2.1 Natural language is imprecise and non-executable
> 2.2 OWL ICV is well-defined and executable, but not a W3C standard and is
> not expressive enough as a general constraint language
> 2.3 SPARQL is a W3C standard, is very expressive, and is executable
> 2.4 Z is very expressive but not well known and is non-executable
> 2.5 There are many other formal specification languages. Does anyone want
> to advocate for one?
> 2.6 A new formalism - not the core focus of the workgroup.
>
> 3. Some one will need to build a reference implementation. A SPARQL
> implementation will be easy to build if the semantics of the constraints
> are in SPARQL.
>
> 4. We want the specification to be implemented and adopted. SPARQL is a
> known quantity and many implementations exist.
>
>
> 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)
>
>
>
>
>
> From:   "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> To:     Arthur Ryman/Toronto/IBM@IBMCA, public-rdf-shapes@w3.org,
> Date:   08/01/2014 05:22 PM
> Subject:        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:53:45 UTC

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