Re: SHACL syntax and metamodel complexity

Among other details, your design has also deleted the custom scopes, e.g.

     https://www.w3.org/TR/shacl/#sparql-scopes

instead using various new properties for only the hard-coded scopes. If 
that's what you are proposing then you may want to open a ticket for 
this and we can discuss this individually.

There are also lots of unknowns with the SPARQL generation, and once you 
have provided details I can send a full list of issues.

(And no, I don't think paths are worth the effort - they make the whole 
structure very unpredictable. Once you have deleted paths, there is no 
reason not to use simple properties such as sh:predicate (or 
sh:inversePredicate)).

Holger


On 8/03/2016 12:34, Peter F. Patel-Schneider wrote:
> 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 03:00:50 UTC