Re: Overriding rules in sub-classes

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