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

Again, your proposed wording goes far beyond simply mentioning a possible 
solution.  Your proposed wording says that a particular approach is to be 
followed unless it is shown to be inadequate.

I do not support this proposed wording.  I do support wording like what is 
currently at the end of Section 3.

peter


On 08/02/2014 01:21 PM, Irene Polikoff wrote:
> Because it identifies a possible solution and says that if it proves to be inadequate, the working group will choose another approach. Thus, the prime candidate is identified, but the group is not mandated to use it.
>
> -----Original Message-----
> From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
> Sent: Saturday, August 02, 2014 4:18 PM
> To: Irene Polikoff; 'Arthur Ryman'; public-rdf-shapes@w3.org
> Subject: Re: Proposed change to the charter, section 4. Deliverables, Recommendation Track
>
> Why would you think that this would be acceptable to me?  This goes well beyond pointing at possible solutions or mentioning possible starting points.
>
> peter
>
> On 08/02/2014 01:13 PM, Irene Polikoff wrote:
>> Then, Arthur's strawman with the modification below should be acceptable:
>>
>> 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 or, if SPARQL proves to be unsuitable for the use cases determined by the group, in an alternative language.
>> 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 or, if SPARQL proves to be unsuitable for the use cases determined by the group, in an alternative language.
>> 2. A specification of how constraint validation interacts with inference.
>> 3. A specification for graph normalization.
>> [1] http://www.w3.org/2014/data-shapes/charter
>>
>> Irene
>>
>> -----Original Message-----
>> From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
>> Sent: Saturday, August 02, 2014 1:17 AM
>> To: Irene Polikoff; 'Arthur Ryman'; public-rdf-shapes@w3.org
>> Subject: Re: Proposed change to the charter, section 4. Deliverables,
>> Recommendation Track
>>
>> I don't see much wrong in pointing at potential solutions, and even less mentioning possible starting points, but that's not what the proposed change to the charter is.  Instead the proposed change mandates SPARQL as the semantics of constraints.  I think that this is in advance of any worked-out proposal for actually using SPARQL for this purpose.
>>
>> If it turns out that SPARQL can be used to specify the semantics of constraints, then it may be reasonable to use SPARQL for this purpose.
>> However, mandating SPARQL's use even before its suitability has been demonstrated doesn't seem to me to be a good idea.
>>
>> peter
>>
>>
>> On 08/01/2014 06:54 PM, Irene Polikoff wrote:
>>> Not necessarily. As Jeremy Carroll said in one of the previous e-mails "W3C experience indicates that a WG with a blank sheet at the beginning often delivers the wrong stuff, late - and the broad ship that sails ends up as a narrow clique on arrival".
>>>
>>> It is better to set a charter that identifies the prime candidate. As the work proceeds, the group may decide that the candidate doesn’t meet key requirements, but having initial stake in the ground is important to the effectiveness of the group, its ability to deliver on time and quality of its deliverables.
>>>
>>> Irene
>>>
>>> -----Original Message-----
>>> From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
>>> Sent: Friday, August 01, 2014 5:53 PM
>>> To: Arthur Ryman; public-rdf-shapes@w3.org
>>> Subject: Re: Proposed change to the charter, section 4. Deliverables,
>>> Recommendation Track
>>>
>>> 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 Saturday, 2 August 2014 21:09:46 UTC