- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Thu, 14 Jul 2016 11:44:05 +0300
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a0q-Brt=TLnDE9-Lo-u9gGPnVb42iuxXWR098tLG+nLSg@mail.gmail.com>
On Tue, Jul 12, 2016 at 6:02 AM, Holger Knublauch <holger@topquadrant.com> wrote: > Looking through the tracker tickets, many remaining tickets are rather > editorial, but the following aspects of the SHACL Core syntax are currently > unresolved. > > ISSUE-133, ISSUE-135 and ISSUE-141: sh:Shape vs. sh:constraint vs. sh:node > > The three tickets above are related, and I have seen various proposals > with individual pros and cons. > > a) Leaving as-is, i.e. representing node constraints as separate objects > via sh:constraint. > + Would mean: no further changes are needed > + Syntax is similar to sh:property, i.e. each constraint is linked to a > shape via a property > > b) As b) but renaming sh:constraint to something like sh:node > + Would make the syntax more consistent with sh:property and sh:sparql > > c) Merging sh:Shape and sh:NodeConstraint, attaching parameters such as > sh:closed directly to shape > + Better syntax to express mixed ranges (ISSUE-141) and sh:and/sh:or > (ISSUE-135) > + Arguably simpler metamodel > > I am undecided but would welcome discussion around this topic so that we > can further stabilize the language. Adopting c) would have quite some > impact on the terminology because we would drop node constraints. Such a > change should be made before another editorial swipe through the whole > document. If we don't want to go this way, we should at least have a > decision and then close the related tickets. > > Personally I am between (b) and (c) with a preference for (b). If we choose (c), i.e. write constraints directly to the shape I think it is more intuitive if we follow the approach of Peter's proposal and change NodeConstraints. We would then apply the constraints to the set of focus nodes and not to each focus node separately as we do now . e.g. here is it clear (to me at least) that the constraint applies on each node separately ex:ShapeA a sh:Shape; sh:scopeClass ex:Person ; sh:node [ sh:minCount 1; sh:nodeKind sh:IRI ; ] but here it is confusing and more intuitive to apply on the set of all persons ex:ShapeB a sh:Shape; sh:scopeClass ex:Person ; sh:minCount 1. sh:nodeKind sh:IRI . e.g. in the first example the sh:minCount makes no sense because it is applied on each node that is a person, if there is none, nothing happens. while in the second it requires at least one person in the data graph Dimitris > Other tickets in the syntax category, less urgent: > > - ISSUE-92: sh:partition vs qualifiedCount - waiting for input from Eric > and/or Iovka > - ISSUE-137: Should we add a constraint component for language tags? > - ISSUE-139: universal applicability (has little impact on core syntax, > yet impacts the metamodel/SPARQL) > - ISSUE-169: Renaming sh:scopeProperty to sh:scopeSubjectsOf > > Regards, > Holger > > > -- Dimitris Kontokostas Department of Computer Science, University of Leipzig & DBpedia Association Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu Homepage: http://aksw.org/DimitrisKontokostas Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Thursday, 14 July 2016 08:45:01 UTC