- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 7 Mar 2016 17:45:21 -0800
- To: public-data-shapes-wg@w3.org
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 >>>>>>>> >>>>> >>> >>> >>> >> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Tuesday, 8 March 2016 01:45:43 UTC