Re: Differing Visions of SHACL

On 2/20/2015 4:02, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> During the F2F it became evident to me that different working group
> participants have differing visions of how SHACL should be put together.
>
>
> One vision is that SHACL will be a thin veneer over some existing language
> (e.g., SPARQL), which provides the bulk of the definition of SHACL.  A
> potential advantage of this vision is that implementation should be very
> easy - all that is needed is an implementation of the existing language and
> an easy-to-implement translation into that language.

Yes I can confirm that implementing this is very easy. The bulk of the 
work happens declaratively as part of the system vocabularies that point 
at the SPARQL queries. The hard-coded (Java) algorithm can be very small.

>    A disadvantage is that
> it limits the things that can be done to things that can be translated into
> the existing language.  (For SPARQL this would mean excluding recursive
> shape recognition and maybe closed shapes.)  An extreme version of this
> vision is that all that the working group needs to do is to produce a way of
> defining translations, and use this mechanism to provide some built-in
> translations.

Just defining the translations would not cover the requirements of a 
declarative high-level language.

>
>
> Another vision is that SHACL will incorporate some new technology.  This
> technology will have some core components that can be expressed as RDF (as
> in the first portion of LDOM), some extensibility mechanism (e.g., OWL
> constraints), and maybe a general-purpose extension mechanism which could be
> implemented via translation into some existing technology (e.g., SPARQL).
> The advantage of this approach is that it is not limited to what can be done
> in some existing technology.  A potential disadvantage is that completely or
> largely new implementations may be required, although even in this case it
> might be possible to partially implement SHACL by a translation into an
> existing technology.  Another potential disadvantage is that extensibility
> via translation might not be able to use the entire facilities of the
> existing technology because part of that existing technology might not fit
> with the definition of SHACL.  For example, if the SHACL is defined
> model-theoretically then any portion of SPARQL that looks inside node IRIs
> might not be usable.
>
>
> The two visions induce differing stances on a number of issues that have
> been discussed at the face-to-face, including what should be in the core,
> whether it matters what should be in the core, and how to produce semantics
> for SHACL.

I believe most (if not all) of the concerns that the ShEx camp has 
expressed (e.g. static analysis, performance guarantees) can be solved 
through the sh:Profile mechanism. ShEx can be defined as a profile that 
selects certain templates with desirable characteristics. They can even 
define an algebra for that profile if they find this useful.

BTW I am fully supportive of having an open architecture in which other 
languages than SPARQL can be used. This may include JavaScript, ShExC 
and even OWL class expressions. But in this first version of SHACL, 
SPARQL needs to be supported by default. Some processors may decide to 
use their native engines instead of SPARQL, and that's OK to implement 
some profile of the overall language.

Holger

Received on Thursday, 19 February 2015 23:58:25 UTC