Re: On the inevitability of SPARQL/SPIN for SHAQL

Jose,

ok, I believe I can now better understand why you are voting against the 
requirements

https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Basic_Graph_Patterns
https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Aggregations

because XPath cannot handle them. How inconvenient... ;)

Regards,
Holger


On 3/1/15 7:45 PM, Jose Emilio Labra Gayo wrote:
> On Sun, Mar 1, 2015 at 9:56 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>
>     On 3/1/15 5:24 PM, Jose Emilio Labra Gayo wrote:
>
>         2.- To allow the core language to have XPATH like
>         functionality and variables. It can be something similar to
>         the expressions that appear in the FILTER clauses in SPARQL.
>         As an example using the compact syntax we could say:
>
>         <RectangleShape> { :weidth ?w, :height ?h, :area ?a, FILTER
>         (?w * ?h = ?a) }
>
>
>     This looks like it would simply reinvent a new SPARQL, only that
>     no existing tool would support it yet.
>
>
> No, it is leveraging on XPath which has lots of implementations and 
> tools. Maybe, the syntax can be "CONSTRAINT" instead of "FILTER" to 
> clarifiy that it is not SPARQL.
>
> <RectangleShape> { :weidth ?w, :height ?h, :area ?a, CONSTRAINT (?w * 
> ?h = ?a) }
>
> The only neede feature is to associate variables with the objects that 
> are being matched and to have a "CONSTRAINT <XPath-Expr>" that 
> evaluates to a boolean.
>
>         But generating human-readable error messages can be a
>         post-process operation. Embedding that functionality in SPARQL
>         you are preventing any implementation that is not based in SPARQL.
>
>
>     Why not?
>
>
> Because  you are embedding SPARQL in the generation of human-readable 
> messages.
>
>     If someone wants to use another language, then this would also
>     have a mechanism to create strings. JavaScript certainly has. 
>
>
> And in that way, the shapes generating human-readable messages in 
> SPARQL are not compatible with the shapes generating human-readable 
> messages in Javascript.
>
>     And even if not, the human-readable messages are purely optional
>     anyway, but preventing something that is already solved by SPARQL
>     doesn't sound like a good idea.
>
>
> Because we are using SPARQL for something that is not needed.
>
> And I emphasize, I am not against SPARQL, I am against embedding 
> SPARQL in an uncontrolled way what is supposed to be a high-level 
> language.
>
> Best regards, Labra
>
>
>     Holger
>
>
>
>
>
> -- 
> -- Jose Labra
>