Re: On the inevitability of SPARQL/SPIN for SHAQL

On Sun, Mar 1, 2015 at 11:29 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

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

No that was not the reason. The reason was, and still is, that they were
described in terms of SPARQL features.

As I said, they can be solved using the extensibility mechanism which can
use SPARQL or whatever.

My XPath based solution is something that can add a lot of expressiveness
to the language without increasing too much its complexity.

Best regards, Jose Labra

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


-- 
-- Jose Labra