- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Mon, 6 Jun 2016 13:55:49 +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+a1j=mBV54JhhORoAJSuT43XvgiT1biHWLPfVUY8jko-Mg@mail.gmail.com>
On Mon, Jun 6, 2016 at 9:31 AM, Dimitris Kontokostas < kontokostas@informatik.uni-leipzig.de> wrote: > > > 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. > Trying to back this up a bit, on a recent paper I presented last week in ESWC we had a related issue. http://svn.aksw.org/papers/2016/ESWC_Jurion/public.pdf If you look at the first paragraph of page 13, experts said that getting violations back when one runs a validation is very good but when you get nothing back (succesful validation) it is not as good as one would expect. The reason is that you cannot be 100% sure that you got a success because no errors were found or because you missed to define a constraint correctly so, if we allow constraints in places that they are just ignored, we give room for such errors and imho would be a wrong decision > 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 > > -- 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 10:56:45 UTC