Re: ISSUE-133: multi-occurrence use cases (was: Selected problems with Proposal 4)

I would say NO for LessThen and LessThenOrEqual.

Like with cardinalities, one number will always be less than another. It doesn't add any new information to, for example, say less than 8 or less then 15, compared to just saying less then 15.

That it is, if this is interpreted as OR. The same argument stands, if it is interpreted as AND.

[I guess I am already wondering/forgetting if it is OR or AND - :)]

May be this what you mean when you say:

> Looking at the YES entries, I guess only sh:class, sh:hasValue and sh:valueShape may conceivably be used multi-valued in practice


Sent from my iPhone

> On Mar 11, 2016, at 10:27 PM, Holger Knublauch <holger@topquadrant.com> wrote:
> 
>> On 12/03/2016 2:23, Karen Coyle wrote:
>> The example that I refer to is:
>> 
>> ex:exampleShape a sh:Shape ;
>>   ex:example [ ex:predicate ex:p ; ex:lang "de" ; ex:lang "en" ] .
>> 
>> Is this using the same mechanism? (Hmmm. This could be an erroneous example, no?)
> 
> Yes, and yes this wouldn't make sense because a literal cannot at the same time have two languages.
> 
>> 
>> I'm asking for examples that do not use sh:class, to understand how else this might be used. Thanks.
> 
> Let's go through the list:
> 
> - sh:class YES
> - sh:directType YES
> - sh:classIn NO
> - sh:datatype NO
> - sh:datatypeIn NO
> - sh:equals YES
> - sh:notEquals YES
> - sh:hasValue YES
> - sh:in NO
> - sh:lessThan YES
> - sh:lessThanOrEquals YES
> - sh:minCount NO
> - sh:maxCount NO
> - sh:minLength NO
> - sh:maxLength NO
> - sh:minInclusive NO
> - sh:maxInclusive NO
> - sh:minExclusive NO
> - sh:maxExclusive NO
> - sh:nodeKind NO
> - sh:pattern YES (theoretically)
> - sh:uniqueLang NO
> - sh:valueShape YES
> 
> In most cases, multiple values would be invalid.
> 
> Looking at the YES entries, I guess only sh:class, sh:hasValue and sh:valueShape may conceivably be used multi-valued in practice. An unknown factor is if any future extensions (templates) would benefit from this.
> 
> Whether this is worth supporting in the syntax is to me valid question. The fallback is always to use the slightly more verbose syntaxes, e.g. using sh:and and make every property single-valued to have a simpler syntax and allow simpler user interfaces. It also avoids the issue of what happens for constraint types with multiple parameter properties. Also: one thing less to explain - would be easier to teach when only one value is allowed.
> 
> Besides, when I see multiple sh:class values, I intuitively wonder whether this means AND or OR and the same may happen to other people. It may cause more confusion than benefits.
> 
> At this stage I would vote against allowing this, instead possibly improve the syntax of sh:and.
> 
> Holger
> 
>