Excluding specific subclasses from a spin rule,constraint...etc

[Nikolaos Beredimas]

Quoting from http://www.w3.org/Submission/spin-modeling/ :

In other words, SPIN class descriptors can only "narrow down" and further restrict what has been defined further up in the class hierarchy. In this spirit, global class descriptions are those that are attached to the root class rdfs:Resource or its OWL equivalent owl:Thing.

So if you define a rule/constraint/... for owl:Thing, it is a global rule. It applies to every subclass of owl:Thing automatically.

I have come across some use cases where this isn't the desirable behavior. I was wondering, therefore, if there is a stanard, SPIN way, of annotating a class, or the top class of a sub-hierarchy of classes, to exclude a specific rule/constraint or a collection of rules/constraints from applying to this class/classes.

Ofc, I could edit said class and annotate it with a custom property, and edit the spin rule/constraint accordingly to check for that annotation

or, I could edit the classes hierarchy and move said class to a different hierarchy 

or any other custom solution.

But I was wondering if there was a SPIN specified way of doing this.

TL;DR 

How to exclude specified SPIN rules from applying to specified subclasses, using only the SPIN vocabulary

PS. Apologies if the answer is too obvious

[Scott Henninger]

Nikolaos; One approach would be to FILTER out the class instances. I.e.:

{ ?this :prop ?value .

  ...

  ?undesiredInstance a :SubClass1 .

  FILTER (?this != ?undesiredInstance)
}

-- Scott

Sent from my iPhone

--
You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nikolaos Beredimas]

Yes I understand that.

But anything like this feels like a custom, one-off, solution, and that entais some disadvantages. 

For example, it ties the SPIN rule to the specific ontology. In another ontology, you'll have to reimplement the rule.

It, also, ties this information to the rule definition, when in reality it should belong to the class definition.

Inferencing also comes into play and you have to account for that too.

That's why I was asking for a generic, SPIN defined solution.

Judging from the answer I understand there is probably not a way to achieve this in a generic, ontology-independent, way, at least currently

Do you think this is a feature that we could hope for in a newer SPIN revision?

In a nutshell, it would extend the object-oriented notion of SPIN rules/constraints inheritance with the ability to override/shadow/retract specific rules/constraints for given subclass(es)

[Scott Henninger]

OK, try this instead.  Add a property, let's name it :doNotProcessRule.  For the classes you do not want to be processed, add (one ore more) rule name, such as "rule1".  The use the following graph pattern.

WHERE {
    ?this ...
    OPTIONAL {
        ?this a ?cls .
        ?cls :doNotProcessRule "rule1" .
    } .
    FILTER (!bound(?cls)) .
}

If a class has a value of "rule1" for :doNotProcessRule, its instances will not be processed by the SPIN rule.  Of course you can have values other than "rule1", but it's just a matter of making a match on a class property to tell the reasoner to skip its instances.


Basically, SPARQL, and maybe a bit of modeling provides a great deal of flexibility for controlling SPIN execution.

-- Scott

[Nikolaos Beredimas]

This feels very close to what I was thinking, because it fits very well with my use case.

However, the question remains (because one can start imagining a lot of use cases):

Wouldn't it be more powerful/beautiful if it could be something like

:myClass spin:ignore :rule1 (eg. just for :myClass, but not its subclasses)

or

:myClass spin:retract :rule1 (for :myClass and all its subclasses)

or

:myClass spin:override [ :rule2 spin:replaces :rule1] (override/replace rule for :myClass and subclasses)

or

:myClass spin:extends [ :sparql_fragment spin:optional :rule1] (and a OPTIONAL graph matching pattern to the to the sparql query that gets executed)

and for all these, the SPIN engine (and not the developer) would be responsible to automatically concstruct/decide the new sparql queries to be executed.

I understand, this would not be a trivial feature to add, but maybe I could persuade you :)

You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/yxgHQe0P5Fk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.

[Holger Knublauch]

Hi Nikolaos,

this is certainly an interesting question, yet I don't see how to solve this. As soon as inferencing is activated, and you have a class hierarchy such as

rdfs:Resource
    ex:RootClass   rule1
        ex:ChildClass   rule2 overrides rule1

and ex:Instance a ex:ChildClass, then an inference engine would add ex:Instance a ex:RootClass, and things become really messy to check. I believe rules and constraints should only ever narrow down the semantics.

It would help me to see a real-world example of such scenarios. Maybe there are work-arounds using multiple inheritance/multiple rdf:types.

BTW this is an interesting discussion in regards to the ongoing W3C Shapes Working Group, that quite possibly creates something close to a "SPIN 2.0", called SHACL [1]. In that spec, take a look at the proposed sh:scope attribute that would allow you to place pre-conditions in front of constraints.

Thanks
Holger

[1] https://w3c.github.io/data-shapes/shacl/

[Nikolaos Beredimas]

Thanks Holger.

If I undestand you correctly, the bottom line is that it doesn't make sense to develop/model, as a standard, any behavior that cannot stand alongside basic inferencing.

I think I agree with that.

I will have to read up on the Shapes WG and SHACL and possibly ask further questions there, but if you can

what are the similiarities and or differencies between the Shapes WG and the discussions at  https://lists.w3.org/Archives/Public/public-rdf-shapes/

[Holger Knublauch]

On 4/7/2015 0:40, Nikolaos Beredimas wrote:

Thanks Holger.

If I undestand you correctly, the bottom line is that it doesn't make sense to develop/model, as a standard, any behavior that cannot stand alongside basic inferencing.

I think I agree with that.

I will have to read up on the Shapes WG and SHACL and possibly ask further questions there, but if you can

what are the similiarities and or differencies between the Shapes WG and the discussions at  https://lists.w3.org/Archives/Public/public-rdf-shapes/

That mailing list was the public discussion forum of the group prior to its official forming. The WG itself, and a link to its (busy) mailing list, can be found at

https://www.w3.org/2014/data-shapes/wiki/Main_Page

Holger

Τη Σάββατο, 4 Απριλίου 2015 - 6:42:45 π.μ. UTC+3, ο χρήστης Holger Knublauch έγραψε:

Hi Nikolaos,

this is certainly an interesting question, yet I don't see how to solve this. As soon as inferencing is activated, and you have a class hierarchy such as

rdfs:Resource
    ex:RootClass   rule1
        ex:ChildClass   rule2 overrides rule1

and ex:Instance a ex:ChildClass, then an inference engine would add ex:Instance a ex:RootClass, and things become really messy to check. I believe rules and constraints should only ever narrow down the semantics.

It would help me to see a real-world example of such scenarios. Maybe there are work-arounds using multiple inheritance/multiple rdf:types.

BTW this is an interesting discussion in regards to the ongoing W3C Shapes Working Group, that quite possibly creates something close to a "SPIN 2.0", called SHACL [1]. In that spec, take a look at the proposed sh:scope attribute that would allow you to place pre-conditions in front of constraints.

Thanks
Holger

[1] https://w3c.github.io/data-shapes/shacl/