This file refers to the Revision 1.0 of DRMO. Minor changes may be implemented in future revisions. With each new revision, the documentation and all serializations of the ontology will be updated. The URI identifying this version (but not the namespace) is
http://www.semanticdesktop.org/ontologies/2012/03/06/drmo/v1.0/
These specifications introduce the DCON Ontology and its vocabulary.
Status of this document
This document arose from
the work done in the di.me project.
Ontology Visualisation
Ontology description
The DRMO vocabulary allows users to express rules in terms of information elements or context/presence elements, and their attributes. Thus, both classes and instances defined by other ontologies, e.g., pimo:Person to denote any person, or a pimo:Person instance to denote a specific person; nfo:Document to denote any document, or a specific instance; any pimo:Person instance attached to the DCON Live Context through dcon:nearbyPeers, or a specific instance to denote that a specific person needs to be nearby. When wrapping a class within a DRMO rule, one can also places constraints on its attributes, e.g., any person who is a member of (pimo:memberOf) a group; any document including a term in its title (nie:title); any nearby person with a low trust level (nao:trustLevel).
In order to wrap Classes or Instances as DRMO rules, they are typed as drmo:Conditions. Multiple conditions can be expressed in an ordered or unordered way. Condition operators include 'and', 'or', or time ordering using the 'succeeded by' and 'preceded' by operators. Conditions can also be negated. Therefore DRMO rules can be classified as production rules with the added value of temporal constraints.
The Rule Management Ontology concepts are inspired by the Event-Condition-Action (ECA) pattern. The ECA pattern is used in event-driven architectures, where the event specifies what triggers the rule, what conditions to specify, and what actions are executed, unlike in our case where DRMO rules do not expect any transaction event signals (such as 'on update' or 'on delete') to invoke the rule. The DRMO is based on the following rule pattern:
where R represents a rule that consists of a combination of conditions cm, triggering one or more resulting actions an. cm consists of a number of constraints cmn, possibly recursive. In theory, constraints can be applied recursively, thus allowing an infinite number of embedded conditions. For practical reasons, we expect applications of DRMO to set a limit on the amount of embedded conditions. More information can be found in a related publication by DEBATTISTA.
Figure 1 shows examples of condition definitions which can be attached to a rule; the first condition (A) is about a person having a trust level value of 1, the second and third (B,C) are about members in a particular group <urn:Group1>. In the first condition the drmo:hasConstraintOnObject property was defined since the value being constrained (in this case the integer value 1) is in the range of the referred constraint property (nao:trustLevel), making it the object in the RDF triple ({ ?s nao:trustLevel "1 }). In the second condition, the value being constrained is in the domain of the referred constraint property (pimo:hasMember), therefore the RDF triple to be matched would be: {<urn:Group1> pimo:hasMember ?o }. For specific cases, the properties drmo:hasConstraintOnSubject and drmo:hasConstraintOnObject can be used interchangeably; when the constraint property (using drmo:hasConstraintOnProperty) referred by one is replaced by its inverse in the other. From Figure 1, we show how these two properties can be used interchangeably in the second (B) and third (C) conditions. In the third condition, the drmo:hasConstraintOnObject property is used, having a referred constraint property \emph{pimo:memberOf}, where its result will have the same effect as the second condition.
Figure 1. Defining conditions using drmo:hasConstraintOnObject (A,C) and drmo:hasConstraintOnSubject (B)
Although in example Figure 1(B) the constraint is placed on a particular item, we also allow for more complex rules involving constraints (drmo:Conditions) on top of other conditions. To enable this, in Figure 2, we replace the specific drmo:hasConstraintOnSubject in condition (B) with a more generic drmo:hasConstraint. Thus, rather then restricting the value to <urn:Group1>, an embedded condition acts as an intermediate variable that can be retrieved against an additional triple store query. This particular intermediate condition will return any group, such that at least one of its members (subjectValue) has a nao:trustLevel value of 1. The applicable groups will then replace <urn:Group1> in the topmost condition.
Figure 2. Substituting the drmo:hasConstraintOnSubject with drmo:hasConstraint to allow multiple values
Defines the action(s) to be executed if a rule's conditions are satisfied. The Action class specifies an action instance (e.g. 'Notify'), whose semantics are understood by the system and result in specific actions being extracted. This corresponds to the consequent part of a production rule.
Defines condition blocks for rules on which queries and logic tests are performed. Each condition can have constraints (also instances of drmo:Condition) recursively. Multiple conditions in a rule are combined together using a number of logical and event operators. This class can be extended to allow the representation of condition templates, specific to the system's needs.
Defines a declarative rule. A rule instance joins (drmo:isComposedOf) a number of antecedents (condition instances) with a number of consequent (actions)
Defines the constraints (which are of type drmo:Condition) which make up a rule's condition. This property is a subproperty of drmo:hasConstraintOnSubject, such that its range is restricted to a drmo:Condition. What this `restriction' really means is that a drmo:Condition is expected both as the domain and the range for this property. This has the effect of creating nested constraints whereby the referred condition (range defined for this property) is itself another condition. Therefore, the condition at the range of this property needs to be resolved first, before being able to apply this constraint on the condition defined in the domain. Thus the difference between this property and its superproperty is that whereas the latter will look for triples (subject, predicate, object) having one specific item (which is simply the range of drmo:hasConstraintOnSubject) as its subject, this property might result in multiple queries each of which match a different item to its subject. The pattern to retrieve these item(s) is defined by the condition that is in the range of this property, i.e., it is defined by another set of drmo:hasConstraintOnSubject or drmo:hasConstraintOnObject and a corresponding drmo:hasConstraintOnProperty.
Places a constraint on a condition (i.e., the domain defined for this property), such that a query can be constructed to look for an RDF triple having: i) the condition itself (i.e., the domain defined for this property) as its subject, ii) the associated constrained property (defined by drmo:hasConstraintOnProperty) as its property, iii) and the referred item (i.e. the range defined for this property) as its object. This property cannot coincide with the property hasConstraintOnSubject.
Places a constraint on a condition (i.e., the domain defined for this property), such that the referred property (i.e., the range defined for this property) must have a specific value. The restricted value is defined by the use of either drmo:hasConstraintOnSubject or drmo:hasConstraintOnObject, which therefore must always be used in conjunction with this property. The constrained property in combination with the constrained subject/object are then used to query triples matching this pattern.
Places a constraint on a condition (i.e., the domain defined for this property), such that a query can be constructed to look for an RDF triple having: i) the referred item (i.e., range defined for this property) as its subject, ii) the associated constrained property (defined by drmo:hasConstraintOnProperty) as its property, iii) and the condition (i.e., domain defined for this property) as its object. This property cannot coincide with the property hasConstraintOnObject.
This property allows the user to define the resource type of the condition blocks. This is the RDF type that the triples look for when attempting to match conditions. For example, a rule triggered when a person is nearby, will have a condition of type pimo:Person.
Combine TWO condition blocks together with the OR operator. For the rule to trigger its actions, only one of the conditions have to be true at any given time.
TWO conditions (A and B) may be composed together using the precededBy Property. If Condition B is preceded by Condition A, the actions are only triggered if Condition A happens at any time before Condition B. This is the inverse property of drmo:succeededBy.
TWO conditions (A and B) may be composed together using the succeededBy Property. If Condition A is succeeded by Condition B, the actions are only triggered if Condition B happens at any time after Condition A. This is the inverse property of drmo:precededBy.
