Re: Implementation feasibility

On Mar 21, 2015 11:04 PM, "Jose Emilio Labra Gayo" <jelabra@gmail.com>
wrote:
>>>>
>>>> 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.

FYI, RDFUnit was implemented by a single person on my free time as well.

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

Maybe some one needs to reconfirm but by looking at the minutes,  'as much
as possible' in this resolution meant everything except the recursion part.

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