Re: Implementation feasibility

> On Mar 23, 2015, at 2:55 AM, Jose Emilio Labra Gayo <jelabra@gmail.com> wrote:
> 
>> 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. 
> 

Yes, and there is a working group resolution:

 http://www.w3.org/2015/02/18-shapes-minutes.html#resolution02
"Define semantics using SPARQL as much as possible" 

Thus, the spec is exactly in accordance with the resolution. What is the basis of your objections?

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

How is the spec limiting the appearance of the third party implementations that are not based on SPARQL engines?

There are no implementation requirements in the spec. In fact, it says in several places that there can be all sorts of implementations.


>> Regards,
>> Holger
> 
> 
> 
> -- 
> -- Jose Labra
>