Re: STRAWPOLL on Approach for SHACL

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

On 04/01/2015 01:20 PM, Iovka Boneva 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.

I would think that the opposite would be true.  A specification of SHACL in
SPARQL would allow results about static analysis of SPARQL to be carried
over to SHACL.   Of course, this also could be done if SHACL was specified
otherwise, by showing that a translation to SPARQL is equivalent to the
other specification for SHACL.

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

This is not correct.  The actual resolution can be found at
http://www.w3.org/2015/02/18-shapes-minutes.html#resolution02

RESOLUTION: Define semantics using SPARQL as much as possible

That's very different from your claim.

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

I think that now is the time to show some results.

> 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
> heard about these during their studies. This community is on my opinion
> larger than the one of SPARQL users.

I don't see any relevance for this last bit.
> 
> Best regards, Iovka

peter

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

iQEcBAEBAgAGBQJVHJuAAAoJECjN6+QThfjzL1QIALlHGPBeTi0Pj8kpqmDYzink
5D7F/cWb78FCkLPqYDghKQeOb5OKyPc8vBENvw0YUj4qEWWU+yRc0D72ybuFMf4a
fQ7QNFFJn41DUWEkg7lxjmJl49a8JF0iINTuggKTiimKVgUI3Nr5XImYssYZpXOo
BbizOhdhdEPyBGClcFH6BdPquDktFSC1bhcKtKqDHCgXkaMNBuiBJHD5+MXgMCQD
9SScSbmbkPycZa+krx8zsFDDOVXv6asLVkbL65iAVm+ObPEkMTJWGty6TAkHF54W
0m6V0OdVm4y4kTRAyyenJMuKhNQNNX8y0or0JlQupEcQWeZzub8RVJi9FZAoU3w=
=0R1u
-----END PGP SIGNATURE-----

Received on Thursday, 2 April 2015 01:30:07 UTC