Re: proposal for issue-211

Hi Dimitris,

Are we removing something and adding something else? Are we just adding or just removing? Or is it still to be decided?

I am literally asking what the change entails.

I know you gave an example of 

>>> ex:S1 a sh:Shape ;
>>>   sh:targetClass ex:Person;
>>>   sh:property [
>>>     sh:predicate ex:name ;
>>>     sh:minCount 1 .
>>>   ]
>>> 
>>> could be also written as 
>>> 
>>> ex:S1 a sh:Shape ;
>>>   sh:targetClass ex:Person;
>>>   sh:predicate ex:name ;
>>>   sh:minCount 1 .


But this is neither here nor there for me since I do not anticipate my users interested in such shapes. I want to se an example showing if anything will change for the shapes that describe constraints for different properties.

You also said the meta model will be simplified. In which way? Which we still talk about shapes and constraints or not? Or will we talk about shapes and property shapes? Or something else?

Is it just me who doesn’t know what this change specifically entails? I see that Karen already said she supported it. I don’t know if I do or if I don’t because I don’t know what it is. Is this change described in detail anywhere?

Irene

> On Dec 7, 2016, at 3:05 PM, Irene Polikoff <irene@topquadrant.com> wrote:
> 
> Dimitris,
> 
> What does this practically mean? 
> 
> 100% percent of our users 90+% percent of the time will describe shapes with constraints on multiple properties. Thus, shapes that only support a description of a single property constraint are of no practical interest to them and to address their needs, the language has to makes it easy to write and understand shapes that define conditions for multiple properties.
> 
> I suppose if there is no effect on the existing syntax, these requirements are addressed. But then, what problem are we solving? How does adding another way to say the same thing simplifies something?
> 
>> On Dec 7, 2016, at 4:06 AM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de <mailto:kontokostas@informatik.uni-leipzig.de>> wrote:
>> 
>> here's the motivation behind this proposal
>> It makes shacl more flexible and simplifies the language and the metamodel a lot with minimal changes in the current syntax and no effect on shacl full
>> it removes any corner cases  / grey areas that have been pointed out in the past and we are patching / extending definitions to cover
>> It makes it much easier to explain and define SHACL. 
>> 
>> Even though this requires to rewrite some parts of the spec, I believe it will take us faster to CR
>> 
>> (attaching this to another issue is fine by me)
>> 
>> 
>> On Wed, Dec 7, 2016 at 10:25 AM, Holger Knublauch <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>> Could you summarize what motivates this change? The "issue" mentioned in the email that you quote below is irrelevant. Users will *not* write such shapes. What is broken with the current design?
>> 
>> Holger
>> 
>> 
>> 
>> On 7/12/2016 17:38, Dimitris Kontokostas wrote:
>>> After a lot of thought, I would like to propose a change in shacl to close this issue.
>>> 
>>> the change is a slight variation of Peter's proposal option #2 from this email
>>> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0053.html <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0053.html>
>>> 
>>> The variation adds the notion of sh:PropertyShape as a subClass of sh:Shape.
>>> This makes it easier to define some annotation properties like sh:label that make sense on properties only and gives us the option to keep sh:property in the language if we want to.
>>> 
>>> if we decide to keep sh:property, it will become a constraint like sh:shape but it will make all our existing syntax valid and with the exact same behaviour.
>>> So this approach will have no effect on the existing syntax but will also regularise the language and enable some new shorter forms of shapes e.g.
>>> 
>>> ex:S1 a sh:Shape ;
>>>   sh:targetClass ex:Person;
>>>   sh:property [
>>>     sh:predicate ex:name ;
>>>     sh:minCount 1 .
>>>   ]
>>> 
>>> could be also written as 
>>> 
>>> ex:S1 a sh:Shape ;
>>>   sh:targetClass ex:Person;
>>>   sh:predicate ex:name ;
>>>   sh:minCount 1 .
>>> 
>>> if we decide to drop sh:property we would use sh:shape instead and reduce the alternate ways we can define the same thing.
>>> 
>>> I also checked this offline with Peter and he is willing to help us get the new terminology right should we decide to go this way
>>> 
>>> Best,
>>> Dimitris
>>> 
>>> -- 
>>> Dimitris Kontokostas
>>> Department of Computer Science, University of Leipzig & DBpedia Association
>>> Projects: http://dbpedia.org <http://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>, http://aligned-project.eu <http://aligned-project.eu/>
>>> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
>>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig & DBpedia Association
>> Projects: http://dbpedia.org <http://dbpedia.org/>, http://rdfunit.aksw.org <http://rdfunit.aksw.org/>, http://aligned-project.eu <http://aligned-project.eu/>
>> Homepage: http://aksw.org/DimitrisKontokostas <http://aksw.org/DimitrisKontokostas>
>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT <http://aksw.org/Groups/KILT>
>> 
>