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

Holger, this doesn't convince me that UI functionality has to be 
integrated into SHACL. Clearly one wants to support different views 
based on user and application needs. In fact, this is what DCMI calls 
"application profiles." There are many different functions that one 
might apply to a set of data. That doesn't mean that all of those 
functions should be in SHACL. I think that there are good reasons that 
much of the web has a "layer cake" structure, with different functions 
occupying different layers rather than trying to define an "all things 
to all people" technology. My view is that incorporating too many 
functions within SHACL is not the best approach.

kc

On 11/21/15 3:28 PM, Holger Knublauch wrote:
> 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.
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 25 November 2015 00:57:42 UTC