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

Hi!

(I'm not completely up to date with recent resolutions, so following 
statements might not be backed by the WG's current status)

> Holger, this doesn't convince me that UI functionality has to be
> integrated into SHACL.
> ...
> My view is that incorporating too many
> functions within SHACL is not the best approach.

Although I agree that trying to define the Swiss army knife of 
constraint languages by adding and adding loads of functionality might 
backfire, it's (imho) difficult to seperate (i) additional but 
"unnecessary" features (unnecessary = they would be used in domains not 
explicitly mentioned in the WG's charter/scope) from those that are 
actually (ii) reasonable and useful. Since UI related use cases are 
particularly mentioned in the charter [1] and I (as for myself) think 
that property groups especially sh:order do have some benefits, I would 
classify them as being (ii) rather than (i).

However, if we all agree that UI related use cases shouldn't be part of 
SHACL's "main application areas", then property groups might become (i).

cheers,
simon


[1] http://www.w3.org/2014/data-shapes/charter


---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2015-11-25 01:57, schrieb Karen Coyle:
> 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.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>>

Received on Wednesday, 25 November 2015 07:53:33 UTC