Re: eliminating property constraints

I'm not sure what scope you want this conversation to have.  In November I
have initiated six threads in the public comments mailing list.  I
previously initiated quite a few more.

I'll limit this message to the November threads.  I do note that most of my
previous messages are about what substantive problems in the SHACL document.
I don't view any of these messages as simply editorial although some of them
may have been addressed by other changes to SHACL.


Thread: some comments on SHACL editors' draft of 8 November (Friday, 11
November)

This thread is about the continuing problems in the SHACL document with
inadequate description of the basic terminology and operation of SHACL.  In
the message I not only stated the basic problem but also put forward several
examples of it.  There have been changes made to the SHACL document to
address some of the examples, and one of them has been associated with
ISSUE-192.  However, I don't see that anything has been done to address the
continuing serious problem that I have brought up again.  This problem was
the subject of ISSUE-142, which was closed by the working group.  I
expressed my disappointment that an important issue was closed without being
satisfactorily addressed.  It is even not just that the document is unclear
about terminology and processing but that the document says things that are
counter to my understanding of what SHACL is supposed to be or be doing.
So, no, there is not a complete list of open working group issues related to
my substantive comments.

Thread: on removing pre-binding from the core of SHACL (Saturday, 12
November)

There is no issue linked to this email thread in
https://www.w3.org/2014/data-shapes/wiki/Comments/September2016/
However, ISSUE-202 was created for it.   I do note that it is not in the
charter of the SPARQL Maintenance (EXISTS) Community Group to provide a
definition of pre-binding.

Thread: two interesting test cases for SHACL (Monday, 14 November)

This email message presented two separate test cases for SHACL to illustrate
two current problems in the description of SHACL.

The first has to do with what happens when a node in a shapes graph is both
a shape and a property constraint.  I had brought up this point before, but
decided to present a test case for it.  I don't see a working group issue
for the problem.

The second test case has to do with the fundamental notion of what makes a
shape in SHACL.  At the time then I wrote this message a shape in SHACL was
a node in a shapes graph with SHACL type sh:Shape or expected type sh:Shape.
Subsequently this has been changed so that more nodes are shapes, including
those nodes that are subjects of target properties.  There is ISSUE-209 on a
related topic, but that topic has aleady been the subject of a long email
thread starting at
https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oct/0029.html

The changes to the SHACL document made in response to the this second test
case have made a significant change to SHACL.  This significant change was
made without any issue being raised and is inadequately described in the
change section of the document.

There should be two new issues on these topics as well as a discussion in
the working group about how the process for making significant changes to
SHACL has broken down.

Thread: eliminating property constraints (Saturday, 19 November)

ISSUE-211 has been created for this thread.

Thread: on ISSUE-196 (Tuesday, 22 November)

This is a new email thread having to do with problems in the closing of
ISSUE-196.

Thread: undocumented changes to SHACL (Tuesday, 22 November)

This is a new email thread having to do with inadequate description of
substantive changes to SHACL.  It may also be that these substantive changes
have not had any working group discussion.

Peter F. Patel-Schneider
Nuance Communications


On 11/20/2016 01:29 PM, Karen Coyle wrote:
> Peter, I have edited the page of received comments [1] and have created issues
> for as many of the items that I could. I would love to say that it is all
> complete and correct, but am not so confident. If you have time to review the
> list and the newly raised items on tracker,[2]  I would appreciate it.
> 
> kc
> [1] https://www.w3.org/2014/data-shapes/wiki/Comments/September2016/
> [2] https://www.w3.org/2014/data-shapes/track/issues/raised
> 
> p.s. for Arnaud - the missing issue #206 is because I had created a duplicate,
> which I then deleted
> 
> On 11/19/16 6:08 AM, Peter F. Patel-Schneider wrote:
>> SHACL currently has shapes, constraints, constraint components, parameters,
>> and the special property sh:property.  This leads to a complex formalism
>> that the SHACL document continues to struggle to adequately describe.
>>
>> This complexity is not necessary.  Both shapes and constraints can be merged
>> into a single notion of shapes.  The special property sh:property can be
>> turned into the single parameter of a new constraint component.
>>
>> Under this new setup for SHACL shapes are uniformly validated in a context
>> where there are focus nodes and value nodes.  Shape validation from targets
>> is done in a context for each target node with the focus node being the
>> target node and the set of value nodes being the singleton containing only
>> the target node.  Constraint components in a shape are each validated in the
>> context of the shape.
>>
>> The new constraint component, with parameter sh:property, works by
>> validating its shape argument in a new context for each value node of the
>> current context.  This new context has as its focus node the original value
>> node and has as its value nodes the set of value nodes for the sh:property
>> or sh:path in the shape, just as before.
>>
>> This change is largely just a change in the description of SHACL.  There
>> are, however, a few minor changes to SHACL itself.  First, there would be a
>> new constraint component with sh:property as its sole parameter.  Second,
>> the argument for this parameter would be a shape, albeit one that has to
>> have a value for either sh:predicate or sh:path.  It would be possible make
>> the expected type for sh:property values be a subclass of sh:shape, but
>> users of SHACL would not need to know that this was the case and the only
>> reason to do so would be to support the validation of SHACL shapes graphs in
>> SHACL.
>>
>> This change to SHACL would help greatly in decreasing the complexity of the
>> langauge and permit a better and more streamlined description of SHACL.
>>
>>
>> Peter F. Patel-Schneider
>> Nuance Communications
>>
>>
>

Received on Tuesday, 22 November 2016 16:43:59 UTC