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

I believe the group will shoot itself in the foot if we continue to 
over-emphasize this threshold. What people under-appreciate is that even 
if the language and the engines support SPARQL, the majority of users 
may never be aware that they are using SPARQL: If you have a team of 10 
ontologists and just one of them can create SPARQL templates, then this 
one person is sufficient to create high-level language elements for all 
the others. The non-SPARQL people only need to "fill in the blanks" on a 
form to instantiate those SPARQL-based templates. Also, SPARQL is no 
rocket science and can be learned incrementally from examples.

What we have seen in the past, and I expect to happen with SHACL on a 
much larger scale, is that some dedicated people create SPARQL template 
libraries and share them with others. The "core" library included in the 
SHACL namespace will be just one among others. Having said this, I very 
much agree that it does make sense to explicitly define such a core 
library so that certain tools can hard-code assumptions, e.g. to drive 
user interfaces in a more intelligent way. This core library should IMHO 
be called the SHACL Lite (Profile) to make clear that this is just a 
subset of the overall language.

Regards,
Holger



On 4/1/2015 0:51, Arnaud Le Hors wrote:
> 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/><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-----
> >

Received on Tuesday, 31 March 2015 22:49:27 UTC