Re: Can Shapes always be Classes?

* Holger Knublauch <holger@topquadrant.com> [2014-11-07 08:28+1000]
> 
> 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).

Could you mock that up using the data and schema earlier in this
thread? I ask because the uses of SPIN templates that I've seen have
all involved rdfs:range inference applied globally to a predicate
while common practice (at least among the OWL community) is to keep
predicates as reusable as possible by constraining their use in
particular contexts with onProperty restrictions.


>                    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?

Just about any time you see re-used types, there is a strong
possibility that different people will have different restrictions on
their use.


> 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
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 7 November 2014 02:05:34 UTC