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

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

I don't believe that anyone is suggesting that there not be a high-level
language component of SHACL that insulates some users from the complexities
of SPARQL.  To insinuate otherwise is counter-productive.

peter


On 03/31/2015 07:51 AM, 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]
>> 
> 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

iQEcBAEBAgAGBQJVGypMAAoJECjN6+QThfjz9AkIAL1i7bDPKWPNp9s22XTtxA82
iDg6VttCrX5S5P0ojtBjEoLJ8ef6aTpyd9mvL7QwcCDt0JyQNhDvPB3RSUknC1GE
ix9kWkCWTQRzATlC4SH9UoBOZU9u4MZaXlBu9piWKgcdwZfq4JwrA+OlB2ErEVLv
J+NS7Yhgh08KAdLmOZHCI3IVyUk6toUzOToMQFe/gTtYu0BHO3q6Tv13OAYNZVa5
2OjB3BHJuFf9A5mIkKRfBp0hboPiaYWTVfEFxYdrpYxicmHIgcfPHgIvbVCgs54p
YgWF/hS+8QJ/QclM7LWhO+LkC1WrZgU0c5+5EU9usByvHONbS3eYO1g85x58FT8=
=FphO
-----END PGP SIGNATURE-----

Received on Tuesday, 31 March 2015 23:14:59 UTC