need of sh:hasShape (was: Re: ISSUE-68 and ISSUE-131: sh:hasShape and pre-binding)

On Sun, Jun 12, 2016 at 12:46 AM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> On 06/11/2016 02:33 PM, Dimitris Kontokostas wrote:
> >
> >
> > On Fri, Jun 10, 2016 at 4:21 PM, Peter F. Patel-Schneider
> > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> >
> >
> >     Then pre-binding shows up in the normative definition of every core
> >     constraint component and sh:hasShape shows up the normative
> definitions of
> >     sh:not, sh:and, sh:or, sh:shape, and sh:qualifiedValueShape.
> >     It is possible to implement the core of SHACL without using
> sh:hasShape and
> >     pre-binding but this implementation will be implementing something
> that is
> >     defined in large part by sh:hasShape and pre-binding.
> >
> >
> > Hi Peter,
> >
> > Could these core components be defined in the spec only with prose or
> would we
> > need another way (like a query generation algorithm)?
>
> It is certainly possible to make the normative definitions of the core
> constraint components be prose.  However, then that prose has to be
> carefully
> crafted so as to be precise and unambiguous.  The current textual
> definition
> boxes are generally acceptable, but some, e.g., sh:nodeKind, are rather too
> informal.  As well, there are often three places where portions of the
> meaning
> of a core constraint component is given in text - the introductory
> paragraph,
> the parameters block, and the textual definition.  It would be much
> preferable
> to only have one, normative textual definition.
>

I was asking specifically for the sh:not, sh:and, sh:or, sh:shape, and
sh:qualifiedValueShape not all core components as these are the only ones
affected by the sh:hasShape function.

Personally I was never in favor of this function but we decided to keep it
for various reasons some time ago. These reasons, among possible others,
included recursion and not increasing the complexity of the spec with code
generation algorithms.

Looks like there is no time to have a proper definition of recursion now
and if we can get away only with prose I see no need to have an official
but optional definition of sh:hasShape.

(My) reasons in favor of removing sh:hasShape

 - the spec defines sh:hasShape as optional for SHACL core but needed for
the extension language. The problem here is that the extension language
does not need sh:hasShape for anything it is only needed to define the
aforementioned core components.

- These components can be defined by other means, e.g Peter already
implemented all of them without sh:hasShape, I implemented only sh:shape
for now and plan for the rest. So, sh:hasShape only defines an optional way
to do something in the spec. I was planning to implement it in RDFUnit but
only because I would have to to make RDFUnit SHACL compliant.

- We could get some recursion with sh:hasShape but this could possibly be a
wrong type of recursion. When in SHACL 2.0 we tackle recursion correctly
there might be backwards compatibility issues that we didn't take into
account.

- sh:hasShape has to be implemented in every different RDF database, e.g.
every SHACL validation engine must have a different sh:hasShape
implementation for every RDF database it wants to support, e.g. one for
Jena, one for rdf4j, virtuoso, graphDB, blazeGraph, ... and thus increases
the barrier for shacl adoption.

- we can mark sh:hasShape as an implementation specific function or if
people see value in this function, move it to another document so there is
some standardization from this WG.

imho, if we can remove sh:hasShape with only a little more precise
definitions we'd remove a lot of complexity from the spec

Best,
Dimitris

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