Re: shapes-ISSUE-114 (Property Groups): Should SHACL include a grouping mechanism of properties (for UI purposes) [SHACL Spec]

I can give you an example that a customer requested. They want to 
produce multiple views on the same data, and return different tree 
structures depending on the input of a web service call. Since Shapes 
can be decoupled from the actual ontologies, this should be fine. They 
could for example define a shape that has the only purpose of 
enumerating the properties to return. When you create a Shape, you 
neither have to share it with anyone else, nor does it need to be reusable.

HTH
Holger


On 11/21/2015 9:16, Karen Coyle wrote:
> 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.
>>>
>>>
>>>
>>
>>
>

Received on Saturday, 21 November 2015 14:28:35 UTC