Re: Implementation feasibility

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