Re: Overriding rules in sub-classes

Yay!!!  I love happy endings.

Thanks again!

On Fri, Sep 20, 2019 at 3:47 PM Irene Polikoff <irene@topquadrant.com>
wrote:

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

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