Differing Visions of SHACL

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


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.


peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU5iU6AAoJECjN6+QThfjzLzsH/28S9bBk1m6vrX2czrx2OCJn
tfd3y5jlOQbr/SpSj+BkiNwC/cEQf7rs97ynKwS0ISFXcTs9QGzx60UPQE8Ms9gI
xFZI40UEcvMS2HjY3L3WSeNptkJXOVXtKuoeb/qKpFWFT/4eBZxCsmpk0bQMpiaf
4uTVwlKM08Akdca/UuanQH3000v3fW0pabrXAIjvDXhNVyF/60T7vFNbcDy5QZ8y
NfSEBN2JoLopcwL3gxUrTOXNjjttt08y5jw4tDJb7sP4w/XVLRaUIgW0jJSxGdCk
RFKcEzSsxwOVdjVV36SytOSOWPzEvwlGqf5tUvMTDVd5wqzpZMnbFmjlQZ81so0=
=hAb5
-----END PGP SIGNATURE-----

Received on Thursday, 19 February 2015 18:03:08 UTC