Re: On the inevitability of SPARQL/SPIN for SHAQL

On Tue, Mar 3, 2015 at 8:51 AM, Jose Emilio Labra Gayo <jelabra@gmail.com>
wrote:

> On Tue, Mar 3, 2015 at 6:40 AM, Holger Knublauch <holger@topquadrant.com>
> wrote:
>
>>  On 3/3/2015 15:30, Jose Emilio Labra Gayo wrote:
>>
>>  On Tue, Mar 3, 2015 at 6:11 AM, Holger Knublauch <holger@topquadrant.com
>> > wrote:
>>
>>>  On 3/3/2015 14:59, Jose Emilio Labra Gayo wrote:
>>>
>>>
>>>
>>>> Why should this group take on such undertaking instead of reusing
>>>> already existing language produced by W3C?
>>>>
>>>
>>>  Because "SPARQL queries cannot easily be inspected and understood,
>>> either by human beings or by machines, to uncover the constraints that are
>>> to be respected". [1]
>>>
>>>
>>>  Jose, the sentence following your excerpt above is
>>>
>>> "The term 'shape' emerged as a popular label for these constraints."
>>>
>>> I believe this clarifies that the group was not contrasting SPARQL with
>>> something like XPath,
>>>
>>
>>  Not at all...why do you say that?
>>
>>
>> Because you were responding to Irene's question that was comparing SPARQL
>> with your XPath variant. The quote that you used to defend your view point
>> was about something else.
>>
>
> I understood Irene's question as why we should not use SPARQL and when I
> started to write my answer I noticed that it was already written.
>
>> I think I have already clarified what subset of XPath I was talking about
>> and for what purpose.
>>
>>
>>> but rather SPARQL versus the high-level vocabulary of sh:minCount and
>>> sh:valueType. A new language such as a yet-to-be-defined variant of XPath
>>> or a yet-to-be-defined subset of SPARQL's FILTER expressions would arguably
>>> have the same basic characteristics as SPARQL itself.
>>>
>>
>>  No, because that subset of XPath (or SPARQL expressions as Richard
>> said) can be used for built-in functions and operations and has a much
>> simpler semantics that we can leverage on than the full SPARQL language
>> with BGPs, UNIONs, OPTIONALs, etc.
>>
>>
>> SPARQL expressions include EXISTS and NOT EXISTS [1], i.e. you would need
>> to define a sub-set of SPARQL expressions here to avoid the features you
>> describe.
>>
>> Sorry, I am not seeing any realistic support for defining such a new
>> language for SHACL. It would exclude too many real-world use cases. Your
>> goal of "simple semantics" has not been approved, and I don't believe it
>> should be approved because it limits the usefulness of the language. As
>> Richard stated, such a reduced language would fail on the marketplace.
>>
>
> In my opinion that will depend on which language will result. I think most
> of the use cases can be captured by a high level declarative language that
> people can easily understand.
>
> The remaining complex use cases can be done with the extensibility
> mechanism that has already been proposed and that is similar to what you
> are proposing. And I have already said that I support it.
>

Hi Jose, all

I am trying to understand the problem then. I believe everyone agrees that
we will additionally define a core language or a limited shacl profile that
will be formalized independent of SPARQL. Weather we name it core language
or limited profile we will define all language constructs that can be
defined independent of SPARQL that everyone in this WG agrees to.
In this regard we could possibly propose sh:xpathFilter rdfs:subPropertyOf
sh:sparqlFilter that could limit the expressiveness of the sh:sparqlFilter
to XPath functions only (but compatible with sh:sparqlFilter).

If all this is about the naming (core/limited) maybe we could vote on this.
Regarding the definition, if we try to formalize the full shacl semantics
(along with the extension mechanisms) it would be very hard without SPARQL.
Thus, I would rather use SPARQL as much as possible and re-formalize only
the core/limited profile part.

Best,
Dimitris


>
> There are some use cases that involve arithmetic expressions and string
> comparisons that could be handled with the "SPARQL expressions"
> subset...but if there is no consensus on that, those use cases could be
> solved with the extensibility mechanism.
>
> I think the main difference between your proposal and mine is that I
> prefer to define a set of high-level constructs and an abstract grammar for
> those that can have a well defined semantics and can be used in a safe and
> compatible way by ShACL users, while you prefer to have a minimal
> "template" construct which is quite flexible because you can put there
> whatever SPARQL definition you want.
>
> Of course, you proposal is more flexible and offers greater expressivity,
> but it also has a lot of risks.
>
> It reminds me to the history of programming languages. You can have much
> more expressivity if you work in a low level language like Assembler...you
> may add macros to assembler so it looks better, but you are still tied to a
> particular architecture and you lose compatibility. The other alternative
> is to try to define a high level language with a predefined set of well
> defined constructs...and maybe some extensibility mechanism were you can
> call assembler...but trying to have well-defined boundaries between the
> high-level and low-level language offers a lot of advantages that you lose
> if you remain in the low-level field.
>
> Best regards, Jose Labra
>
>
>> Holger
>>
>> [1] http://www.w3.org/TR/sparql11-query/#func-filter-exists
>>
>
>
>
> --
> -- Jose Labra
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas