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-----

Received on Tuesday, 31 March 2015 03:08:13 UTC