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

On 6/06/2016 6:36, Peter F. Patel-Schneider wrote:
> Yes, each constraint component should not need more than one implementation,
> whether it is in the core or otherwise.

While I share the same goal, I don't see how it can work in practice. 
You have not yet responded to how this would look in cases like 
sh:hasValue where being forced to use the query snippet for node 
constraints and property constraints would lead to abysmal performance.


>    Otherwise there are just that many more ways of introducing an error.

This is IMHO not a strong enough argument to *prevent* multiple queries. 
It's a nice-to-have. No need to cripple the language just for that. If 
an extension developer creates a poorly tested and broken extension then 
it's a bug that he or she needs to fix. That's the same as everywhere.

>
> 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.

I completely disagree. Compared with OWL, this policy would mean that 
any constraint-like property should be applicable everywhere. For 
example in addition to

ex:Person
     a owl:Class ;
     owl:disjointWith ex:Animal ;
     rdfs:subClassOf [
         a owl:Restriction ;
         owl:onProperty ex:gender ;
         owl:maxCardinality 1 ;
     ] .

the policy that you propose would also allow

ex:Person
     a owl:Class ;
     owl:maxCardinality 1 ;
     rdfs:subClassOf [
         a owl:Restriction ;
         owl:onProperty ex:gender ;
         owl:disjointWith ex:Animal ;
     ] .

Do you remember why the OWL WG did not apply the same policy that you 
describe?

In the case of SHACL you would allow something like

ex:PersonShape
     a sh:Shape ;
     sh:maxCount 1 ;
     sh:property [
         sh:predicate ex:gender ;
         sh:closed true ;
     ] .

(Note the sh:maxCount would be utterly confusing to people, needlessly 
increasing the cognitive load.)

There are good reasons why languages are designed to disallow certain 
nonsensical statements: they support "compile-time" checking of syntax 
errors, and enable input forms to suggest relevant properties.

I would also appreciate a response to the case of primary keys from my 
previous email. Using them in inverse property constraints would be 
meaningless and misleading. There must be a way for extension developers 
to indicate for which cases a constraint component can be used. 
sh:context is playing that role. We could potentially use Shapes and 
sh:scopeClass instead, but then the meta-shapes would overlap with the 
actual data shapes.

I believe the general problem that we have again and again is that you 
(Peter) seem to focus on the constraint validation aspect only, while I 
(and hopefully others) also want workable support for the other use 
cases of SHACL such as form generation. From a pure validation 
perspective, it may indeed be possible to formulate queries for all 
three cases, even if they are dummies. But from a users' perspective 
this makes no sense. And even from an implementation point of view, 
forcing all the 3 cases everywhere is an extra burden. I believe cutting 
down to a maximum of two queries will be acceptable and is easily 
achievable without the drastic redesign you are proposing.

I wouldn't mind walking through the core vocabulary again to see if we 
can further generalize some components. For example sh:hasShape could be 
applied to node constraints too (pending a renaming probably). But there 
still needs to be a generic context mechanism for extension authors. As 
a tool developer I need that feature.

Holger

>
> 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 Monday, 6 June 2016 06:14:40 UTC