Re: SHACL Compact Syntax, was Re: Fwd: Transition Request: 3 FPWGNOTE documents

> On May 29, 2017, at 9:31 AM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:


> 
> 
>> / {}  # this is a nested node shape
>>   / -> ex:fooShape  . # reference
>>   / nodeKind=sh:IRI  # put all constraints inline and end with a '.'
>>   /ex:parent {}  # this is a property shape, path is provided, 
>>   /ex:parent -> ex:fooShape2  # reference
>>   ^ex:child nodeKind=IRI [2..2] . # put all constraints inline and end with a '.'
>> }
>> 
>> where inline definitions could have more limited expressivity than nested ones {}
>> 
>> Also the example in the document is confusing e.g.
>>  ex:ssn       xsd:string [0..1] pattern="^\\d{3}-\\d{2}-\\d{4}$" .
>>  ex:worksFor  IRI ex:Company [0..*] .
>> 
>> is there a specific order in which people are supposed to put constraints?
>> how would the parser know how to correctly  treat xsd:string / ex:Company as datatype and class respectively?
>> e.g what would the following produce?
>>  ex:ssn       xsd:string .
>>  ex:worksFor  ex:Company .
> 

For some constraint components there is a requirement to say

property=value  such as 


pattern="^\\d{3}-\\d{2}-\\d{4}

or 

maxLength=5 

But some are “elevated” so that they do not require a property name before them. This includes cardinality i.e., we do not say:

minCount=2 maxCount=2 and, instead, say:

[2..2]

There is a parseable syntax here which allows for more compactness.

The same is true for nodeKind, class and datatype.

We could say

nodeKind=IRI, as you are suggesting, but why?

It seems to be sufficient to simply say

IRI

or 

BlankNode

No other constraint components could be using these parameter values, so it is easy to understand that this is a value for the nodeKind. Same with datatype and class.

Of course, alternatively, the syntax could always insist that the parameter must be there, so one had to say

>> ex:worksFor  nodekind=IRI class=ex:Company minCount=0 maxCount=* .
instead of

>> ex:worksFor  IRI ex:Company [0..*] .


But this would be considerably less compact as datatype, class and cardinality values will probably be most commonly specified constraints. Perhaps, followed by nodeKind.

Giving them a special treatment in the interest of the compact syntax being compact, I think, is warranted and easy enough. If anything, a possible improvement may be to see if any other properties could be possibly removed.