Re: Role of SPARQL

* Holger Knublauch <holger@topquadrant.com> [2014-11-26 10:08+1000]
> On 11/26/2014 6:26, Peter F. Patel-Schneider wrote:
> >I would say that each solution for defining semantics requires
> >work,
> 
> And each solution that does not rely on SPARQL requires work by the
> database vendors (who have implemented SPARQL already). This is an
> important factor compared to all the rather academic possibilities
> such as SWRL. I mean, seriously, who would really want to reinvent
> all the built-ins of SPARQL with yet another language?
> 
> There are now even SPARQL engines implemented in JavaScript (!)
> 
> I don't mind listing all the alternatives, but at some stage we need
> to become more pragmatic and show the wider community that we are
> trying to build a practical standard, not another ivory tower
> language.

I'm happy to be pragmatic; let's look at the cost of all of these
approaches. 

If we want to define Resource Shapes, remember that it is a recursive
language (the valueShape of a Resource Shape is in turn another
Resource Shape). There is no way to express that in SPARQL without
hand-waving "and then you call the function again here" or "and then
you embed this operation here" text.  The embedding trick doesn't work
in the general case because SPARQL can't express recursive queries,
e.g. "test that this Issue is valid and all of the Issues that
references, recursively".

If we don't want to define Resource Shapes, it would probably be
pragmatic to settle on the functionality before settling on the
definition language. Then when we've settled on the functionality,
we can have a bake-off of the various approaches.


> Holger
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Wednesday, 26 November 2014 05:58:08 UTC