W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > May 2017

Re: formal objection on excluding many well-behaved shapes from SHACL

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 5 May 2017 07:32:23 -0700
To: Irene Polikoff <irene@topquadrant.com>
Cc: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Message-ID: <0fbda12c-939e-31b3-05c4-3b583ae117d6@gmail.com>
There is overlap, but the two objections are different.

peter

On 05/05/2017 07:20 AM, Irene Polikoff wrote:
> Peter,
> 
> In this formal objection you have repeated what you have already said in the formal objection about paths syntax.
> 
> Does this formal objection, therefore, supersede the paths formal objection as you combined them into one?
> 
> If the answer is ‘no’ - please rephrase this formal objection not to include the content from another formal objection.
> 
> Irene
> 
>> On May 5, 2017, at 10:12 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>> This is a formal objection to the exclusion from SHACL of numerous shapes
>> that have well-behaved intuitive meanings.  A number of these exclusions
>> first appear in the 11 April 2017 version of SHACL.  The overall severity of
>> these exclusions was noticed during an attempt to produce an implementation
>> of SHACL Core.
>>
>> There is no technical reason to exclude numerous shapes that have been
>> excluded from SHACL and good reasons to permit them.  The exclusions make
>> SHACL harder to write for users.  As SHACL implementations are free to
>> behave however they want on shapes graphs that contain these excluded shapes
>> the exclusions serve as an impediment to interoperability in SHACL.
>>
>> In most cases the only change required to SHACL to no longer exclude these
>> shapes and thereby improve the utility and the interoperability of SHACL is
>> to just remove syntax rules that exclude them.  There is no need to change
>> the semantics of SHACL at all to include these shapes.   The burden on
>> implementators will be very low, and in many cases there will be no burden
>> at all, as these excluded shapes act like similar non-excluded shapes.
>>
>>
>> Some of these exclusions are as if a programming language made (x>4 && x>6)
>> illegal, but left (x>4 && x>=6) legal.  These syntax restrictions make it
>> hard for SHACL users to write legal SHACL shapes graphs.  If there is a need
>> to warn users about these shapes, it is better to do so using a lint-like
>> tool that is not tied to the syntax of SHACL.
>>
>> Actually, the situation is even worse in SHACL than it would be if a
>> programming language had these sorts of exclusions.  Completely conforming
>> SHACL implementations are free to do anything at all on most invalid syntax
>> so a SHACL implementation can signal an error or return any set of
>> validation results on shapes that contain the analog of (x>4 && x>6), even
>> though the intuitive behaviour of these shapes is completely clear.
>>
>>
>> Some of the excluded shapes are degenerate in that they will produce
>> validation results for all focus nodes or all focus nodes that have a value
>> for a particular property.  For example, the excluded shape
>>  ex:false a sh:PropertyShape ;
>>    sh:path ex:p ;
>>    sh:datatype xsd:integer ;
>>    sh:datatype xsd:int .
>> will produce a validation result for every focus node that has a value for
>> ex:p.   However, many shapes that are degenerate in this sense are not
>> excluded.
>>
>> Others of the excluded shapes are not degenerate in this way but instead
>> have constraints that are redundant.  For example, in the excluded shape
>>  ex:redundant a sh:PropertyShape ;
>>    sh:path ex:p ;
>>    sh:minInclusive 5 ;
>>    sh:minInclusive 9 .
>> one of the constraints is redundant.  However, many similar shapes that also
>> have redundant constraints are not excluded.
>>
>> Some of the excluded shapes don't even have any redundant constraints.  For
>> example in the excluded shape
>>  ex:dateTime a sh:PropertyShape ;
>>    sh:path ex:p ;
>>    sh:minInclusive "2002-10-10T12:00:00-05:00"^^xsd:dateTime ;
>>    sh:minInclusive "2002-10-10T12:00:00"^^xsd:dateTime .
>> neither of the constraints are redundant.  To exclude all dateTime values
>> before "2002-10-10T12:00:00-05:00"^^xsd:dateTime and also before
>> "2002-10-10T12:00:00"^^xsd:dateTime requires two uses of sh:minInclusive.
>>
>> Some others of the excluded shapes are somewhat degenerate for standard RDF
>> graphs but not for generalized RDF graphs, where literals can be subject of
>> triples.  For example, in standard RDF the excluded shape
>>  ex:generalized a sh:NodeShape ;
>>     sh:lessThan ex:p .
>> produces a validation report for nodes that have values for ex:p and can be
>> better stated for standard RDF graphs as a property constraint with path
>> sh:p and sh:maxCount 0.  In generalized RDF this shape is not degenerate as
>> it also produces a validation report for some literals.  However, many
>> shapes that are degenerate in this way for standard RDF graphs but not
>> degenerate for generalized RDF graphs are not excluded.
>>
>> Yet others of the excluded shapes are not excluded for any discernible
>> reason at all.  For example, the excluded shape
>>  ex:comments a sh:PropertyShape ;
>>    sh:path [ rdfs:comment "inverse of ex:p" ;
>>    	      sh:inversePath ex:p ] ;
>>    sh:class ex:C .
>> does not have any problems whatsoever.  Its meaning is clear.  It does not
>> accept or reject all nodes.  It does not have any redundant pieces. It is
>> excluded for no discernable reason.
>>
>> It is easy for users to accidentally write these excluded shapes.  Automatic
>> generation of SHACL shapes is made harder by these exclusions.  There are
>> extra costs when implementing SHACL syntax checking because of these
>> exclusions.
>>
>> Interoperability is particularly harmed by these exclusions.  Fully
>> conforming SHACL implementations may implement ex:false as producing a
>> validation report for all nodes.  They may instead implement ex:false as
>> never producing a validation report, on the argument that multiple
>> sh:datatype constraints should just be removed.  They may implement ex:false
>> as not producing a validation report for literals with datatype xsd:integer,
>> or xsd:int, because the implementation assumes that only one sh:datatype can
>> be present.  They may even implement ex:false as sometimes not producing a
>> validation report for literals with datatype xsd:integer, and sometimes not
>> producing a validation report for literals with datatype xsd:int.
>>
>>
>> These exclusions should be removed from SHACL by removing the syntax rules
>>
>>  datatype-maxCount, nodeKind-maxCount, minCount-scope, minCount-maxCount,
>>  maxCount-scope, maxCount-maxCount, minExclusive-maxCount,
>>  minInclusive-maxCount, maxExclusive-maxCount, maxInclusive-maxCount,
>>  minLength-maxCount, maxLength-maxCount, languageIn-maxCount,
>>  uniqueLang-scope, lessThan-scope, lessThanOrEquals-scope,
>>  qualifiedValueShape-scope, and in-maxCount
>>
>> and changing the syntax rules
>>
>>  path-metarule, path-non-recursive, path-predicate, path-sequence,
>>  path-alternative, path-inverse, path-zero-or-more, path-one-or-more, and
>>  path-zero-or-one
>>
>> to
>>
>> path-non-recursive A node p is not a well-formed SHACL property path if
>> 		   p is a blank node and any of the following rules require,
>> 		   directly or indirectly, determining whether p is a
>> 		   well-formed SHACL property path.
>>
>> path-metarule     A node is a well-formed SHACL property
>> 		  path if it satisfies exactly one of the following
>> 		  rules and if it is a blank node it does not have a value
>> 		  for more than one of rdf:first or rdf:rest,
>> 		  sh:alternativePath, sh:inversePath, sh:zeroOrMorePath,
>> 		  sh:oneOrMorePath, and sh:zeroOrOnePath.
>>
>> path-predicate    A predicate path is any IRI.
>>
>> path-sequence 	  A sequence path is a blank node that is a SHACL list with
>> 		  at least two members and each member of the list is a
>> 		  well-formed SHACL property path.
>>
>> path-alternative  An alternative path is a blank node that has exactly one
>> 		  value for sh:alternativePath and that value is a SHACL
>> 		  list with at least two members and each member of the list
>> 		  is a well-formed SHACL property path.
>>
>> path-inverse      An inverse path is a blank node that has exactly one value
>> 		  for sh:inversePath and that value is a well-formed
>> 		  SHACL property path.
>>
>> path-zero-or-more A zero-or-more path is a blank node that has exactly one
>> 		  value for sh:zeroOrMorePath and that value is a
>> 		  well-formed SHACL property path.
>>
>> path-one-or-more  A one-or-more path is a blank node that has exactly one
>> 		  value for sh:oneOrMorePath and that value is a
>> 		  well-formed SHACL property path.
>>
>> path-zero-or-one A zero-or-one path is a blank node that has exactly one
>> 		 value for sh:zeroOrOnePath and that value is a
>> 		 well-formed SHACL property path.
>>
>> The change to path syntax not only permits paths that should not be excluded
>> but also excludes paths that should not be included, such as
>>  [ rdf:first ex:p ; rdf:rest ( ex:q ) ; sh:inversePath ex:p ]
>>
>> These changes to the syntax of SHACL results in a SHACL that is easier to
>> write, easier to generate, easier to implement, and more interoperable.
>>
> 
Received on Friday, 5 May 2017 14:32:59 UTC

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