Editors: Adrian Giurca, Gerd Wagner (REWERSE Working Group I1)
We propose to add typing constructs to the current RIF cre condition language. In particular, the distinction between objects and data values (denoted by object- and data-valued terms such as object names/IDs and data literals), which has a long tradition in computer science, should be adopted. It exists both in UML/OCL and in RDF(S)/OWL/ SWRL. Moreover, many important rule languages such as ILOG JRules, Blaze Advisor Rules, JBoss Rules, Oracle Business Rules make it. However, there are also rule languages that don't support this distinction: Prolog, F-Logic, Jess, Jena2 Rules. Our proposal is to allow (but not require) typing both for terms and atoms. For typed terms the RDF/OWL distinction between object-valued and data-valued terms is adopted. The possibility of having untyped terms and untyped atoms is retained for compatibility with languages that don't support the distinction between data values and objects.
1. NAME ::= #PCDATA
2. Con ::= #PCDATA
3. Var ::= '?' NAME
4. TERM ::= Con Var | Expr
5. Fun ::= #PCDATA
6. Rel ::= #PCDATA
7. Expr ::= Fun '(' TERM* ')'
8. Atom ::= Rel '(' TERM* ')' TERM '=' TERM
9. LITFORM ::= Atom
10. QUANTIF ::= 'Exists' Var+ '(' CONDIT ')'
11. CONJ ::= 'And' '(' CONDIT* ')'
12. DISJ ::= 'Or' '(' CONDIT* ')'
13. CONDIT ::= LITFORM QUANTIF | CONJ | DISJ
Instead of the ambiguous and hard to read abbreviations CON and
DATA we propose to use the more verbose non-terminals
INDIVIDUALNAME and DATALITERAL. Our proposal is to
replace the rule [2] with the new rules below:
INDIVIDUALNAME ::= GenericEntityName | ObjectName | DATALITERAL
DATALITERAL ::= PlainLiteral | TypedLiteral
GenericEntityName ::= xs:NCName
ObjectName ::= 'Obj(' objectID classID ')'
PlainLiteral ::= 'PLit(' lexicalValue languageTag? ')'
TypedLiteral ::= 'TLit(' lexicalValue datatypeID ')'
objectID ::= xs:QName
classID ::= xs:QName
where GenericEntityName is the concept of untyped individual
constants/names, ObjectName is the concept of typed individual
(corresponding to an OWL individual, for example) and PlainLiteral
and TypedLiteral correspond to RDF's plain literal
and typed
literal (i.e. languageTag is as in [RFC-3066] and
lexicalValue being a Unicode [UNICODE] string, which
should be in Normal Form C [NFC]). xs:NCName and xs:QName are XML Schema datatypes.
classID is a reference to the vocabulary class of the
ObjectName.
Following SWRL's abstract syntax we propose to distinguish between object variables i.e. variables that denote objects and data variables i.e. variables that denote data values. Our proposal is to extend the rule [3] with the following rules:
VAR ::= GVar | OVar | DVar
GVar ::= 'GVar(' name ')'
OVar ::= 'OVar(' name classID? ')'
DVar ::= 'DVar(' name datatypeID? ')'
name ::= xs:NCName
datatypeID ::= xs:QName
where OVar stands for object variable, DVar stands
for data variable, GVar stands for generic (or untyped) variable.
classID and datatypeID are optional references to the
corresponding vocabulary elements (classes respectively datatypes). Notice that
imposing the character '?' as starting character for a variable
name is a non necessary (see langyages like Java for example).
In addition to supporting the generic function term concept of standard predicate logic we propose to support also properties as functions, user-defined functions and datatype (or built-in) functions. All these types of functions are constituents of object-oriented programming, modeling and rule languages. Following OO terminology, user-defined functions are called operations, data-valued properties are called attributes and object-valued properties are called reference properties (because they refer to an object). The proposal is to extend the rules [4] and [7] as below:
TERM ::= GTERM | OTERM | DTERM
GTERM ::= GenericEntityName | GVar | GFTerm
GFTerm ::= GFun '(' GTERM* ')'
OTERM ::= ObjectName | OVar | OFTERM
OFTERM ::= ObjectOperationFTerm | ReferencePropertyFTerm
ObjectOperationFTerm ::= objOpID '(' OTERM? TERM* ')'
ReferencePropertyFTerm ::= refPropID'(' OTERM ')'
DTERM ::= DATALITERAL | DVar | DFTERM
DFTERM ::= DataOperationFTerm | AttributeFTerm | DatatypeFTerm
DataOperationFTerm ::= dataOpID '(' OTERM? TERM* ')'
AttributeFTerm ::= attrID '(' OTERM ')'
DatatypeFTerm ::= datatypeFunID '(' DTERM* ')'
All IDs are of type xs:QName.
We follow SWRL's distinction between different types of atoms, because it formalizes the types of atomic statements that are implicit in OO languages. In addition to SWRL's object classification atoms, property atoms and object equality atoms, we propose to include association atoms, which support n-ary relations. Then the proposal is to extend the rule [8] with the following rules:
ATOM ::= GAtom | OATOM | DATOM
GAtom ::= GRel '(' GTERM* ')' | GTERM '=' GTERM
OATOM ::= OClassificationAtom | PROPERTYATOM | AssociationAtom | ObjectEqualityAtom
OClassificationAtom ::= classID '(' OTERM ')'
PROPERTYATOM ::= AttributionAtom | ReferencePropertyAtom
AttributionAtom ::= attrID '(' OTERM DTERM ')'
ReferencePropertyAtom ::= refPropID '(' OTERM OTERM ')'
AssociationAtom ::= assocID '(' OTERM OTERM TERM+ ')'
ObjectEqualityAtom ::= OTERM '=' OTERM
DATOM ::= DClassificationAtom | DatatypePredicateAtom
DClassificationAtom ::= datatypeID '(' DTERM ')'
DatatypePredicateAtom ::= datatypePredID '(' DTERM* ')'
All IDs are of typexs:QName. The equality between two data terms must follow the RDF concept of literal equality and is defined by datatype-specific equality predicates.
At the time of this proposal the following existent languages are investigated:
The concepts of object classification atom and data classification atom already exist in OWL/SWRL and UML/OCL also in specific rule languages. The REWERSE Rule Markup WG develops such XML syntax. All examples below use a possible XML syntax for the RIF Core condition language with the proposed extension (adopted from R2ML ).
// cust is a GoldCustomer RIF: ex:GoldCustomer( OVar(cust ex:Customer)) SWRL: ex:GoldCustomer( I-variable(cust)) UML/OCL: cust : GoldCustomer JRules: ?cust : GoldCustomer(); Blaze: cust is any GoldCustomer JBoss Rules: cust : GoldCustomer() F-Logic: Cust : GoldCustomer.
XML Syntax:
<ObjectClassificationAtom classID="ex:GoldCustomer"> <ObjectVariable name="cust" classID="ex:Customer"/> </ObjectClassificationAtom>
// distance is an Integer RIF: xs:integer( DVar(distance)) SWRL: Integer (D-variable(distance)) UML/OCL: distance : Integer JRules: ?distance : int; Blaze: distance is any Integer JBoss Rules: distance : int F-Logic: -
XML Syntax:
<DatatypeClassificationAtom classID="xs:Integer"> <DataVariable name="distance"/> </ObjectClassificationAtom>
Property atoms are common in OWL/SWRL and UML/OCL. Both languages distinguish between object-valued properties and data-valued properties. While a property is a relation in OWL/SWRL, it is a function in UML/OCL. In RIF, a property can be considered both a relation and a function. Consequently, a relational property atom can be rewritten as an equality atom, as the examples below show. In the case of an attribution (data-valued property) atom, the equality predicate is provided by the respective datatype. In our example below, we reuse the SWRL built-in equality predicate.
// the age of cust is 40 RIF: ex:age( OVar(cust),"40"^^xs:int) RIF: swrlb:equal( ex:age(OVar(cust)),"40"^^xs:int) SWRL: age( I-variable(cust), '40' ) Jena 2: (?cust ex:age "40"^^xs:int) UML/OCL: cust.age = 40 F-Logic: cust:Customer[age -> '40'] JRules: ?cust : Customer(age==40); Blaze: cust is any Customer JBoss Rules: cust : Customer(age == 40)
XML Syntax
// the property ex:age as a relation
<AttributionAtom attributeID="ex:age">
<subject>
<ObjectVariable name="sCart" classID="ex:ShoppingCart"/>
</subject>
<dataValue>
<TypedLiteral lexicalValue="40" datatypeID="xs:integer"/>
</dataValue>
</AttributionAtom>
// the property ex:age as a function
<DatatypePredicateAtom datatypePredicateID="swrlb:equal">
<dataArguments>
<ObjectVariable name="cust" classID="ex:Customer"/>
<TypedLiteral lexicalvalue="40" datatypeID="xs:int"/>
</dataArguments>
</DatatypePredicateAtom>
// the customer assigned to ShoppingCart sCart is cust RIF: ex:customer( OVar(sCart ex:ShoppingCart), OVar(cust)) RIF: ex:customer(OVar(sCart ex:ShoppingCart)) = OVar(cust) SWRL: customer(I-variable(sCart) I-variable(cust)) Jena 2: (?sCart ex:customer ?cust) UML/OCL: sCart.customer = cust; F-Logic: sCart:ShoppingCart[customer -> Cust] JRules: sCart : ShoppingCart(customer == cust); Blaze: sCart is any ShoppingCart such that sCart.customer = cust is any Customer JBoss Rules: sCart:ShoppingCart(customer == cust);
XML Syntax
<ReferencePropertyAtom referencePropertyID="ex:customer">
<subject>
<ObjectVariable name="sCart" classID="ex:ShoppingCart"/>
</subject>
<object>
<ObjectVariable name="cust" classID="ex:Customer"/>
</object>
</ReferencePropertyAtom>
Notice that FLogic does not distinguish between object-valued properties and
data-valued properties but provides a generic concept of property in the form of
an F-molecule. FLogic also encodes the cardinality of the value of a
property (using '->>' for multivalued properties).
The GAtom construct is supposed to be used when interchange with
languages that do not distinguish between objects and data, such as Prolog and
Jess:
RIF: geometry:inbetween( GVar(point1), GVar(point2), GVar(point3)) Prolog: inbetween( Point1, Point2, Point3) JESS: (inbetween ?point1 ?point2 ?point3)
XML Syntax
<GenericAtom genericPredicateID="geometry:inbetween">
<arguments>
<GenericVariable name="point1"/>
<GenericVariable name="point2"/>
<GenericVariable name="point3"/>
</arguments>
</GenericAtom>