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

My feedback was triggered by Simon's comment "Trying to get our own compact
syntax published now will cause more harm than good."

I am not trying to block the publication of the compact syntax. All I'm
saying is that maybe we should aim to publish this in a more flexible
location. People who will end up on the note document will not have a way
to navigate to the up-to-date version since it cannot be changed until a
new WG is formed.

Best,
Dimitris

Typed by thumb. Please forgive brevity, errors.

On May 30, 2017 04:05, "Irene Polikoff" <irene@topquadrant.com> wrote:

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