Re: Overriding rules in sub-classes

I can however set the sh:resultPath so that may be sufficient; if there are
use-cases where I need to know the subject node, maybe I can infer it?  For
the moment, resultPath may be enough to last the weekend!

On Fri, Sep 20, 2019 at 4:08 PM Gary Murphy <gary@schemaapp.com> wrote:

> well ... almost, it works for validation purposes except for one small
> detail: I've lost any information to say which particular Organization in
> the input had triggered which error ...
>
> Logic puzzles are so much fun ...
>
> On Fri, Sep 20, 2019 at 3:48 PM Gary Murphy <gary@schemaapp.com> wrote:
>
>> 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
>>
>
>
> --
> 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