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

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.


Received on Saturday, 12 March 2016 03:27:56 UTC