Re: SHACL syntax and metamodel complexity

Dimitris,

On 8/03/2016 1:44, Dimitris Kontokostas wrote:
> Hi Peter,
>
> one thing that definitely needs to change in your proposal is the 
> names of sh:fillers and sh:filter :) my eyes hurt when trying to 
> distinguish between the two.
>
> From a superficial look at your proposal
> I find the current syntax, in particular the sh:property / 
> sh:inverseProperty quite intuitive to write & read for the end user 
> while yours is very verbose and hard to get from the first look.
> if we move to sh:constraint both syntax look quite similar in terms of 
> complexity but yours has the advantage that is consistent.
>
> sh:constraint in the current spec is quite overloaded and contains 
> direct sparql queries, nested shapes with and/or/not as well as node 
> constraints.
> From a user point of view I would try to further simplify 
> sh:constraint than to complicate sh:property / sh:inverseProperty.
> This could keep the metamodel complexity at high levels but then again 
> the metamodel is meant for the implementers and very few users.
>
> if we want to target end-user simplicity, my high level take on 
> sh:constraint would be to split its responsibiities:
> - node constraints could move to sh:allProperties and we end up with 
> something like sh:property / sh:inverseProperty / sh:allProperties ( / 
> sh:allInverseProperties??)
> - use a different property to define sparql constraints. I would use 
> sh:sparqlConstraint [...] directly but if people want to reserve room 
> for js, sh:nativeConstraint is fine as well. This would be attached to 
> sh:property / sh:inverseProperty / sh:allProperties only.

I think this is a more constructive discussion than Peter's 
"replace-all" approach. I would encourage you to raise ISSUEs on such 
incremental improvements, that are well-motivated and that we can tackle 
one-by-one. There are all kinds of syntactic sugars possible to make the 
syntax clearer.

Holger


> - for the nested shapes with sh:and/or/not I do not have a clear idea 
> but nesting them with something like sh:nested would be an easy option
>
> as a sidenote, If we keep the existential constraints only to 
> sh:minCount / sh:maxCount (ISSUE-129) , all metamodel definitions 
> would be sufficiently defined with a NodeValidationFunction (ASK 
> query). There might be some edge cases (Holger can probably tell them 
> easily) where this is not sufficient but if we can ignore those we 
> have an opportunity for a great metamodel simplification.
>
> I also haven't talked about the qualified cardinality / shapes as I 
> haven't looked into that part much yet
>
> Best,
> Dimitris
>
>
>
> On Sat, Mar 5, 2016 at 2:17 AM, Peter F. Patel-Schneider 
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>
>     On 03/03/2016 04:20 PM, Holger Knublauch wrote:
>     > If you want this to be
>     > seriously considered, please work out the details, including
>     Turtle files etc.
>
>     > Holger
>
>     OK, since you asked so nicely, see the two attached files.
>
>     peter
>
>
>
>
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia 
> Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org, 
> http://http://aligned-project.eu <http://aligned-project.eu/>
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>