- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 12 Mar 2016 13:27:21 +1000
- To: public-data-shapes-wg@w3.org
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
Received on Saturday, 12 March 2016 03:27:56 UTC