- From: Irene Polikoff <irene@topquadrant.com>
- Date: Thu, 14 Apr 2016 08:42:48 -0700
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: kcoyle@kcoyle.net, public-data-shapes-wg@w3.org
True. In my experience, however, very few people are comfortable with and/or chose to put together complex class expressions via unions and intersections. A more common pattern is grouping individual restrictions by declaring a class to be a subclass if or an equivalent class of multiple separate restrictions. Sent from my iPhone > On Apr 14, 2016, at 8:34 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote: > > I don't think that anyone is arguing that the analogue of validation in OWL > works differently, in part because of a difference in the underlying semantics. > > What is illustrative, however, is the way that OWL puts together class > expressions (the analogue of shapes). There is no need in OWL for a separate > syntactic category analogous to constraints. For example, intersection takes > several class expressions and is itself a class expression, no other kind of > construct needed. Similarly, all values from takes an object property > expression and a class expression and produces a class expression. Again a > separate syntactic category like constraint (or restriction) is not needed. > > So it is not the case that OWL has a separate syntactic category for constraints. > > > peter > > >> On 04/14/2016 08:19 AM, Irene Polikoff wrote: >> I am not sure to what extent following OWL pattern matters to this discussion. Further, in OWL validations don't work as typically expected because of the OWA and, on the other hand, one could get a violation simply by declaring two classes disjoint and having an instance that is a member of both. >> >> This aside, the closest parallel is probably with OWL restrictions. Restrictions declare constraints (such as cardinality and values) and then other classes are defined as equivalent or subclass of various restrictions. In doing this, the regular classes effectively group restrictions and define a scope (what resources should be checked against the constraints) acting as a shape. >> >> This is not an apple to apple comparison with shapes and constraints because OWL and SHACL have a number of different assumptions and capabilities, but close enough. >> >> Sent from my iPhone >> >>> On Apr 14, 2016, at 7:35 AM, Karen Coyle <kcoyle@kcoyle.net> wrote: >>> >>> >>> >>>> On 4/14/16 7:11 AM, Jim Amsden wrote: >>>> I can see the potential simplicity and uniformity of merging Shape and >>>> Constraint (but in Peter's example, it would seem to make a lot more >>>> sense to use sh:cConstraint instead of sh:Shape). One possible outcome >>>> of this approach is that its fairly easy to describe constraints on a >>>> nested hierarchy or property navigation path. >>>> >>>> However, RDFS and OWL clearly distinguish classes and properties of >>>> classes, and it seems reasonable for constraints to follow that >>>> distinction. The simplification below is significant, but I don't find >>>> it that compelling or sufficiently motivating to redesign SHACL. >>> >>> As I read SHACL, both shapes and constraints are classes, so the analogy to classes and properties doesn't fit for me. In fact, Peter's solution seems to be the one that follows the pattern of classes and properties. However, I admit that I never really "got" the reason for both constraints and shapes, and have assumed that there was an implementation motivation that wasn't obvious from the "user" view. >>> >>> kc >>> >>>> >>>> Rather the appeal of the current SHACL design is that it has real >>>> implementation and usage experience in OSLC Resource Shapes, and we >>>> don't introduce the risk of new unanticipated issues resulting from a >>>> different language for which we possibly can't reuse this experience. >>>> >>>> Regarding that experience, I'm much more concerned that SHACL has no >>>> compatibility story with OSLC Resource Shapes. Given that there are >>>> significant implementations and existing products that have made >>>> investments in implementing and using Resource Shapes, it seems a >>>> prudent business (not technical) concern to address compatibility. It >>>> may be very hard to justify a business case for migrating those products >>>> to SHACL, possibly leading to barriers to its broad appeal and adoption. >>>> >>>> >>>> >>>> Jim Amsden, Senior Technical Staff Member >>>> OSLC and Linked Lifecycle Data >>>> 919-525-6575 >>>> >>>> >>>> "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote on 04/14/2016 >>>> 08:59:04 AM: >>>> >>>>> From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com> >>>>> To: kcoyle@kcoyle.net, "public-data-shapes-wg@w3.org" <public-data- >>>>> shapes-wg@w3.org> >>>>> Date: 04/14/2016 09:00 AM >>>>> Subject: Re: Shapes and/vs constraints >>>>> >>>>>> On 04/13/2016 09:22 PM, Karen Coyle wrote: >>>>>> One of the differences between the proposals put forth by Holger >>>>> and Peter is >>>>>> whether there need to be both shapes and constraints (Holger's >>>> view) or just >>>>>> shapes (Peter's). This sounds to me like an important difference, >>>> but I need >>>>>> an explanation of why 1) Holger thinks just having shapes will not >>>>> work and 2) >>>>>> why Peter thinks we do not need both. >>>>>> >>>>>> A simple, clear explanation of each point of view would be very >>>>> much appreciated. >>>>>> >>>>>> Thanks, >>>>>> kc >>>>> >>>>> The direct question is why doesn't SHACL *need* both shapes and >>>> constraints. >>>>> >>>>> The answer to this is that it is possible to unify both shapes and >>>>> constraints in several ways. Description logics (including OWL) >>>> provide one >>>>> syntax design built around restrictions on objects and their property >>>> values >>>>> that does not have a split between the analogue of shapes and >>>> constraints, >>>>> using only classes. The syntax that I put together a while ago also does >>>>> not need both shapes and constraints to capture all the expressive >>>> power of >>>>> the current core SHACL syntax. Since it is possible to unify shapes and >>>>> constraints in SHACL there is therefore no need for both of them. >>>>> >>>>> >>>>> Given that it is possible to unify shapes and constraints, why is it >>>> a good >>>>> thing to do? >>>>> >>>>> Consider a shape that validates nodes that are SHACL instances of >>>> ex:person >>>>> and either doctors or have income greater than 100,000. With split >>>> shapes >>>>> and constraints this needs several constructs just to keep the split, >>>> as in >>>>> >>>>> ex:s1 a sh:Shape ; >>>>> sh:constraint [ >>>>> a sh:NodeConstraint ; >>>>> sh:class ex:person ; >>>>> sh:or >>>>> ( [ a sh:Shape ; >>>>> sh:constraint [ >>>>> a sh:NodeConstraint ; >>>>> sh:class ex:doctor >>>>> ] >>>>> ] >>>>> [ a sh:Shape ; >>>>> sh:property >>>>> [ a sh:PropertyConsraint ; >>>>> sh:predicate ex:income ; >>>>> sh:minExclusive 100000 >>>>> ] >>>>> ] ) >>>>> ] . >>>>> >>>>> With unified shapes and constraints these extra constructs are not >>>> needed, >>>>> as in >>>>> >>>>> ex:s1 a sh:Shape ; >>>>> sh:class ex:person ; >>>>> sh:or >>>>> ( [ a sh:Shape ; >>>>> sh:class ex:doctor >>>>> ] >>>>> [ a sh:Shape ; >>>>> sh:propValues >>>>> ( ex:income >>>>> [ a sh:Shape ; >>>>> sh:minExclusive 100000 >>>>> ] >>>>> ) >>>>> ] ) . >>>>> >>>>> Not only is this shorter but it is more uniform. >>>>> >>>>> >>>>> peter >>> >>> -- >>> Karen Coyle >>> kcoyle@kcoyle.net http://kcoyle.net >>> m: 1-510-435-8234 >>> skype: kcoylenet/+1-510-984-3600 >>
Received on Thursday, 14 April 2016 15:43:23 UTC