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

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:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 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?
> >>
> >>
> >>
> >>
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> >
> > iQEcBAEBAgAGBQJVGaOfAAoJECjN6+QThfjzmYsH/167vkA7bx7IkXvOkmWrfl76
> > lm3EPRKYXBSWdI1KRu2DpoLc/4sv2PQlI1bmXeqaA9n58DhqSulfppuWBK6825BY
> > SsRyNPsaZUap9p5TCQAL8lyj6frV9XM9dWh/b9Ccv7ygwQUpU4q/qOqOEYh4e8UL
> > Ah1ZDrN+0d39xfFLr4O4EdeLEEJ1OMnjAVAIGQxNI3XptNtP79UchtOan1scKfGX
> > 3YfShJZnxuZMvUdKNwFUuSAU7E0J/nSJfzavpA6n3EvTRGDaFuDrAhdAZB1X/hjz
> > ErWw+HGiQLQP+DUf0/a8g2x6NlshgYt3U2k5cpdRVgx8Hjr76w+dQLMZWHBEcPE=
> > =d+xT
> > -----END PGP SIGNATURE-----
> >
> >
> 
> -- 
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>