Re: Proposal to close ISSUE-102 leaving this to other syntaxes

I'd be more in favor of this solution if I saw evidence that there will 
be a compact syntax that provides this.

Note that the requirement for min/max reads:

4.2.1 R5.2: Property Min/Max Cardinality

The stated values for a property may be limited by minimum/maximum 
cardinality, with typical patterns being [0..1], [1..1], [0..*] and [1..*].

If this wasn't to be included in SHACL as stated, then the group should 
have discussed and accepted this change. If we had, it would have been 
solved by now. Unfortunately, it is now "carved in code" which makes 
changing more difficult.

I'm working on a table comparing the requirements to the SHACL draft 
(which will need input from others).[1] I'd like to make clear what is 
in the requirements that is different from the draft, and what is in the 
draft that is not in the requirements. The requirements state the mind 
of the group at that time, and we can discuss additions or changes, but 
we should keep them in the process.

kc
[1]https://docs.google.com/document/d/1whx2DeJtng-WZXo2DAHc_GZL7ElXNS_B8fBxarGA-0o 
- in a Google doc now because I didn't want to put it on the wiki until 
i had experimented a bit. has requirements, some SHACL functions, lots 
of question marks

On 10/15/15 2:02 PM, Holger Knublauch wrote:
> I believe having a way to specify unbounded maxCount and open shapes in
> RDF triples is unnecessary and has more costs than benefits. We should
> keep the language consistent - if nothing is stated then nothing is
> constrained. If we do such defaults for maxCount then the same would be
> expected for all other constraint types. However, other syntaxes and
> user interface tools may display this information, i.e. your option 3).
>
> Proposal: Close ISSUE-102 stating that no changes to the RDF data model
> of SHACL are done but other languages such as a Compact Syntax may
> include things like [0..*]
>
> Holger
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Saturday, 17 October 2015 21:29:09 UTC