ISSUE-139: uniform descriptions and implementations of constraint components

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?  Why should sh:minCount need two
(or three) implementations?

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.

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 Sunday, 5 June 2016 15:07:10 UTC