- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 6 Jun 2016 08:26:48 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: Holger Knublauch <holger@topquadrant.com>, Karen Coyle <kcoyle@kcoyle.net>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
I don't see that this is about something that is always wrong. It is about something that can be determined to produce a violation on all values. However, there are lots of other things that can be easily determined to work the same way, for example ex:silly rdf:type sh:Shape ; sh:property [ sh:predicate ex:age ; sh:datatype xsd:integer ; sh:datatype xsd:int ] . Should this also be an illegal SHACL shape? I don't know of any advantage of the existing design over one that does not need more than one implementation of constraint components, except that it may be possible to have somewhat faster SPARQL code for extension constraint components if there is separate code for each kind of constraint. peter On 06/06/2016 06:02 AM, Dimitris Kontokostas wrote: > > > On Mon, Jun 6, 2016 at 2:41 PM, Peter F. Patel-Schneider > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote: > > I don't think that this argument speaks to my proposal. My proposal is not > that using sh:datatype in an inverse property constraint should be ignored. It > is that using sh:datatype in an inverse property constraint should produce > constraint violations instead of being syntactically illegal, just like using > sh:minLength does on a property value that is a blank node. > > > Apologies then, I mixed up the errors with the violations in what you said above. > > so, with this approach we will have to define something that will always be > wrong and instead of a "syntax error" we degrade it to "run time error". > This is something we can still decide to do with the existing spec and keep > the context information as is. > > in general, although I am sympathetic to the idea of a default (global) > implementation I think there is a lot of value in the existing design to just > throw away > > > > One could argue, I suppose, that sh:minLength should produce a failure when > used on a blank node and so should sh:datatype in an inverse property > constraint. But then sh:datatype should produce failures instead of > constraint violations on IRIs when used in other contexts and sh:class should > produce failures instead of constraint violations on literals and several > other situations should also produce failures instead of constraint > violations. > > peter > > > On 06/06/2016 03:55 AM, Dimitris Kontokostas wrote: > > > > > > On Mon, Jun 6, 2016 at 9:31 AM, Dimitris Kontokostas > > <kontokostas@informatik.uni-leipzig.de > <mailto:kontokostas@informatik.uni-leipzig.de> > > <mailto:kontokostas@informatik.uni-leipzig.de > <mailto:kontokostas@informatik.uni-leipzig.de>>> wrote: > > > > > > > > On Sun, Jun 5, 2016 at 11:36 PM, Peter F. Patel-Schneider > > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com> > <mailto:pfpschneider@gmail.com <mailto: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 > > > > > > > -- > 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 15:27:19 UTC