Re: SHACL syntax and metamodel complexity

On 03/07/2016 07:00 PM, Holger Knublauch wrote:
> 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.

Yup, I had missed that on my first pass through the extension features.

The metamodel thus needs a property for this, like

sh:scopeSPARQL        a rdf:Property ; rdfs:domain sh:Shape; rdfs:range xs:string

Also missing was derived properties.  That's a bit trickier to get right - the
simple approach (putting the code in-line) isn't appealing.

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

Huh?  SPARQL generation is part of this task?  This is syntax and metamodel
(and informal semantics).

> (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)).

It would be possible to put these properties into shapes.  I had thought about
that, but I didn't like the idea that one property changed the meaning of the
rest of the constructs in the shape.

> Holger

peter

> 
> 
> 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 04:04:21 UTC