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 :) On Fri, Apr 3, 2015 at 3:49 PM, Scott Henninger <[email protected]> wrote: > 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 > > > On 4/3/2015 8:16 AM, Nikolaos Beredimas wrote: > > 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) > > > Τη Παρασκευή, 3 Απριλίου 2015 - 2:41:56 μ.μ. UTC+3, ο χρήστης 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 >> >> On Apr 3, 2015, at 7:05 AM, Nikolaos Beredimas <[email protected]> wrote: >> >> 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 >> -- >> 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 [email protected] >> --- >> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> -- > 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 [email protected] > --- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > 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 [email protected] > --- > 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 > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected] --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
