Re: reworded requirements for section 3 Complex Constraints

Hi Eric,

I suggest we give Peter a chance to edit your version of the 
requirements to withdraw his objections. Then we can (as a group) look 
at what you guys have produced. It's certainly not only up to me to 
decide this.

To me, much of the changes in wording will be OK if we can agree on a 
resolution to the classes/shapes question, and I had just sent a 
proposal to resolve that (ldom:ShapeSelector) that will hopefully work 
for everyone!

On the extension mechanism, yes I agree we should put this on the list 
of requirements, but it should be separate from the complex constraints 
topic. Our extension mechanism may be very brief in the first version of 
the spec, and basically say that properties similar to ldom:sparql can 
be used for other languages.

The critical bit though is that we require SPARQL to be a built-in 
(well-defined) extension in the official spec. This does not mean that 
all implementers need to support it in full, but that we can produce

- a self-contained language where the templates are backed by SPARQL queries
- an expressive language that actually covers all Complex Constraint 
requirements

I am perfectly happy to see extensions for JavaScript etc in the future, 
but SPARQL is well-established and there is no reason not to cast it 
into stone already. This has been done in SPIN for many years, and users 
are happy with this.

Holger


On 2/11/2015 5:46, Eric Prud'hommeaux wrote:
> * Holger Knublauch <holger@topquadrant.com> [2015-02-07 10:29+1000]
>> On 2/6/15 5:57 PM, Eric Prud'hommeaux wrote:
>>> Again, with Holger's approval, I'll make these changes.
>> I believe the main driver for all these changes was to react to
>> Peter's objections. So I suggest you keep working on your branch
>> until Peter is satisfied and then the rest of the group checks
>> whether this compromise is still acceptable to them.
> Apart from the one that I interpreted as being about extensibility, I
> think Peter and I are content with my proposed wording. Can you give
> feedback on the first req, which I interpreted as being about
> extensibility and Peter interpreted as being about core expressivity.
>
>
> -The language should allow users to implement constraints that check
> complex conditions, with an expressivity as covered by the following
> sub-requirements (e.g. basic graph patterns, string and mathematical
> operations and comparison of multiple values).
>
> +==== Constraint Extensions ====
> + +Shapes will have a defined extension mechanism enabling other
> languages to provide supplementary constraints, (e.g.  basic graph
> patterns, string and mathematical operations and comparison of
> multiple values).
>
>
>
>> Holger
>>
>>

Received on Wednesday, 11 February 2015 00:10:08 UTC