Re: Implementation feasibility

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

Because there is not a clear separation between the high-level language
constructs and the SPARQL definitions. My main point is that we have to
separate one from the other so we can also define the semantics by other
means.

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

But how can it be optional if the semantics of sh:valueShape is defined in
terms of it? Where is it defined that it is optional? What is the semantics
of sh:valueShape?

I am asking because I am trying to figure out the semantics of the language
constructs that you propose with Peter's and Eric's proposal and it is
difficult without having that definition.

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

It adds another dependency on an underneath SPARQL engine that I think is
not needed. However, I don't have a strong opinion on it right now, so I
will not fight against it. It was an example of some hidden SPARQL
dependencies that I found reading the spec.

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

So you are imposing a Full platform based on SPARQL.


> And I would be open to negotiating this fact, because in practice I expect
> people to ignore this requirement anyway.
>

Great.

With regards to macros, I am not opposed to have some language construct to
include them, but I would prefer it not to be hard-coded in sparql. I think
a similar result can be obtained if the executable body of the macro was a
SHACL constraint, which could itself contain a call to the extension
mechanism that allows external SPARQL definitions. I will try to provide
the details in this wiki page:

https://www.w3.org/2014/data-shapes/wiki/Shacl-language

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

Maybe you should try to re-read my emails and look for any argument against
SPARQL. You keep repeating statement that I am against SPARQL which is
false. I just want SHACL to have the best design possible. To that end, I
think it is better to identify what is the role of SPARQL with regards to
SHACL and to have a clean separation of concerns.

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

Because I don't think it will, and if it will, then the WG would do it
wrong. We are not defining SPARQL 2.0, we are defining SHACL.


> You also did not provide any proof that you cannot implement SHACL core
> without SPARQL, based on my draft. Please provide this proof.
>

I am trying to understand how it can be separated from SPARQL.

You are the one that is claiming that it can be implemented without SPARQL
so you are the one who should prove it.

At this moment I am just saying that it doesn't seem so. I keep finding
places where using SPARQL seems the only way to proceed.

The best way to prove that it can be implemented without SPARQL would be to
have a semantics definition that was independent from SPARQL and that's
what I tried to do with my Axiomatic Semantics.



>
> Holger
>
>


-- 
-- Jose Labra