Re: Implementation feasibility

On 3/23/2015 16:55, Jose Emilio Labra Gayo wrote:
> On Mon, Mar 23, 2015 at 7:16 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     On 3/23/2015 15:34, Jose Emilio Labra Gayo wrote:
>>     What I am against is that the SHACL high-level language depends
>>     on a full SPARQL engine and that one cannot implement it without
>>     that engine. So if we add a language construct to define macros,
>>     then that language construct should not be tied to SPARQL.
>
>     You keep repeating the same incorrect claim over and over again.
>     Of course you can implement the high-level language without a full
>     SPARQL engine. Please explain why you cannot, based on my draft.
>
>
> Your current draft has dependencies on SPARQL because its semantics is 
> defined based on SPARQL.

Yes its semantics are defined in SPARQL, and you stated you are OK with 
that. But this does *not* mean that an implementation needs to use 
SPARQL. You can implement the equivalent behavior using Scala or Java IF 
statements and FOR loops. But this was explained over and over again, 
yet you don't acknowledge this fact.

>
> Furthermore, its semantics is not even fully defined in SPARQL and 
> employs extra-functions that are not defined. I that sense I think 
> Peter's approach is more and self documented than your proposal.
>
> For example, the SPARQL definition of sh:valueShape is based on 
> function "sh:hasShape" which is defined in natural language.

Incorrect. I have already (several times) explained that the sh:hasShape 
function is optional, and just one way of implementing this. The spec 
makes this clear too. Having said this, if a SPARQL processor wants to 
implement SHACL, then providing this sh:hasShape function is just 
another small addition.

>
> There are some other SPARQL dependencies like the sh:path construct 
> that must return a SPARQL path expression...so a SHACL processor will 
> need to implement SPARQL path's even to generate its reports.

Incorrect. The only SPARQL path expressions required are
- forward property links
- inverse property links
- concatenations of paths
which can easily be handled by a non-SPARQL implementation. And this is 
only to make sense of the paths in constraint violations, which is 
completely optional.

>
>     And the language construct to define macros is not part of the
>     core profile, so you don't even need to look at templates outside
>     of your Core profile.
>
>
> As I said, I want to have a SHACL high-level language that is 
> expressive enough.
>
>     Furthermore, the language construct to define macros is already
>     independent from SPARQL, so I have no idea what you are unhappy about.
>
>     http://w3c.github.io/data-shapes/shacl/#templates
>
>
> The defiinition incudes the following:
>
> "Well-defined, non-abstract templates must provide at least one 
> executable body property using sh:sparql."
>
> Is it really independent from SPARQL?

Yes it is independent from SPARQL, because your implementation does not 
need to use the sh:sparql and may instead rely on jose:subSetOfSPARQL or 
shx:javaScript or no such property and just hard-code the templates. The 
sh:sparql is there only to make sure that SHACL at least has one 
interoperable mode that works on the Full platform. And I would be open 
to negotiating this fact, because in practice I expect people to ignore 
this requirement anyway.

>
>     The resulting high-level language would become almost like SPARQL,
>     yet not be SPARQL. This is exactly what the RIF people did: if no
>     agreement can be found, let's introduce yet another intermediate
>     language and then define mappings from that language into the
>     languages that people actually use in practice. The difference is
>     that SPARQL is the established and official standard for exactly
>     those scenarios. Users like SPARQL and it is widely supported and
>     optimized by all kinds of tools. I remember Iovka stating that her
>     team used Jena to implement ShEx. Well then, why not just call
>     Jena's built in SPARQL engine, go with the mainstream and have a
>     far more powerful engine?
>
>     Why the obsession about avoiding SPARQL at all costs?
>
>
> Why are you repeating that false claim that I want to avoid SPARQL at 
> all costs? Could you tell me where I said that?

This should be obvious by anyone reading your emails. Your arguments 
against SPARQL just don't add up, IMHO at least.

>
> My point is that one thing is SPARQL and another thing is (or should 
> be) SHACL. I have already said in other threads the roles that SPARQL 
> can have with regards to SHACL, and I have said that I am not opposed 
> to most of the roles that can be used to solve those complex constraints.
>
> However, I think the SHACL language should be expressive enough to 
> handle most of the use cases without the need of an underneath SPARQL 
> engine and that the WG should not limit the appearance of third party 
> SHACL implementations that are not based on SPARQL engines.

You did not respond to my point that any sufficiently expressive 
alternative high-level language will converge towards SPARQL. You also 
did not provide any proof that you cannot implement SHACL core without 
SPARQL, based on my draft. Please provide this proof.

Holger