Re: STRAWPOLL on Approach for SHACL

Static analysis of SPARQL queries may be hard, but not very hard. The inclusion problem over the subset known as “well-designed SPARQL”, which includes most if not all practically occurring queries, is decidable. The semantics of SPARQL is a variation of relational algebra, a well-studied formalism. For SHACL to become widely used, the number of implementers has to exceed the number of academics researching it, and the semantics must be accessible to them. The semantics of SHACL being defined in SPARQL doesn’t prevent the use of other formalisms for analysing it.

Best,
Richard


> On 1 Apr 2015, at 08:19, Iovka Boneva <iovka.boneva@univ-lille1.fr> 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 :
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> 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
>> 
>> iQEcBAEBAgAGBQJVGbUhAAoJECjN6+QThfjz4YcIAKPfBa9XucZ1sRmxghaHqlq1
>> 1M0umxM79QXRBjNL3qO1R2QZRGo3tgrrZf0cKTBJOXFSRaEyX5g7nZuy3gGkFHNz
>> jrjN393t9wNZ4ZVJLPTN+zsETECeSlwho6k2qGheX1DS/biwfeUg9ZSJx2d/Av+v
>> faT8yQN7dR4I3GDiSl4uL3VZfdkqqzq56mGlzTocPDfiLNMThBaJX6dn/WuWnzMF
>> XjPITr42kwFeow4Cq0DQ4OgqvoahRA0EtVmI+IoBEVcj/yJgxSzn9qc6UvwV7HPd
>> EQEe1dHN9eUwUlHdQWynn8PlO942qroeP4Nqa120Vo3Egowr8A94RcK0q3+l7Ig=
>> =pLs4
>> -----END PGP SIGNATURE-----
>> 
> 
> 
>

Received on Wednesday, 1 April 2015 07:58:58 UTC