- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 7 Mar 2016 12:19:08 -0800
- To: public-data-shapes-wg@w3.org
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 Monday, 7 March 2016 20:19:26 UTC