Re: Overriding rules in sub-classes

Correct

> On Sep 20, 2019, at 3:46 PM, Gary Murphy <gary@schemaapp.com> wrote:
> 
> Thanks for the clarification (and correction) I may still be a bit lost,  I'm thinking the basic shacl structure would be
> 
> :OrganizationShape
>   a sh:NodeShape ;
>   sh:property [
>       sh:path ( sh:inversePath rdf:type schema:contactType );
>       sh:datatype xsd:string ;
>       sh:minCount 1 ;
>     ] ;
>   sh:targetNode :Organization
> .
> it seems to be working ;)
> 
> On Fri, Sep 20, 2019 at 3:25 PM Irene Polikoff <irene@topquadrant.com <mailto:irene@topquadrant.com>> wrote:
> I think I made a typo. 
> 
> I meant to say:
> 
> Use sh:targetNode :Organization
> 
> Then, for all property shapes use a path with inverse of rdf:type e.g.
> 
> ^rdf:type/schema:sameAs
> 
> To constrain values of schema:sameAs for organizations.
> 
> Since you are looking specifically for a triple {?s rdf:type :Organization} you are not constraining values for members of subclasses.
> 
>> On Sep 20, 2019, at 3:07 PM, Gary Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> wrote:
>> 
>> It's been a while since I had the chance to try this --  your Option 2 using an inverse path does seem my best choice as { ?s rdf:type :Organization } is exactly the constraint I need and I thought I'd understood the method, but I'm still having trouble phrasing sh:targetObjectsOf to constrain to just that one rdf:type value.
>> 
>> On Fri, Sep 6, 2019 at 12:02 PM Gary Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> wrote:
>> oh yes, much better.  thank you!
>> 
>> On Fri, Sep 6, 2019 at 11:06 AM Irene Polikoff <irene@topquadrant.com <mailto:irene@topquadrant.com>> wrote:
>> When a property shape is targeting class members, it applies to all class members including those that are members of subclasses.
>> 
>> Deactivating, de-activates the shape for all targets. There is no way to keep it active for some and deactivate it for others.
>> 
>> When different behavior is needed for different classes that have a common parent, I could think of the following options:
>> 
>> 1. Target at the lowest level of the class hierarchy that would work for your purposes
>> 
>> 2. Do not use class target (implicit of explicit). Instead use sh:targetObjectOf on the inverse of the rdf:type property
>> 
>> This may be the most appropriate solution in your situation. It would target only resources that are subjects in the {?s rdf:type :Organization} triples. Instances of subclasses would not be targeted.
>> 
>> 3. Various other modeling options
>> 
>> Such as creating “view Or abstract classes”  for the purpose of targeting only 
>> 
>> e.g.
>> 
>> Organization
>>  NonProfit Organization
>>  Government Organization
>>  Commercial Organization
>>   Local Business
>> 
>> Create a class
>> 
>> Non-Commercial Organization
>> 
>> Make NonProfit Organization and Government Organization its subclasses. This could be done in addition to them being subclasses of Organization so that Non-Commercial Organization is not part of the above hierarchy.
>> 
>> Now, you could target Non-Commercial Organization.
>> 
>> This is a variant on what Jakub’s proposed using SPARQL target approach.
>> 
>>> On Sep 6, 2019, at 10:33 AM, Gary Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> wrote:
>>> 
>>> Well that's the problem, the constraints don't always say the same thing, or may have different sh:severity, or may be contingent on other properties of the sub-class item or inverse paths; if there's no mechanism, then of course there has to be a work-around, which may be to programmatically sift the received shacl results to select out those pertaining to the actual instance class before displaying them.
>>> 
>>> I had hoped it may be possible to limit the scope of sh:deactivated in some way, so in the sub-class, a rule could implicate the ancestor shape by name, deactivate it, and then provide it's own class-specific test, but then again, when the shacl engine encountered the parent rule, how could it know?  I'm thinking Jakub's method of excluding the subClass in the ancestor rule may be the best option.
>>> 
>>> 
>>> On Thu, Sep 5, 2019 at 3:10 PM Irene Polikoff <irene@topquadrant.com <mailto:irene@topquadrant.com>> wrote:
>>> Since LocalBusiness is a subclass of Organization, you do not need to repeat the constraint for it.
>>> 
>>> It is already in place. There is no override since the constraints say the same thing. It is just unnecessary repetition.
>>> 
>>> On Sep 5, 2019, at 2:32 PM, Gary Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> wrote:
>>> 
>>>> 
>>>> Is it possible to specifically override a rule when applied to a subclass?
>>>> 
>>>> I have
>>>> schema:LocalBusiness rdfs:subClassOf schema:Organization
>>>> 
>>>> and in the shapes rules for both I have 
>>>> sh:path schema:sameAs ;
>>>> sh:minCount 1 ;
>>>> 
>>>> and each has a message, but the message is (slightly) different; when I validate the file, I get both rules reporting, so there are two messages, one for Organization, one for LocalBusiness
>>>> 
>>>> Is there a general pattern for avoiding this?  I'd like to override the Organization rule rather than see both.
>>>> 
>>>> -- 
>>>> Gary Lawrence Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> - Hunch Manifest, 15 Wyndham N 'C', Guelph
>>> 
>>> 
>>> -- 
>>> Gary Lawrence Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> - Hunch Manifest, 15 Wyndham N 'C', Guelph
>> 
>> 
>> 
>> -- 
>> Gary Lawrence Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> - Hunch Manifest, 15 Wyndham N 'C', Guelph
>> 
>> 
>> -- 
>> Gary Lawrence Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> - Hunch Manifest, 15 Wyndham N 'C', Guelph
> 
> 
> 
> -- 
> Gary Lawrence Murphy <gary@schemaapp.com <mailto:gary@schemaapp.com>> - Hunch Manifest, 15 Wyndham N 'C', Guelph