- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 09 Apr 2015 16:53:51 -0700
- To: Arthur Ryman <arthur.ryman@gmail.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Having an independent specification for the high-level part of SHACL is a bad idea in my opinion. What happens if the partial specification disagrees with the specification for all of SHACL? That said, I have nothing against providing a specification for just the high-level part of SHACL provided that this specification is clearly subservient to the specification for all of SHACL. peter On 04/02/2015 01:07 PM, Arthur Ryman wrote: > Peter, > > I hope so. However, I believe that we can and should state the semantics > of a HL SHACL independently of an extension mechanism. That semantics > would be enriched by the inclusion of extensions. > > -- Arthur > > On Sat, Mar 28, 2015 at 4:35 PM, RDF Data Shapes Working Group Issue > Tracker <sysbot+tracker@w3.org> wrote: >> shapes-ISSUE-31 (unitary semantics): Is there going to be a single >> unitary semantics for all of SHACL [SHACL Spec] >> >> http://www.w3.org/2014/data-shapes/track/issues/31 >> >> Raised by: Peter Patel-Schneider On product: SHACL Spec >> >> Is there going to be a single unitary semantics for all of SHACL, with >> the high-level language constructs defined using that semantics, or are >> there going to be two semantics for SHACL, one for the high-level >> constructs and another for the rest. >> >> >> >> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVJxEPAAoJECjN6+QThfjzSU8IANEzubIx55R2VH+yhW4td24s VBYqmuBffF602CbnhiNjB6pfg4UIz/yjY2cb/fFM3KW+xvqYdai2VR0cr8sYstGq A8qI1VTSS8N2TpEICf34sprdaU55g0+2+taqdZo7pkagHBWM/JibZ9On/071/KaG ewiMNWTWLq9ATKZNIoYJ5YprW/8A9GT5tvjFoSxXAV28nhQuLWLLLKphaEPGJ3CS Anb1E5SQ2z2gjoPDkhQHgXYlVMQ2YyzMNiNlue+0uyWHMFh0eE/kAjAHX1s7lkHi wpUJo9CjzM+6VXANV1p8lXNrpAwFHJtPHBRJLx0OImhA54tIMbV0ca2l6koTYCA= =EUkY -----END PGP SIGNATURE-----
Received on Thursday, 9 April 2015 23:54:22 UTC