Re: STRAWPOLL on Approach for SHACL

I agree that the same thing expressed in one language or another 
(SPARQL, FO logic, bag languages, ...) should not be more or less 
difficult to analyse. Some languages however have been there for tens of 
years, their expressive power and algorithmic complexity are well 
understood, and using these languages allows for getting faster results 
regarding static and complexity analysis.

Of course people will study static analysis of SHACL even if its 
semantics is defined in SPARQL. However, it will probably take more 
time, and will probably be done by first translating the semantics in 
some other formalism. What could also happen is that some aspects show 
to be difficult to formalize, and are left out.

As far as I know, all members of the working group agree on the idea of 
having a SPARQL-based extension mechanism. On the F2F meeting in 
February we also agreed that a SPARQL equivalent will be given whenever 
possible, including for the core language. Defining the semantics 
independently on SPARQL does not mean that SPARQL will be discarded, but 
rather that we start with something that is *by construction* easier to 
analyse, and also sound because we will have time to show its soundness. 
As SPARQL is a very expressive language, we are sure that the 
descriptive semantics is translatable into SPARQL, whereas the opposite 
translation would be harder to achieve.

I understand the concern about formal semantics being harder to 
understand by implementers. However, having formal semantics does not 
mean that it will be the unique semantics given.
My colleagues and myself are currently working on extending our initial 
ShEx semantics to cover more requirements, unifying the three initial 
semantics whenever possible. As part of this work, we plan to provide a 
description of the semantics in English for neophyte users, as well as 
precise algorithms for implementers. Unfortunately, all this takes time, 
and I prefer not to show partial results before being certain that these 
are correct.

A last (for now) argument in favour of declarative semantics is that 
formalisms like first-order logic and regular languages are known to a 
large community: even those who do not like formal methods have possibly 
heart about these during their studies. This community is on my opinion 
larger than the one of SPARQL users.

Best regards,
Iovka


Le mer. 01 avril 2015 13:54:05 CEST, Peter F. Patel-Schneider a écrit :
>
> -----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-----



-- 
Iovka Boneva
Associate professor (MdC) Université de Lille
http://www.cristal.univ-lille.fr/~boneva/
+33 6 95 75 70 25
Please note that I read my mails twice a day at 9:00 and 13:00 (CET)
For urgent matters, please contact me by phone

Received on Wednesday, 1 April 2015 20:21:22 UTC