Re: SHACL syntax and metamodel complexity

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.
- 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> 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
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT