Re: Implementation feasibility

On 3/21/2015 15:16, Jose Emilio Labra Gayo wrote:
>
>     >
>     >> There are several implementations for ShEx, which is a similar
>     language
>     >> to the one described there.
>
>     ShEx has exclusive or, the core has inclusive or. This is a
>     significant
>     difference.
>
>
> It has already been said that the people behind ShEx are also members 
> of this WG and that we are open to adapt the language. In the case of 
> "or" I am more in favor of having both language constructs, "sh:or" 
> for disjunction and "sh:oneOf" for exclusive or.

This reminds me that we have never voted about the inclusion of the 
sh:or/choice/OrConstraint as high-level language elements. The 
requirements only list Logical Operators

https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Logical_Operators

but these are filed under "Complex Constraints", and my own 
understanding was that I am voting for something that may in practice 
only be expressed in SPARQL or similar languages.

I see no convincing advantages of reinventing all kinds of high-level 
built-ins for things that are already covered by SPARQL. We had 
something similar in SPIN, called the SPIN RDF Syntax - an object model 
for SPARQL, where you had things like sp:not and sp:or as triples. Users 
didn't like such things because the resulting Turtle files became hard 
to edit by hand, making custom editing tools mandatory. Newer version of 
SPIN therefore allowed inserting SPARQL strings (as literals) directly. 
Furthermore, introducing Or, Not etc adds the complexity of algorithms 
and engine implementations.

So it is quite possible that sh:OrConstraint (etc) will not become part 
of the final core language.

>
> What we are discussing at this point is about the methodology of how 
> to proceed with the spec, my proposal is precisely to identify which 
> are the most interesting language constructs that can be included in 
> the SHACL high-level language.
>
> At this point I would suggest to be more inclusive than exclusive, 
> identifying the most interesting language constructs and giving them 
> names (something like the table you created and Eric's proposal) so we 
> can have an understanding of which are those constructs.

Ok, if you are serious about being more inclusive than exclusive, then 
please withdraw your objections to

https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Patterns

which are clearly needed requirements in the real world (used in the 
majority of SPARQL queries).

>
> It will be important to know how those language constructs interact 
> between each other, and then we can even discourage some features 
> whose interaction can lead to very bad performance or even 
> contradictory shapes. That's what can be done by defining of SHACL 
> profiles.

Yes, you can then exclude support for the Patterns above from the SHACL 
profile of your choice, yet blocking this expressivity for everyone else 
only because your profile doesn't support it is not helpful for the 
collaboration in this group.

Thanks
Holger