Re: differing accounts of Shape Expressions

On Wed, Feb 25, 2015 at 7:04 PM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> There are three quite different accounts of Shape Expressions available off
> of http://www.w3.org/2001/sw/wiki/ShEx
>
> ...

> There is the ShEx/Operational Semantics at
>
> http://www.w3.org/2001/sw/wiki/ShEx/OperationalSemantics_Operational_semantics
> This appears similar in spirit to an axiomatic semantics for SHACL prepared
> by Jose Emilio Labra Gayo.  Let's call this SE3.
>
> SE3:
>
> The semantics in SE3 is an axiomatic semantics.  It works on a version of
> RDF graphs.  It appears to be non-additive, in that the matched portions
> of a
> graph are unioned together, but the account is missing many details.
> Apparently adding the missing details results in a semantics that is
> non-additive, i.e., conjoining something with itself requires two copies of
> whatever is matched by the conjunct.  The semantics also appears to be
> closed, i.e., every edge in the graph has to be used.
>
> SE3 is problematic because there are many missing portions of the
> axiomatization.
>
>

> Where does SE3 fit:
>
> SE3 appears to be an axiomatic semantics for the language of SE1 but it is
> hard to figure out just what is going on.
>

SE3 is indeed an attempt to capture the axiomatic semantics of SE1. It was
adapted from [1] and was the basis of the ShExcala implementation.

After that paper was published and the working group started I decided to
concentrate in what could be the possible outcome of the working group. One
of the missing pieces of that operational semantics was a way to keep track
of the triples that are being matched which can be useful to handle "Xor"
and "Negations"

During the F2F and these days I have adapted that axiomatic semantics to
Shacl. The result is:

http://labra.github.io/Haws/shacl/index.html

In fact, I did some modifications according to your suggestions.

For example, I moved "Closed shapes", "Negations" and "Xor" to a new
section about possible extensions to leave the core language as simple as
possible.

As it is, the core language is more or less the same as the language you
suggested in this email:

https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Feb/0266.html

the main difference is the semantic formalism. You are using a model-based
semantics and I opted for an operational semantics.

I think it would be more productive for the WG to concentrate on the
similarities and the common features of the different proposals than in
their differences.

In fact, I was also planning to add a section on how to map the core
language features to SPARQL so it would align also with Holger's proposal.

By the way, that operational semantics is quite easy to implement so one
can play with it. You can find a Haskell prototype here:

https://github.com/labra/Haws/blob/master/papers/shacl.hs

I am also working these days on a Prolog prototype that will be available
here (it is not finished yet).

https://github.com/labra/proshacl

As has already being said, the people that have been working on the Shape
Expression proposals are part of the WG and we are willing to contribute
and combine the different possibilities to obtain the best technology. I
think the fact that there are some differences like the treatment of
closed/open shapes, exclusive/inclusive or, etc. is a positive point so we
have a better understanding of the different alternatives and design
options.

Best regards, Jose Labra