Re: Implementation feasibility

On Mon, Mar 23, 2015 at 7:16 AM, Holger Knublauch <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.

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.

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.

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?

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?

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.

Regards,
> Holger
>
>


-- 
-- Jose Labra