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

Thanks, Simon. I don't actually disagree with this -- but I'm not sure 
how we figure out what is reasonable and useful, so I'd like to see a 
discussion of that. (Maybe this is a good f2f discussion, when we have 
more time.)

I'm at a conference and yesterday was able to get a group of people 
together to talk about SHACL (and other potential solutions), and there 
were some hints of what that group sees as "reasonable." One of those 
things was the ability to have a local name ("label") for properties, 
but also to have an easy way to obtain a list of properties, names, and 
usages. But they didn't want to share things like specific UI functions 
like order, and they weren't comfortable with having those in the 
descriptions (SHACL or an application profile) that we share. Yes, one 
could create different SHACL datasets for those different functions, but 
an easier way, in the opinion of this group, would be for it to be easy 
to separate UI information from the validation and documentation 
information, so that you can make a choice in what to share without 
having to create a lot of different SHACL datasets.

I'm still at the conference but I'm hoping to develop some simple 
diagrams of what we discussed.

kc

On 11/25/15 8:52 AM, Simon Steyskal wrote:
> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>

-- 
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 08:59:10 UTC