Re: Implementation feasibility

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



On 03/20/2015 11:10 AM, Jose Emilio Labra Gayo wrote:
> On Fri, Mar 20, 2015 at 6:52 PM, Peter F. Patel-Schneider 
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
> On 03/20/2015 10:48 AM, Jose Emilio Labra Gayo wrote:
>> On Fri, Mar 20, 2015 at 5:54 PM, Dimitris Kontokostas 
>> <kontokostas@informatik.uni-leipzig.de
> <mailto:kontokostas@informatik.uni-leipzig.de>
>> <mailto:kontokostas@informatik.uni-leipzig.de
> <mailto:kontokostas@informatik.uni-leipzig.de>>> wrote:
> 
> [...]
> 
> 
>> Holger, you only mention SPARQL based implementations...this
>> contradicts the assertion that it will be possible to have non-sparql
>> based implementations.
> 
>> At this moment, there are already some implementations that show that 
>> non-SPARQL based implementations of the core language are feasible.
> 
> Are there any correct implementations of the core language, i.e.,
> roughly what is described in
> http://w3c.github.io/data-shapes/data-shapes-primer/?
> 
> 
>> There are several implementations for ShEx, which is a similar language
>> to the one described there.

ShEx has exclusive or, the core has inclusive or.  This is a significant
difference.

> How well do they work on large RDF graphs?
> 
> 
>> It depends on what you call "large RDF graphs" and on what you call
>> "work well".

Let's say tens of millions of triples and validation times for a single
shape roughly as fast as the equivalent SPARQL query would take.

>> Some of the work has been done precisely to identify tractable subsets 
>> of the language. Much more work can be done to find better algorithms
>> and optimizations and even to define hybrid implementation that
>> leverage parts of the implementation to other tools.
> 
>> As an example, my ShExcala implementation contained a "validation by
>> endpoint" extension which allows triples that affect a node to be
>> validated on demand through an endpoint. This was an experimental
>> feature that I had no time to fully test due to other obligations. I
>> also think Eric has also been working extending his implementation in a
>> similar way.
> 
>> The WG can promote the appearance of independent implementations which
>> do not depend on SPARQL or it can prohibit them by saying that in order
>> to implement SHACL one needs a SPARQL engine.

But no one is saying that to implement the SHACL core one needs a SPARQL
engine.  If you want a full SHACL that can be implemented without the
equivalent of a SPARQL engine then you should be proposing alternative
extension mechanisms.

>> Best regards, Jose Labra

peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVDGSTAAoJECjN6+QThfjz/uQIAMP5cMJCw5ajJNSj8P/w+Cwp
lCR4SGfLRP3PIyxO7gRicm4HuI+bO4AqfEKrXgfBa5JrdwSCs7wsj/pByb5paTQV
xWhRPVnWhq2SusED5+gFHjINLSy0ZvjcOcRZrpWRPFyxUi7ASAUQCKxLayJQ2hj5
e2TcqnHtW0Xoeitfv/44EZQIE9RW2/MZ9EwVRixerGenLSP6pQ7YLC5vna2Sz3VG
yF9hamXRXgVEKeXFbRCObbWBcDEphf0RTMUR/RU8vYhz91g1icjcMIM+VhCCvNdj
Nqnj/aixpt5Cq4EcL0axZ9vu4koKidTEuuKs+N4XG+Bda6HNSm06Yh63JTO5c3Q=
=QWrJ
-----END PGP SIGNATURE-----

Received on Friday, 20 March 2015 18:19:29 UTC