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

So, this goes into the SPARQL extension mechanism, which also affects the
definition of the  core language and, with what you propose,
- there should be *only one* SPARQL query that will address all three
contexts, and any other contexts we may introduce in the future (e.g. for
paths)
- even if it doesn't make sense in some cases or even if it would result in
an error when used, all contexts will be enabled for all components with
this one generic SPARQL query, right?

(apologies if you discussed this already on the last telco)

Dimitris


On Sun, Jun 5, 2016 at 6:06 PM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> 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?  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
> >
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT