Re: STRAWPOLL on Approach for SHACL

Iovka,

Concerning static analysis, that is only possible in the absence of
extensions. As soon as you add extensions then you bring in the full
complexity of the extension language (SPARQL, JS, etc.) and you are
led to undecidable problems.

Therefore, we really only can do static analysis on the core language.
But that semantics of the core language are expressible is many
equivalent ways. Therefore, isn't it immaterial to the issue of static
analysis if the WG provides formal semantics in SPARQL?

-- Arthur


On Wed, Apr 1, 2015 at 4:20 PM, Iovka Boneva
<iovka.boneva@univ-lille1.fr> wrote:
> 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 21:58:39 UTC