Re: Overriding rules in sub-classes

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

> oh yes, much better.  thank you!
>
> On Fri, Sep 6, 2019 at 11:06 AM Irene Polikoff <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> 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>
>> 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> 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> - Hunch Manifest, 15 Wyndham
>>> N 'C', Guelph
>>>
>>>
>>
>> --
>> Gary Lawrence Murphy <gary@schemaapp.com> - Hunch Manifest, 15 Wyndham N
>> 'C', Guelph
>>
>>
>>
>
> --
> Gary Lawrence Murphy <gary@schemaapp.com> - Hunch Manifest, 15 Wyndham N
> 'C', Guelph
>


-- 
Gary Lawrence Murphy <gary@schemaapp.com> - Hunch Manifest, 15 Wyndham N
'C', Guelph