- From: Irene Polikoff <irene@topquadrant.com>
- Date: Sat, 4 Apr 2015 12:02:03 -0400
- To: "kcoyle@kcoyle.net" <kcoyle@kcoyle.net>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Karen, I think Holger's point is that "high level language" is a colloquial term that literally means higher lever than SPARQL. In that sense, any template provides a high level language to people who use the template. Saying that the user-defined templates are not high level would be counterintuitive. Saying 'SHACL Lite' instead of 'SHACL high level language', makes the distinction that we are trying to communicate much clearer (and it is shorter). SHACL Lite would, obviously, only include the built-in vocabulary. Irene Sent from my iPhone > On Apr 4, 2015, at 10:33 AM, Karen Coyle <kcoyle@kcoyle.net> wrote: > > Holger, I don't think we should be including user-defined templates in our definition of high-level language. What users do after the standard is developed is outside of the standard. We can't include those either logically nor temporally. The high level language should consist of SHACL-defined properties and classes. > > kc > >> On 4/3/15 8:28 PM, Holger Knublauch wrote: >> Arthur, >> >> note that Richard wrote "the built-in constructs of the high-level >> language" which is an important qualifier: the term "High-level >> language" to me includes not just the built-in "core elements" from the >> SHACL namespace (such as sh:datatype) but also any user-defined >> high-level elements, i.e. templates. I believe we should revert to using >> the terms "Core" or "Lite" vocabulary when we mean the built-ins. >> >> Holger >> >> >> >>> On 4/4/15 10:49 AM, Arthur Ryman wrote: >>> Richard, >>> >>> Yes, extensions should increase the vocabulary of constraints and use >>> the same syntactic pattern as the HL vocabulary. I don't see how that >>> implies that they are part of the HL vocabulary. The HL vocabulary >>> contains a fixed, predefined set of constraints. A HL processor would >>> only be expected to understand the HL vocabulary. >>> >>> -- Arthur >>> >>> On Thu, Apr 2, 2015 at 4:13 PM, Richard Cyganiak <richard@cyganiak.de> >>> wrote: >>>> Arthur, >>>> >>>>> On 2 Apr 2015, at 20:51, Arthur Ryman <arthur.ryman@gmail.com> wrote: >>>>> >>>>> My expectation is that extensions are packaged in a seamless way so >>>>> you can use them without being exposed to their implementation. >>>>> However, that is not the same as being part of the high-level >>>>> language. My view is that the high-level language is a fixed set of >>>>> constraints defined by the WG. >>>> So you are saying that things like this should be impossible? >>>> >>>> MyShape = >>>> (propertyA maxOccurs 1) >>>> OR >>>> ((propertyB maxOccurs 1) AND (propertyB meets >>>> FooExtensionConstraint)) >>>> >>>> I’d argue that seamless packaging of extension constraints would >>>> *require* that they can be used just like the built-in constructs of >>>> the high-level language. >>>> >>>> Best, >>>> Richard >>>> >>>> >>>> >>>>> -- Arthur >>>>> >>>>> On Sat, Mar 28, 2015 at 4:18 PM, RDF Data Shapes Working Group Issue >>>>> Tracker <sysbot+tracker@w3.org> wrote: >>>>>> shapes-ISSUE-27 (extensions-in-highlevel): Can extension >>>>>> constraints be used in the high-level language? [SHACL Spec] >>>>>> >>>>>> http://www.w3.org/2014/data-shapes/track/issues/27 >>>>>> >>>>>> Raised by: Richard Cyganiak >>>>>> On product: SHACL Spec >>>>>> >>>>>> It looks like SHACL will be split into two parts: >>>>>> >>>>>> 1) A high-level “Core/Lite” language consisting of things like >>>>>> cardinality constraints, datatype constraints, conjunctions and >>>>>> disjunctions >>>>>> 2) An extension mechanism that relies on embedded expressions in a >>>>>> more expressive language >>>>>> >>>>>> Do constraints defined using 2) become part of the high-level >>>>>> language, that is, can they be used in nested expressions like >>>>>> conjunctions and disjunctions? Or do they stand “outside” the >>>>>> high-level language and are directly associated with >>>>>> classes/individuals/etc? > > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 >
Received on Saturday, 4 April 2015 16:02:35 UTC