Re: shapes-ISSUE-25 (core/lite): What's in Core/Lite? [SHACL Spec]

Call it declarative or not, the whole premise of this WG is that SPARQL is 
too low level and something higher level is needed. So, I think we can 
agree that when people start writing SPARQL they are crossing some kind of 
threshold.

Here is how the workshop report reads: 
http://www.w3.org/2012/12/rdf-val/report 

"Constraints checking can be performed using SPARQL quite effectively, but 
SPARQL queries cannot easily be inspected and understood, either by human 
beings or by machines, to uncover the constraints that are to be 
respected."

If we throw that out we can just stop what we are doing and all go home.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


"Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote on 03/30/2015 
08:07:42 PM:

> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, public-data-shapes-wg@w3.org
> Date: 03/30/2015 08:07 PM
> Subject: Re: shapes-ISSUE-25 (core/lite): What's in Core/Lite? [SHACL 
Spec]
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I don't think that a SPARQL extension mechanism is any less declarative 
than
> any other part of SHACL. SPARQL is a query language, not a programming
> language.
> 
> peter
> 
> PS: Yes, there is an escape mechanism built into SPARQL that can be used 
to
> execute arbitrary code. I'm ignoring this wart.
> 
> 
> On 03/30/2015 05:25 PM, Arnaud Le Hors wrote:
> > The only natural boundary I see with what I would consider "core" and
> > the rest is between the declarative part from the non-declarative part
> > (a.k.a the extension mechanism with pieces of SPARQL or other
> > programming). This seems to be in line with the deliverable we have 
(the
> > split and numbering is mine, added to illustrate my point):
> > 
> > 1) An RDF vocabulary, such as Resource Shapes 2.0, for expressing 
these 
> > shapes in RDF triples, so they can be stored, queried, analyzed, and 
> > manipulated with normal RDF tools, 2) with some extensibility 
mechanism 
> > for complex use cases.
> > 
> > This in no way means to me that "the extension mechanism shoved into a 

> > dusty corner" because we need to make sure that the two can work 
> > together.
> > 
> > Can we not separate these two pieces the way HTML and JavaScript+DOM
> > are? With HTML5 one can define custom elements using Javascript and 
the
> > two co-exist gracefully. Why isn't a similar approach possible here? 
-- 
> > Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies 
- 
> > IBM Software Group
> > 
> > 
> > Karen Coyle <kcoyle@kcoyle.net> wrote on 03/30/2015 12:51:15 PM:
> > 
> >> From: Karen Coyle <kcoyle@kcoyle.net> To: 
public-data-shapes-wg@w3.org
> >>  Date: 03/30/2015 12:52 PM Subject: Re: shapes-ISSUE-25 (core/lite): 
> >> What's in Core/Lite? [SHACL Spec]
> >> 
> >> I'm not convinced that we need to define "core" as a specific set of 
> >> properties and functions separate from "not-core." It seems to me 
that
> >>  core came up primarily as a documentation suggestion: that 
> >> documentation would introduce SHACL with some properties that we
> >> assume are common to many applications, and examples of those. More
> >> complex concepts (extension) would follow after that. So rather than 
a
> >> set "core" I think what we need is a document that introduces SHACL
> >> with a logical progression, meeting the needs of the three audiences
> >> that Arthur has outlined.
> >> 
> >> kc
> >> 
> >> On 3/30/15 12:27 PM, Peter F. Patel-Schneider wrote:
> > If the extension mechanism is shoved into a dusty corner then it 
matters 
> > a lot what is in core/lite.  If, however, SHACL includes a construct
> > that can express lots of things that is truly part of SHACL, then it
> > matters a lot less what is in core/lite.   If SHACL includes a 
construct
> > to define new high-level constructs then what is in core/lite is 
pretty
> > much a matter of taste.
> > 
> > peter
> > 
> > 
> > On 03/28/2015 01:16 PM, RDF Data Shapes Working Group Issue Tracker 
> > wrote:
> >>>>> shapes-ISSUE-25 (core/lite): What's in Core/Lite? [SHACL Spec]
> >>>>> 
> >>>>> http://www.w3.org/2014/data-shapes/track/issues/25
> >>>>> 
> >>>>> Raised by: Richard Cyganiak On product: SHACL Spec
> >>>>> 
> >>>>> Assuming that SHACL includes an extension mechanism that can be 
> >>>>> used to express pretty much anything, which constructs will be
> >>>>> in the high-level Core/Lite part of the language that can be
> >>>>> used without the extension mechanism?
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>> 
> >>> 
> >> 
> >> -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net <
http://kcoyle.net/>
> >> m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
> >> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBAgAGBQJVGg9+AAoJECjN6+QThfjzqF0H/2xhCzRgHC5Zq0D6nobelYZ9
> 0qm5G4h9B48XeBgbIcUJkFfTfTNABrVBNhqq6+iUupRr1FiQkcK4nCMQGlWx8p3d
> QXyYbEmWSxP7xLgAuk1KvWj20Gfo+T7tDxZtzEWSVIi224U7kFRO6nCqiVXQNlZE
> xBTZ4qCMPfsFRxtI5fDF2bqqsGs2J2/En8zlmuwNMBnls57ybJcbG6LBizhOqRxb
> DML99/KSGJnn2yDI3DKxpKQVIV+9gezt1Ef34wp7n5h1H0Pv9E87f85gAtCXrKz5
> 1M9fupU8Y4DU5Pc9+M6RSqC3yKRvGXDGPKgor30E7ZBMUkVsR6f1kKX9pTdak9Y=
> =2CdR
> -----END PGP SIGNATURE-----
>