Re: On the inevitability of SPARQL/SPIN for SHAQL

While I am a big fan of XPath (I use it all the time), I have to agree with
Irene here - treating RDF as if it were XML seems like a bad idea.

I can't help but think that there is a perception thing going on.  The
resistance to committing to SPARQL as a constraint language in favor of,
e.g., XPath, seems to stem from a feeling that SPARQL is a low-level,
implementation-specific language whereas some alternative is higher-level.

I view SPARQL as being at a much higher level than, e.g., XPath (just as I
view RDF as being at a higher level than XML).  In RDF, we talk about how
our resources relate to one another - not how a document (or a table, or a
spreadsheet, or etc.) happens to structure that relationship.   XPath is a
high-level language for navigating a very particular structure; if you
change the structure, your XPath is at risk (and many of the features of
XPath are there to help you make an XPath expression immune to certain
changes in structure).   SPARQL is a language for navigating data graphs,
regardless of how they are represented in a document.


I think this is the source of a lot of the "XML Confusion" that Irene
mentions in her message.  Those of us who are RDF fans can't help but be
puzzled by any language proposal that, in our view, makes lower-level
commitments in the shapes language.


I suspect that there are others for whom SPARQL seems like the low-level
language.  I can't represent this viewpoint as well since I don't myself
hold it.  But if this is the view one is coming from, then committing to
SPARQL would seem like a low-level commitment.

and I think we are agreed that we expect Shapes to develop a high-level
language.  We just don't agree on where the levels are.




Dean


On Sun, Mar 1, 2015 at 6:19 AM, Irene Polikoff <irene@topquadrant.com>
wrote:

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