Wings allows for the specification of more advanced semantic functionality of components via the definition of rules. Use of these rules is entirely optional. As you saw from the previous testing sections, they are not necessary in order to elaborate or run a workflow. Nevertheless, they provide a very expressive mechanism to state semantic constraints in Wings. As a result, writing rules takes time to master. We are working towards providing a better interface for specifying this functionality that makes manual authoring of rules unnecessary.
NOTE: Wings uses the W3C’s OWL standard to represent and reason about semantic constraints. However, OWL has limited expressivity. A rule language can be used in combination with OWL to express more advanced constraints. The W3C is currently developing a recommendation (ie, a standard) for a rule language.
If you are not familiar with rules, we recommend that you read some introductory materials on this subject. At the moment, Wings supports Apache Jena rules. In the future we plan to support standard rule languages as they become available.
Rules can be entered in the text field in the “Component Rules” tab in the Component Browser. You can use Jena rule syntax and in particular rule built-ins to specify complex conditions. These rules are not associated with any specific component. Instead, in each rule one needs to specify on the left-hand side appropriate conditions under which the rule applies (“fires”), asserting its right-hand side. Hence, if a rule shall only apply to a specific component (which is often the case, see examples below), you need to specify appropriate conditions to limit the application of the rule to only that component.
To get started, consider the following two stubs, specifying two common shapes of these rules:
Preconditions
[name_preconditions:
(?c rdf:type pcdom:nameClass)
(?c pc:hasInput ?in1) (?in1 pc:hasArgumentID "Input1in1")
# your conditions here, e.g., notEqual(?in1, ?in2), or (?in1 dcdom:hasLanguage "en")
-> (?c ac:isInvalid "true"^^xsd:boolean)
]
Effects
[name_effects:
(?c rdf:type pcdom:nameClass)
(?c pc:hasInput ?in1) (?in1 pc:hasArgumentID "Input1in1")
(?c pc:hasOutput ?out1) (?out1 pc:hasArgumentID "Output1out1")
# optionally, you can add conditions here to make this effect conditional,
# or to get the values of some input properties, e.g., (?in1 dcdom:hasLanguage ?lang)
->
# Your assertions here. These will be added to the knowledge base when
# this type of component encountered during workflow elaboration. E.g.,
# (?out1 dcdom:hasLanguage ?lang)
]
This rule states the meta-data properties the outputs of a component of a qualified type have. This allows us, for instance, to propagate meta-data properties over the execution of components. For instance, the following rule states that if the input file has some language ?lang, then the output file will also have that language.
[getSortedWords_effects:
(?c rdf:type pcdom:getSortedWordsClass)
(?c pc:hasInput ?in1) (?in1 pc:hasArgumentID "Input1TextFile)
(?c pc:hasOutput ?out1) (?out1 pc:hasArgumentID "Output1WordListFile)
(?in1 dcdom:hasLanguage ?lang)
->
(?out1 dcdom:hasLanguage ?lang)
]