Re: Can Shapes always be Classes?

On 11/7/14, 6:57 AM, Eric Prud'hommeaux wrote:
> * Irene Polikoff <irene@topquadrant.com> [2014-11-06 15:34-0500]
>> I would put these constraints directly on the Issue class.
>>
>> Peter's suggestion of associating constraints with rdfs:Resource also works. Although, in the presence of large data sets/streams, one doesn’t want to have to check everything for every resource. A key feature of class-associated constraints is that they provide for scoping. When data is small, it doesn’t really matter. For larger data sets, a better practice would be to minimize the number of un-scoped or too broadly scoped constraints.
> If I understand, you would add the submitter and assignee constraints to the Issue class itself. Would that be in the form of a SPARQL that tested the cardinality and object of all of their respective properties?
>
This context-sensitive constraint would be attached to Issue (because it 
is really issue-specific, and does not apply to all Person instances). 
Most other constraints on Person would remain globally, so one would 
only need to cover the small differences that are Issue-specific (and 
the default constraints get owl:imported from another file). So the 
delta that is actually needed here is quite small. And is this even a 
real use case, or a constructed example? Why should not every user of 
the Issue tracker have an email address?

Honestly to me it feels like the whole concept of stand-alone, detached 
Shapes was created as syntactic sugar for corner cases, while being less 
than ideal for the "normal" case of classes with global constraints. 
That's my impression at least, as I don't remember ever having run into 
such scenarios where the above-mentioned work-arounds would not have 
been acceptable.

Holger

Received on Thursday, 6 November 2014 22:29:02 UTC