Re: differing accounts of Shape Expressions

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

Thanks for the pointer to published material on SE3.  Is SE3 supposed to
supplant the semantics of SE1 or is it supposed to be equivalent to the
semantics of SE1?

I don't think that the working group can consider Shape Expressions to be
one thing.  SE1 and SE2 are completely different.  They target different
formalisms, they use different semantics, they have different constructors,
they have different intuitions.  If every time "Shape Expressions" is used
the working group has to figure out whether it is SE1 or SE2 (or SE3) then
the working group will be doing needless work.

peter

On 02/26/2015 09:37 AM, Jose Emilio Labra Gayo wrote:
> On Wed, Feb 25, 2015 at 7:04 PM, Peter F. Patel-Schneider 
> <pfpschneider@gmail.com <mailto: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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU7+bFAAoJECjN6+QThfjzG+QH/3J+VNOpPa+pn7m8HdslcGwv
YatBPkIrZ7z8jpsjG+a8sH8zarILTPwu/L38VbioSpDNQwNKMW3R6RCPv29677sx
0LY20EZ+G4/Ev5Zq9x8JuT7Cw7ZmOPcH194ZUtASni4X0ZJDlVUQDoK38McHg3el
oc+HEH8ibvcc2tdDcs9hW4KHcyhRiRBdfQM6oYyDO2JNJWMJJsD3/wjF01/iS0nO
2dv0ck+0tFMFbEXuoHcMrdOiXiON+f3keaQ+qmQwzb6Uo2uQlW1XoAnXuoewK29J
ivYFDl8t4/axHE5qjCw0J7yJMge1oLOhRo59yq2f1Kx627XAEK9eWsY2LKKQDac=
=YO8T
-----END PGP SIGNATURE-----

Received on Friday, 27 February 2015 03:39:15 UTC