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

On Mon, Jun 6, 2016 at 2:41 PM, Peter F. Patel-Schneider <
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>> wrote:
> >
> >
> >
> >     On Sun, Jun 5, 2016 at 11:36 PM, Peter F. Patel-Schneider
> >     <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