- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Mon, 6 Jun 2016 09:31:54 +0300
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Holger Knublauch <holger@topquadrant.com>, Karen Coyle <kcoyle@kcoyle.net>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a1TkbOLx87TGqNk7b3CbyCBMUZHiOOBK6noqs5F2RVKtA@mail.gmail.com>
On Sun, Jun 5, 2016 at 11:36 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > 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. > I would argue that all these cases should throw an error, otherwise it would again require extra cognitive load to remember when a use of a constraint is actually used or ignored. One other case is optimization, if we require "no more than one" implementation then we may result in very inefficiently defined constraints. e.g. for a particular context (and a particular value of the constraint) I can probably create a very efficient SPARQL query that is many times faster than the general one, with your approach we loose that advantage. When we test small / in-memory graphs the delay might not be so noticeable but in big SPARQL endpoints it may result in very big delays or even failing to run the query > > 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 > > > > -- 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:32:50 UTC