Re: Role of SPARQL

Whatever language syntax is decided, some interoperable mechanism needs 
to be found to perform the actual queries against a dataset. These 
queries can be quite complex graph patterns. SPARQL is an obvious choice 
here.

Stardog ICV compiles to SPARQL. ShEx has a SPARQL mapping. Resource 
Shapes is a subset of ShEx. SPIN executes as SPARQL. RDFUnit does.

So I am wondering whether anybody disagrees on this topic at all, and 
whether we can use this opportunity to narrow down the space of open issues.

The resolution could be that we make it a requirement for any solution 
that it needs to be executable with SPARQL. This topic is separate from 
the surface syntax.

I am just trying to be pragmatic.

Thanks,
Holger



On 11/22/14, 3:23 AM, Arnaud Le Hors wrote:
> Is this something we can resolve without knowing which technology we 
> are going to use though?
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards - 
> IBM Software Group
>
>
>
>
> From: Holger Knublauch <holger@topquadrant.com>
> To: public-data-shapes-wg@w3.org
> Date: 11/20/2014 03:22 PM
> Subject: Role of SPARQL
> ------------------------------------------------------------------------
>
>
>
> I think we should raise an issue to determine the role of SPARQL in this
> stack. One of the reasons why I believe this is an important direction
> is that it will impact ISSUE-1 (inferencing). For example, see the
> unresolved feature request brought to our attention by Axel:
>
> http://www.w3.org/2009/sparql/wiki/Feature:ParameterizedInference
>
> The interaction is that if SPARQL (in general) had a syntax to specify
> entailment regimes, and Shapes are based on SPARQL, then the topic of
> inferencing may become a non-issue from a Shapes perspective - it would
> be solved in the lower parts of the stack.
>
> From what I can guess by listening to previous discussions, many people
> here are in favor of defining Shapes with SPARQL semantics, at least
> with a mapping/compilation to SPARQL, so I believe this is a topic that
> we should formally discuss and resolve.
>
> Holger
>
>
>