Re: On the inevitability of SPARQL/SPIN for SHAQL

Personally, I feel that mixing paradigms results in design that is inelegant and problematic on many levels. This is RDF. Why bring XPath in when there are equally good and better approaches within RDF stack?

Besides RDF is still recovering from XML baggage and misunderstandings that resulted from people confusing it with its XML serialization. 

Irene

Sent from my iPhone

> On Mar 1, 2015, at 4:45 AM, Jose Emilio Labra Gayo <jelabra@gmail.com> 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
>