- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 21 Nov 2015 06:16:47 -0800
- To: public-data-shapes-wg@w3.org
I'm still not sure that SHACL should get into form design at this level. We need to think about a bigger picture -- adding in form design makes a SHACL description less re-usable, since not everyone will want to create the same forms. Adding form design also could diminish the value of SHACL as a statement of the constraints your data conforms to, for the purpose of informing consumers of the data. I am also concerned that not all cases would be as simple as the one given here. I would need to see more use cases than this simple one before making a decision about this. kc On 11/19/15 8:18 AM, Arthur Ryman wrote: > Seems to have minimal cost to implement and some potential benefit. > > -- Arthur > > On Thu, Nov 12, 2015 at 6:09 PM, RDF Data Shapes Working Group Issue > Tracker <sysbot+tracker@w3.org> wrote: >> shapes-ISSUE-114 (Property Groups): Should SHACL include a grouping mechanism of properties (for UI purposes) [SHACL Spec] >> >> http://www.w3.org/2014/data-shapes/track/issues/114 >> >> Raised by: Holger Knublauch >> On product: SHACL Spec >> >> If shapes are used to describe form layouts, it is in my experience a common requirement to group related properties together. Examples include "Labels and Descriptions", "Class Axioms", "(SKOS) Concept Relationships". UI builders could use such structured information to produce sections. The groups could be ordered by themselves, and properties such as sh:order could be applied to the properties within a group. >> >> A possible, minimally disruptive, design would be >> >> ex:SKOSRelationsGroup >> a sh:PropertyGroup ; >> sh:order 0 ; >> rdfs:label "Concept Relationships"@en . >> >> ex:MyShape >> a sh:Shape ; >> sh:scopeClass skos:Concept ; >> sh:property [ >> sh:predicate skos:broader ; >> sh:order 0 ; >> sh:group ex:SKOSRelationsGroup ; >> ] ; >> sh:property [ >> sh:predicate skos:narrower ; >> sh:order 1 ; >> sh:group ex:SKOSRelationsGroup ; >> ] . >> >> Any of these properties would be entirely optional, as usual. >> >> >> > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Saturday, 21 November 2015 14:17:18 UTC