W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

Re: Implementation feasibility

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Sun, 22 Mar 2015 05:38:51 -0700
Message-ID: <550EB7DB.7030305@gmail.com>
To: Jose Emilio Labra Gayo <jelabra@gmail.com>
CC: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
Hash: SHA1

On 03/21/2015 10:17 PM, Jose Emilio Labra Gayo wrote:
>>>>> There are several implementations for ShEx, which is a similar 
>>>>> language to the one described there.
> [...]
>> Because you are saying that there is a significant difference between 
>> ShEx and SHACL and I say that the people behind ShEx are flexible
>> enough to adapt what has been proposed for ShEx to SHACL.
> This also does not, by itself, mean that implementations of ShEx
> demonstrate implementation feasibility of the core of SHACL.
> Of course not, how can one demonstrate without a crystal ball when SHACL
> has not been defined? My assertion was precisely that implementing ShEx
> was feasible and that if the SHACL high level language is similar it
> should also be feasible.

Similar languages can have very different implementation feasibility.  In
particular, inclusive and exclusive or can give rise to very different
implementation characteristics.  (Of course, it may be that inclusive or is
easier than the exclusive or in Shape Expressions.)  So, again, the
implementability of Shape Expressions is not direct evidence of the
implementability of the core of SHACL, unless the core of SHACL is
equivalent to a subset of some correctly implemented version of Shape

> Furthermore, all ShEx implementations that I know have been done by
> single individuals as a proof-of-concept.
>> As an example, I am more inclined to have both inclusive and exclusive 
>> or, so the user can chose which one depending on its validation needs.
> I'm not sure how adding features makes the core of SHACL more
> implementable.
> It was an example about design language flexibility, not
> implementability. At this moment we are not adding features, we are
> choosing which are the features. It is better now to put every language
> construct on the table so the WG can select which ones should or should
> not be part of the language. That's why I to propose to start designing
> the SHACL high-level language instead of imposing an implementation based
> on SPARQL.
> Best regards, Jose Labra


Version: GnuPG v1

Received on Sunday, 22 March 2015 12:39:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:18 UTC