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

Re: Implementation feasibility

From: Jose Emilio Labra Gayo <jelabra@gmail.com>
Date: Sat, 21 Mar 2015 22:04:25 +0100
Message-ID: <CAJadXXJuWz9YdQ6Rpi7aNvWY0rbx_hRZxCjbOVNZpCnc=KDJ=Q@mail.gmail.com>
To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
>
> Yes, DBPedia is a very good use case. But precisely for that, I think we
>>> should try to have a solution that doesn't depend on SPARQL and where SHACL
>>> processors can be optimized for that kind of data.
>>>
>>
>> If SHACL implementations need to be based on SPARQL, then it will be very
>> difficult to optimize SHACL processors given SPARQL's own complexity. While
>> if we are able to define a SHACL high-level language with a set of
>> constructs that can be implemented without SPARQL, then we are promoting
>> the appearance of third party implementations that can be optimized to
>> handle those problems.
>>
>
> The problem  is that we need solutions that work reliable and fast for
> existing systems. We should not be based on what might or might not be
> achieved in the future.
> There was a recent validation I performed for a paper, can you provide a
> time estimate for a ShEx validation on the following setting using your
> laptop?
> Validate 4M instances from a 62M triple RDF dataset against ~1,500 class
> shapes with ~9,500 facets.
>

Surely not. My ShEx implementation (which was done by a single person in my
free time) was not optimized and was not intended for that kind of
problems...but I don't think that fact invalidates my previous argument
that allowing SPARQL free implementations of SHACL or some subsets of SHACL
some teams could not obtain better results.


> There was a WG decision on the F2F meeting to base the semantics on
> SPARQL, you did not object then but you seem to object now.
> http://www.w3.org/2015/02/18-shapes-minutes.html#resolution02
>

The resolution was: "Define semantics using SPARQL as much as possible" and
I agree with that. I have said in several threads that I have no problem to
define mappings from the language constructs to SPARQL definitions. My
objection is to have SHACL tied to SPARQL in such a way that we prohibit
third parties to implement SHACL without a full SPARQL engine.

Personally I have no problem in defining the semantics of the high level
> vocabulary without SPARQL
>

Right, so we agree there.


> but I would be very concerned if SHACL did not have a native support for
> SPARQL.
>

And we probably agree there. Native support for SPARQL can also be obtained
using the extensibility mechanism that I was saying in my other email.

Best regards, Jose Labra
Received on Saturday, 21 March 2015 21:05:16 UTC

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