Re: ISSUE-133: Wiki page with syntax examples

In general I am in favor of syntax simplifications but I have some concerns
on this one, mainly from the use perspective
What might not be straightforward for the users with this proposal is that
when they use sh:or in property constraints they will not be able to use
components such as
sh:hasValue, sh:equals, sh:disjoint, sh:min/maxCount, sh:uniqLang and in
general all components with NC not checked in the table of section 4
e.g. when someone defines that a property ex:p  must :
 - have sh:hasValue X or sh:hasValue Z
 - be sh:equals to ex:p1 or ex:p2
they will always get back failures or violations (depending on ISSUE-139)

the reason is that when someone uses sh:or from a property constraint,
sh:or in interpreted as a node constraint and although  in many cases this
works well, (e.g. with datatypes, nodeKind, etc) all components that do not
support both contexts are problematic
we also have sh:closed that with the current definition applies only on
Node Constraints and people will be actually able to use it in an sh:or in
a property constraint now

Based on the above, I would prefer not to go with this change but since I
saw support during the last call I only raise my concerns and will stay
neutral on this.




On Mon, Jul 18, 2016 at 4:21 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 17/07/2016 5:17, Karen Coyle wrote:
>
>> Holger, thanks for this. My question now is, would we still need:
>>
>> sh:PropertyConstraint
>> sh:NodeConstraint
>> sh:property
>> ?
>>
>
> sh:NodeConstraint would disappear - it would be sh:Shape. The class
> hierarchy would look like
>
> sh:Constraint
>     sh:PropertyConstraint
>     sh:Shape
>
> and sh:property would be the parameter of a constraint component that
> takes sh:PropertyConstraints as its values. A sh:Shape would be a
> constraint that is satisfied if all its constraint components are satisfied
> (see sh:hasShape).
>
>
>> If (as it appears) sh:property is always followed by a node with
>> sh:predicate, then those are redundant, and only sh:predicate is necessary.
>>
>
> I cannot follow this train of thought. Along the same lines, all classes
> would be redundant as soon as they have a property that makes them
> identifiable. But sh:PropertyConstraint is very distinct from
> sh:NodeConstraint or sh:Shape. Among others it serves as a container to
> group together properties that only make sense there, e.g. sh:predicate,
> sh:path, sh:name, sh:description, sh:order, sh:group - none of which apply
> to shapes in general. I believe it will also be an intuitive concept for
> people coming from OWL or object-oriented backgrounds - basically a shape
> declares properties, and these properties have their own characteristics.
> In OWL this is similar to owl:Restrictions. The metamodel is IMHO cleaner
> this way.
>
> Holger
>
>
>
>
>> kc
>>
>> On 7/14/16 3:43 PM, Holger Knublauch wrote:
>>
>>> I have started a wiki page to collect examples of how the proposed
>>> syntax change to merge sh:Shape and sh:NodeConstraint would look like:
>>>
>>>     https://www.w3.org/2014/data-shapes/wiki/ISSUE-133
>>>
>>> Please feel free to edit this page and/or discuss on the mailing list.
>>>
>>> Cheers,
>>> Holger
>>>
>>>
>>>
>>>
>>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT