Re: ISSUE-139: uniform descriptions and implementations of constraint components

On 6/06/2016 1:06, Peter F. Patel-Schneider wrote:
> My recent messages have been about constraint components in general.  Of
> course, the examples of constraint components that are easiest to discuss are
> the core constraint components, and when discussing core constraint components
> there are also issues related to how they are described in the SHACL
> specification.
>
>
> Right now constraint components in both the core and in the extension have the
> potential for tripartite behaviour - one behaviour in node constraints, one
> behaviour in property constraints, and one behaviour in inverse property
> constraints.  No core constraint components actually work this way at present,
> but the potential is there.  This should be changed so that constraint
> components, both in the core and in the extension, have a common behaviour for
> node constraints, property constraints, and inverse property constraints.
>
> Not only should each constraint component have a single behaviour, but
> constraint components should share common behaviours.  Right now it is
> possible for a constraint component to do something completely different with
> the property.  For example, a constraint component could decide to use the
> constraint's property in an inverse direction in both inverse property
> constraints and property constraints or could just ignore the property altogether.
>
> Further, there should also be a common description of this behaviour common to
> constraint components.  Some core constraint components, e.g., sh:class, are
> already described using a terminology, namely value nodes, that can easily
> apply to all constraint components.  Other constraint components, such as
> sh:minCount and sh:equals, are described using different terminology that
> describes the same thing.  This makes sh:minCount and sh:equals appear to be
> quite different from sh:class.  Either the descriptions should align or there
> should be different syntactic categories for sh:class and sh:minCount.
>
> It is also possible to resolve this problem by using a different syntax for
> SHACL.  ShEx does this by having a single property-crossing construct.  OWL
> does this by having multiple property-crossing constructs, including
> ObjectAllValuesFrom and ObjectSomeValuesFrom.  In both ShEx and OWL there are
> many constructs, including the analogues of sh:class, that then just work on
> single entities with no need to worry about focus nodes vs value nodes or
> properties vs inverse properties.
>
>
> Along with the problems of differing behaviour and description there is also
> the problem of tripartite implementations, both of core and extended
> constraint components.  Why should sh:class need three pointers to
> implementations, even if they are the same?

This could easily be fixed, e.g. by introducing a property 
sh:defaultValidator. I prefer incremental steps over restarting.

>    Why should sh:minCount need two (or three) implementations?

If we accept path expressions into SHACL then there would only be a 
single sh:pathValidator.

>
> One could say that this doesn't matter at all because SHACL implementations
> are free to implement core constructs however they see fit.  However, this
> implementation methodology is completely exposed for constraint components in
> the extension.  It would be much better if only a single simple implementation
> was needed for each constraint component.  It would also be much better if the
> implementations of constraint components did not need to worry about how value
> nodes are determined.
>
>
> So my view is that SHACL is currently has the worst of all possible worlds.
> Its syntax is complex, because each constraint component has its own rules for
> where it can occur.  Its behaviour is complex, because each constraint
> component decides how to behave in each kind of constraint.  Its description
> is complex, because different constraint components are described in different
> ways.  Its implementation is complex, because constraint components can have
> up to three different implementations each of which is often more complex than
> necessary.

SHACL has the current level of complexity because the range of possible 
use cases is complex. There is no free lunch. Simplifying too much would 
limit what SHACL can do, e.g. only a sub-set of SPARQL. This dangerously 
reminds me of the OWL DL mantra to limit the expressivity of the 
language so that certain OWL reasoners don't run into worst-case 
behavior. I hope we are not repeating the same mistakes and don't 
produce yet another ivory tower language here.

Holger


>
> peter
>
>
>
>
>
>
> On 06/05/2016 06:45 AM, Dimitris Kontokostas wrote:
>> I was planning to ask for clarifications on this as well
>>
>> Is this thread about enabling all contexts in all SHACL Core components only
>> or a suggestion to change the SPARQL extension mechanism in general?
>> These two can be independent of each other imho.
>>
>> Best,
>> Dimitris
>>
>> On Sun, Jun 5, 2016 at 10:10 AM, Holger Knublauch <holger@topquadrant.com
>> <mailto:holger@topquadrant.com>> wrote:
>>
>>      Peter, could you clarify whether you were only talking about the core
>>      constraint components and how the spec would define them, or about the
>>      general mechanism? I am not too concerned about how we write things in the
>>      spec. There is only one SPARQL query per component right now in the spec.
>>
>>      Thanks
>>      Holger
>>
>>      Sent from my iPad
>>

Received on Monday, 6 June 2016 06:30:43 UTC