Re: Re: using classes to control constraints

I don't think so.

Everything said so far, confirms the view that constraints stated on a
superclass must hold on subclasses.

Michel's request is going farther in saying that if a range of property
values in a constraint is defined as members of a superclass, data that
uses members of its subclasses for the property values should also pass
validation.

On Thu, Feb 12, 2015 at 12:40 AM, Simon Steyskal <ssteyska@wu.ac.at> wrote:

> Hi!
>
> I guess that would contradict the general notion of inheritance, i.e. all
> constraints stated on a superclass must hold on its subclasses too and
> there should be no constraints that are not passed to a superclass'
> children.
>
> simon
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Michel Dumontier <michel.dumontier@gmail.com>
> Datum: 12.02.2015 05:54 (GMT+01:00)
> An: Irene Polikoff <irene@topquadrant.com>
> Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Holger Knublauch
> <holger@topquadrant.com>, public-data-shapes-wg@w3.org
> Betreff: Re: using classes to control constraints
>
> Hi,
>   i would like to have shapes to be compatible with OWL entailment.  For
> instance, if I place a superclass in a constraint, i would like to validate
> positive where i have a subclass in the data.  But I see that as a choice
> that should be specified with the shape, as I could imagine that you might
> also want to validate with only the specified class.
>
> m
>
>
>
> On Feb 11, 2015, at 8:16 PM, Irene Polikoff <irene@topquadrant.com> wrote:
>
> There is no interaction with entailment or querying. The data is what it
> is.
>
> Constraints describe what the data should be in order to pass the
> validation. They are used to validate the data that is available. They
> don't change the data.
>
> On Wed, Feb 11, 2015 at 7:38 PM, Peter F. Patel-Schneider <
> pfpschneider@gmail.com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> On 02/11/2015 04:16 PM, Irene Polikoff wrote:
>> > When is it supposed to be checked?
>> >
>> > When constraint checking/data validation is invoked
>>
>> Only then?  What is the interaction with entailment?  And querying?
>>
>> > What reporting needs to be done?
>> >
>> > As I recall, there has been a discussion about what should be returned
>> > and a few people provided examples of the kind of reporting they want.
>> It
>> > has been captured in the LDOM document.
>>
>> That was for explicit invocation of validation.   If type assertions can
>> be
>> made to shapes then I think that much more needs to be done.
>>
>> > Why are you asking?
>>
>> Because, explicit typing to shapes needs to be integrated into the rest of
>> RDF, RDFS, and SPARQL.
>>
>>
>> peter
>>
>> >
>> > On Wed, Feb 11, 2015 at 4:17 PM, Peter F. Patel-Schneider
>> > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>> >
>> > So there is in an error in an RDF graph.  How is that supposed to work?
>> > When is it supposed to be checked?  What reporting needs to be done?
>> >
>> > peter
>> >
>> >
>> > On 02/11/2015 01:08 PM, Irene Polikoff wrote:
>> >> It is intended for validation and works over data that exists. So, if
>> >> ex:a is not ex:p ex:q, there is an error.
>> >
>> >> On Wed, Feb 11, 2015 at 1:49 PM, Peter F. Patel-Schneider
>> >> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>> > <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>> wrote:
>> >
>> >
>> >
>> >> On 02/11/2015 10:42 AM, Irene Polikoff wrote:
>> >>> <What would it mean to assert that an object belongs to a shape via
>> >>> an rdf:type link?>
>> >
>> >>> I believe it would mean that constraints defined for the shape apply
>> >>> to the object.
>> >
>> >
>> >> So I can infer things from this assertion?  For example, if ex:shape
>> >> requires that the value of ex:p be ex:q then does ex:a rdf:type
>> >> ex:shape . imply ex:a ex:p ex:q .
>> >
>> >> peter
>> >
>> >
>> >
>> >
>> >
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJU2/X1AAoJECjN6+QThfjztwYH/RGKnTIPGMQrrJb9OtignRAT
>> MNcGm2fkh39D8IpUkoE85JAKzG9NJcvdI74748JJppdUnrJPbCwXWlX9HnNDNOW4
>> lbgTK8Y3eiDr7liavMsK+7ZbuF/QAocAXaWU9dPbwdrCXHFY1jmfY6y1H0KlfvST
>> vvyAh12zhzHFxgksALkxKEvnSaGL6rHlZUoNh6Ke/8gZKn5Z2B0yQJZvkJdVU5sa
>> j1P/BrzLd5QNIUgiSQJklQecXN8sTZt5Cd96ePGlGD6hn9aLnVUKgbNH5BvpMchw
>> z51tUAaXAQFK1RtoRec+PYiJxaXRQ3UK3ZZQ1JsWSIq5350vx16j7jXgyc5+4eg=
>> =8Iey
>> -----END PGP SIGNATURE-----
>>
>
>

Received on Thursday, 12 February 2015 17:09:42 UTC