Re: SHACL syntax and metamodel complexity

I didn't say that there were no differences in expressivity.  I proposed
adding paths, for example.  (I don't know if paths are worth the extra
complexity, however.  I put them in partly to see how complex they are.)
The initial version that I put together only concerned the core of SHACL.
The second version provided a metamodel for templates and functions

I believe that I have covered all the expressive power of the core of SHACL,
except that I accidentally left out sh:hasValue and sh:in.  Adding these two
in was trivial. I also put in a too-strong restriction on the parts of
constraint components that expect classes, properties, or datatypes, which I
have since removed.

The version that I sent out is missing some parts of the SHACL extension,
notably derived properties.  My goal was to address the core of SHACL, so this
part has not received the same attention.  I have a revised metamodel for the
extension, but I am still refining it in places.

However, the reason I started looking at syntax was not to change the
expressive power, it was to see if the metamodel could be simplified.

peter


On 03/07/2016 05:45 PM, Karen Coyle wrote:
> 
> 
> On 3/7/16 2:58 PM, Holger Knublauch wrote:
>> Peter's proposal does not have the same functionality and is not simpler
>> or easier to learn. Neither would simplicity necessarily be an argument
>> to prefer it. There are good reasons why the current draft and proposal
>> 3 have their structure.
> 
> I asked earlier if there were differences in functionality. Peter said no; you
> now say yes. If there are, then I think we need to enumerate them. It's not
> enough to just Y/N with nothing further.
> 
> kc
> 
>>
>> As an analogy, take the difference between a "simple" weakly-typed
>> language (e.g. JavaScript) and a "complex" strongly-typed language (e.g.
>> Java). Some developers prefer JavaScript, others Java. The difference is
>> that the more structured languages (like Java) allow for additional
>> support at edit time, compile time and static analysis, and typically
>> lead to more maintainable code in the long term. If SHACL is supposed to
>> support data longevity, then I'd certainly prefer a more structured
>> approach.
>>
>> Holger
>>
>>
>> On 8/03/2016 6:19, Karen Coyle wrote:
>>> If Peter's proposal has the same or similar functionality but is
>>> simpler and easier to learn, then that is enough to make it
>>> preferable. If we hope that SHACL will be widely used, even by
>>> developers with minimal technical acumen, then we must aim for
>>> simplicity. Fewer constructs, if they can be combined to create the
>>> necessary functionality, is better, IMO, than many specific
>>> properties. We should follow the "principle of least effort." [1]
>>>
>>> kc
>>> [1] Zipf, George K. Human Behavior and the Principle of Least Effort:
>>> An Introduction to Human Ecology. Cambridge, Mass: Addison-Wesley
>>> Press, 1949
>>>
>>> On 3/6/16 8:04 PM, Holger Knublauch wrote:
>>>>  From what I have seen so far, your alternative proposal has at least as
>>>> many irregularities and constructs as the current drafts, while
>>>> introducing many new problems. I will send a list of problems that I
>>>> have already found at some stage. Many of these design decisions are
>>>> basically a matter of taste and of a different world-view.
>>>>
>>>> I believe as long there is no list of real ISSUEs that you are trying to
>>>> solve here, all this looks like a solution in search of a problem.
>>>>
>>>> Holger
>>>>
>>>>
>>>> On 7/03/2016 13:21, Peter F. Patel-Schneider wrote:
>>>>> I don't see this as a radical change.  A radical change would scrap
>>>>> most of
>>>>> the syntax and require non-local changes to shapes and constraints.
>>>>>
>>>>> What is broken in the current syntax is that there are too many
>>>>> constructs and
>>>>> too many irregularities.  Refactoring results in fewer constructs and
>>>>> more
>>>>> regularity.  This will result in a language that is easier to use.
>>>>>
>>>>> peter
>>>>>
>>>>>
>>>>> On 03/06/2016 06:24 PM, Holger Knublauch wrote:
>>>>>> Peter,
>>>>>>
>>>>>> I understand this is largely just a sketch and you may be "thinking
>>>>>> out loud".
>>>>>> Yet I don't have sufficient information on how all this is supposed
>>>>>> to work,
>>>>>> e.g. with SPARQL generation. It would help if you could provide some
>>>>>> examples
>>>>>> of how this vocabulary would be used to define some built-in and
>>>>>> extension
>>>>>> constraint types. On
>>>>>>
>>>>>> https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_3
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am presenting snippets illustrating the definitions of
>>>>>> ex:LanguageConstraintType, sh:PatternConstraintType and
>>>>>> sh:ClassConstraintType. Would you mind creating similar examples in
>>>>>> your
>>>>>> metamodel?
>>>>>>
>>>>>> Furthermore, I am unclear what problem you are trying to solve. What
>>>>>> is broken
>>>>>> in the current SHACL syntax that motivates your (radical) changes?
>>>>>> Have any
>>>>>> users complained or are there any related ISSUEs recorded? Of course
>>>>>> we can
>>>>>> come up with any number of syntaxes for SHACL and I could certainly
>>>>>> make up
>>>>>> plenty of variations, too.
>>>>>>
>>>>>> Thanks,
>>>>>> Holger
>>>>>>
>>>>>>
>>>>>> On 5/03/2016 13:32, Peter F. Patel-Schneider wrote:
>>>>>>> I fixed up some silly syntax errors and added prefix
>>>>>>> declarations.  The
>>>>>>> attached file looks OK to the syntax checker I grabbed.
>>>>>>>
>>>>>>> peter
>>>>>>>
>>>>>>>
>>>>>>> On 03/04/2016 04:29 PM, Holger Knublauch wrote:
>>>>>>>> Turtle file doesn't parse. Could you fix this?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Holger
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/03/2016 10:17, Peter F. Patel-Schneider wrote:
>>>>>>>>> On 03/03/2016 04:20 PM, Holger Knublauch wrote:
>>>>>>>>>> If you want this to be
>>>>>>>>>> seriously considered, please work out the details, including
>>>>>>>>>> Turtle files
>>>>>>>>>> etc.
>>>>>>>>>> Holger
>>>>>>>>> OK, since you asked so nicely, see the two attached files.
>>>>>>>>>
>>>>>>>>> peter
>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

Received on Tuesday, 8 March 2016 02:34:57 UTC