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

Yes, each constraint component should not need more than one implementation,
whether it is in the core or otherwise.  Otherwise there are just that many
more ways of introducing an error.

Yes, in the current setup each constraint component should be usable in node
constraints, in property constraints, and in inverse property constraints.
Otherwise there is an extra cognitive load on users to figure out when a
constraint component can be used.  The idea is to not have errors result from
these extra uses, though.  Just as sh:minLength does not cause an error when a
value node is a blank node neither should sh:datatype cause an error when used
in an inverse property constraint.  Of course, an sh:datatype in an inverse
property constraint will always be false on a data graph that is not an
extended RDF graph.

peter


On 06/05/2016 09:57 AM, Dimitris Kontokostas wrote:
> 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 <mailto: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>
>     > <mailto: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
>

Received on Sunday, 5 June 2016 20:36:50 UTC