Re: [SHAQL Feedback] SPARQL & definition/result coupling

On Fri, Feb 27, 2015 at 12:20 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

>
> On 2/27/15 6:13 PM, Dimitris Kontokostas wrote:
>
>> Hi Holger, all
>>
>> First of all I think the spec is going to a good direction, it needs some
>> work to be coherent but this was expected for such a limited time.
>>
>> As you suggested I summarize and continue our offline discussion in the
>> mailing list for public review.
>>
>> I also want the SPARQL expressiveness in the spec but IMHO if we keep it
>> uncontrolled it can be messy.
>> My (revised based on your comments) suggestion is to allow *only* SELECT
>> queries where the select variables are limited to the ones defined in the
>> end of section 15.1.3 [1] (?root/?this, ?level, ?message, ?predicate,
>> ?value) or any other variable is explicitly defined in the spec . An
>> additional requirement is that the variable ?root (or ?this on focus node
>> queries) is required and the query is marked as invalid if it does not
>> exist.
>>
>> Depending on what results the user wants to get the SHAQL engine can
>> convert this query to
>> - ASK -> true / false
>> - SELECT COUNT(DISTINCT ?root) -> violation counts
>> - SELECT DISTINCT ?root -> get erroneous nodes
>> - SELECT DISTINCT ?root ?label [...] -> nodes with additional metadata
>> - CONSTRUCT { ... } -> custom
>> and then programatically create the results.
>> If people want additional metadata they can be easily added with shapes
>> annotations. This is something that is already working well in RDFUnit [2]
>> and could be adapted for SHAQL.
>>
>> The reason why we *should not* allow CONSTRUCT queries is the very strong
>> coupling of constraint definition with validation results.
>> At first, construct queries cannot easily be transformed to all the above
>> forms and we limit SHAQL reporting expressiveness.
>> But, the most important part is that we hardcode the results in the shape
>> and this provides very little flexibility on the result representation and
>> hard to change when/if the spec changes.
>> In addition construct queries limit the results to blank nodes that some
>> people don't like.
>> Finally, when there are multiple violation values (sh:value) CONSTRUCT
>> creates a separate violation for each value whereas in RDFUnit I use a
>> - SELECT ?root ?value {...} ORDER BY ?root
>> and manually place all values (or any other defined annotations) in the
>> same violation
>>
>> I would also discourage the use of ASK queries to make the spec shorter
>> and more consistent. People can easily write a SELECT ?root/?this instead
>> with all the expressive benefits this brings.
>>
>
> Thanks, I am always in favor of simplifications. I believe I agree that
> ASK should be deleted - now that we have SELECT (which did not exist in the
> original SPIN spec). ASK was confusing to many people because it wasn't
> intuitive that they had to return false to indicate OK. With SELECT it will
> be clearer that the result set rows are becoming violation reports.
>
> On the other aspects, I need to play with how this would look and work in
> detail before I can respond. My current intuition tells me that we are
> losing some other flexibility if we drop CONSTRUCT support, e.g. the
> ability to return additional information such as custom properties of
> constraint violations and greater ease of constructing path structures as
> objects.
>
> BTW it is not correct that CONSTRUCT would be limited to blank nodes, you
> can have something like BIND(UUID() AS ?error) in the WHERE clause and then
> use that new variable.
>

Then the problem comes when one combines different shapes where one
construct uses blank nodes, another 'BIND(UUID() AS ?error)' and other
simple SELECT statements


> Many thanks, let's stay in touch on this matter


I agree to keep this open and investigate further on the available options

Best,
Dimitris


>
> Holger
>
>
>


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