Re: STRAWPOLL on Approach for SHACL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I agree that SPARQL is complex, but I don't see how specification in SPARQL
hurts static analysis of SHACL.

SHACL has (or is extremely likely to have) an extension mechanism that is
SPARQL.  Any static analysis of all of SHACL is thus going to involve
analysis of SPARQL.

Static analysis of the high-level language of SHACL need not involve
analysis of all of SPARQL.  Only the aspects of SPARQL that are used by the
high-level language of SHACL participate, and only to the extent that they
are used by the high-level language of SHACL.  If the high-level language of
SHACL is easy to analyze, it will be easy to analyze when recast as SPARQL.

SPARQL is a query language.  Query languages have been extensively analyzed,
in particular for query optimization but also for other properties.   If
SHACL is specified via SPARQL, then that analysis becomes available for use
when analyzing SHACL.

In the end, I think that specifying SHACL in terms of SPARQL may end up
making analysis of SHACL easier.  However, this depends in part on what ends
up in the high-level language of SHACL.  If the high-level language of SHACL
uses parts of SPARQL that are hard to analyze then the specification of
SHACL via transformation to SPARQL is not going to make analysis easy.  But
if this is the case there is nothing to prevent analysis being performed by
looking at an equivalent specification.

peter



On 04/01/2015 12:19 AM, Iovka Boneva wrote:
> As I am against using SPARQL for defining the semantics, I catch the
> question to Jose to give you my reasons.
> 
> I consider very important to be able to perform static analysis on
> shapes. The semantics of SPARQL is by itself complex, and would make
> static analysis very hard.
> 
> 
> If SHACL becomes widely used (which I hope will be the case), then lots
> of people will be interested in performing static analysis. Static
> analysis is useful at least for query optimization and simplification of
> shapes, and certainly for many other reasons that will come up with
> applications. As an example, my colleagues and myself have ideas on how
> to use shapes for easier data integration, and would need to perform
> static analysis for that.
> 
> Typical static analysis problems are testing inclusion and equivalence
> of shapes, testing whether two shapes are compatible (non disjoint),
> testing whether a shape is compatible with a query.
> 
> A SPARQL based semantics would make static analysis very hard. For
> instance, inclusion of SPARQL queries is undecidable, and in order to
> have decidable problems, one would need to end up with different kinds of
> restrictions of SPARQL, which always complicates things.
> 
> For making static analysis easier, it is very much preferable to adopt a 
> restricted core language with controlled expressive power, and with 
> declarative semantics based on a well studied formalism.
> 
> Iovka
> 
> 
> Le lun. 30 mars 2015 22:42:09 CEST, Peter F. Patel-Schneider a écrit :
>> 
> Hi Jose:
> 
> Are you against using SPARQL as a specification formalism for the
> high-level language of SHACL even if there is no need to use a SPARQL
> implementation (or equivalent) to actually implement the high-level
> language of SHACL?
> 
> If so, what aspects or features of such a specification are you against?
> 
> peter
> 
> 
> On 03/26/2015 10:52 AM, Jose Emilio Labra Gayo wrote:
>>>> 
>>>> I was going to vote but reading the options, they are both options 
>>>> reasonable, what worries me is if there is some hidden implication
>>>> about the relationship between SHACL and SPARQL.
>>>> 
>>>> If option a) doesn't imply that the high-level language constructs
>>>> will be merged with the SPARQL definitions, I would not have a
>>>> problem if they are in the same document but in separate sections.
>>>> 
>>>> However, if voting option (a) implies that the high-level language
>>>> will be tied to SPARQL as it currently is, the my vote will be
>>>> against.
>>>> 
>>>> Best regards, Jose Labra
>>>> 
>>>> 
>>>> On Thu, Mar 26, 2015 at 2:36 AM, Arnaud Le Hors <lehors@us.ibm.com 
>>>> <mailto:lehors@us.ibm.com>> wrote:
>>>> 
>>>> There has been a lot (!) of discussion on the mailing list and I'd
>>>> like to get an update on where the WG stands with regard to the
>>>> different approaches being proposed. I know this doesn't capture
>>>> all the issues (obviously) and some will feel that this isn't the
>>>> right question but at least this is one point of contention that we
>>>> need to address so, please, bear with me.
>>>> 
>>>> Rather than doing this just on a teleconference I set up a wiki
>>>> page so that who can't attend the teleconference can still
>>>> respond: 
>>>> https://www.w3.org/2014/data-shapes/wiki/Strawpoll_On_Approach
>>>> 
>>>> Thank you. -- Arnaud Le Hors - Senior Technical Staff Member, Open
>>>> Web Technologies - IBM Software Group
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- -- Jose Labra
>>>> 
> 
>> 
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVG9xdAAoJECjN6+QThfjz3D4IAKYMd/7yW0fUaJHRtWDDUDny
8WQDzrJEP9uDo0b3x9K1Mo59k29tZeF/Sc8uSYocQfiuwTY3PN0slGpnTofQ+8xa
mlBYMoq5Nw11qPHcstXQ450xslt/sbjWJ98L6HO+Stk7V5023i+dwyR+Kj1gbGuQ
xggxqpCcHgI3zPCL9MaaUDpFaBj+kkLfL05Zc6n4d5adSByIv3ebRc/qC1OUSgFw
EQeB+XNOuG2BA0r+Muk/8WLXfasVb8/CaeFs9kGM/81rf33q5kPANRRIrTsNGQfj
WPFREzesBK2rQXGOGmJI6UFIY38uhxbrbs8mbgGLT2nMGjBays1FO08C2s5QOdI=
=To2J
-----END PGP SIGNATURE-----

Received on Wednesday, 1 April 2015 12:09:19 UTC