Re: Overriding rules in sub-classes

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

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