Re: RDF Data Shapes WG agenda for 8 October 2015

On 10/07/2015 10:31 AM, Arnaud Le Hors wrote:
> With, as usual, an overly optimistic list of issues to tackle:
> https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.10.08
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM
> Software Group

Here are my comments and voting instructions.


Opening issues

There are several issues that do not identify the problem being addressed.  I
think that such issues should be revised to clearly state what issue they are
addressing.  Issue statements should also be clear and without editorializing.

ISSUE-95

See separate email to follow.

ISSUE-91

As I indicated last week, in
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Oct/0004.html,
I vote +1 for resolving ISSUE-91 in a way that does not require default values
for cardinalities, i.e., min 0 and max unbounded. I vote -1 for other ways of
resolving ISSUE-91.

ISSUE-57

Cardinalities on groups of constraints is a decided increase in expressive
power for SHACL.  Is there a semantics for this added expressive power that is
compatible with the rest of SHACL and can be effectively implemented?  Without
this I vote -1 for adding the construct.

ISSUE-86

I vote -1 on any proposal that requires or advocates putting shape and data
information or shape and ontology information together.  SHACL is not a
modelling language.  SHACL can function with shape information separated from
data and ontology information and this separation should be the suggested way
to use SHACL.

ISSUE-92

The proposals for resolving ISSUE-92 suggest that repeated constraints on the
same property be considered as "additive".  I do not feel that there is much
evidence to support the need for this reading.  In particular, the example in
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Sep/0107.html
does not need an additive reading as there is no overlap between the two sets
of possible values - all that is needed are qualified cardinality constraints
and a cleanup on constraints to generalize node-based constraints.  A proposal
for this cleanup is described in ISSUE-98.  I vote for this approach and
against the other approaches.

ISSUE-93

I agree that there is a conflation of good style with requirements on SHACL
shape graphs, particularly for rdfs:label and rdfs:comment.  I also agree that
good style should not be diluting the requirements for SHACL.

Separately, I agree that the requirements for SHACL shape graphs and SHACL
engines are smushed together and that the requirements for SHACL engines
should be refactored.  I think that the way to do this is to define SHACL
operations like validation and then describe what implementations of these
operations must or should or may do.  Validation reports are part of SHACL
validation, so it is not possible to just define what is required for data to
satisfy a shape as suggested in
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Sep/0232.html

ISSUE-94

I do not feel that there is any need to completely remove the RDF syntax
definition from the current SHACL document.  I do agree that there should be
more care taken to discuss SHACL constructs without appearing to require them
being RDF.  I also agree that the semantics of the constructs should be
written without depending on the RDF representation of SHACL constructs.

ISSUE-96

I feel that SHACL validation results already contain adequate information to
identify the construct in question.  Adding more information only complicates
an already-complex system.  I vote -1 for such additions.


peter

Received on Thursday, 8 October 2015 12:53:39 UTC