Editors: Adrian Giurca, Gerd Wagner (REWERSE Working Group I1)
Date: November 28, 2006

RIF Core Vocabulary

The RIF Positive Conditions Language acts implicitely in top of a vocabulary. This vocabulary consists of a number of names which are Unicode strings in the normal form C.

EBNF

VOCABULARY         ::= (VOCABULARY_ENTRY)*
VOCABULARY_ENTRY   ::= (Rel | Con | Fun)*
Rel                ::= ID
Fun                ::= ID
Con                ::= ID
ID                 ::= unicode string in normal form C

The UML class diagram modeling this vocabulary is:

REWERSE I1 Proposal

Motivation

The distinction between objects and data values (denoted by object- and data-valued terms such as object names/IDs and data literals) has a long tradition in computer science. It exists both in UML/OCL and in RDF(S)/OWL/ SWRL. Moreover, many important languages on the market like ILOG JRules, Blaze Advisor Rules, JBoss Rules, Oracle Business Rules consider 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.

REWERSE I1 Proposal for Basic RIF Vocabulary

The RIF Core Vocabulary contains just Rel, Fun and Cons.

We propose to extend this vocabulary with a number of fundamental concepts:

• The abstract concept of TYPE. Any TYPE may have super types.
• Class a subclass of TYPE
• Property as a special kind of predicate (i.e. Rel).
• Operation as a special kind of function (i.e. Fun).

The UML class diagram of this vocabulary is:

The actual RIF vocabulary is in white, while in our extansion proposal concepts are in aqua and their relationships in red.

We propose also better names: Predicate instead of Rel, Function instead of Fun, IndividualName instead of Con

Below is the EBNF corresponding to the class diagram

EBNF

VOCABULARY       ::= (VOCABULARY_ENTRY)*
VOCABULARY_ENTRY ::= (Predicate | IndividualName | Function | TYPE)*
Predicate        ::= 'Predicate(' predicateID ('argumentType(' typeID ')')* ')' | Property
Property         ::= 'Property(' propertyID ('domain(' classID ')')? ('range(' typeID ')')? ')'
Function         ::= 'Function(' functionID ('argumentType(' typeID ')')* ')' | Operation
Operation        ::= 'Operation(' operationID ('contextType(' classID ')')? ('argumentType(' typeID ')')*  'returnType(' typeID ')' ')'
IndividualName   ::= 'IndividualName(' individualNameID ('type(' typeID ')')? ')'
TYPE             ::= Class | Datatype 
Class            ::= 'Class(' classID ('superType(' classID ')')* ')'
Datatype         ::= 'Datatype(' datatypeID ('superType(' datatypeID ')')* ')'

predicateID      ::= xs:Qname | xs:anyURI
functionID       ::= xs:Qname | xs:anyURI
individualNameID ::= xs:Qname | xs:anyURI
typeID           ::= classID  | datatypeID
classID          ::= xs:Qname | xs:anyURI
datatypeID       ::= xs:Qname | xs:anyURI

Typed and untyped individual constants

IndividualName

The concept of typed/untyped individual constants/names.

EBNF:	
IndividualName(abc)
IndividualName(ex:John type(ex:Person))

XML Syntax: 
<IndividualName individualNameID="abc"/>
<IndividualName individualNameID="ex:John" classID="ex:Person"/>

Classes and datatypes

TYPE

The abstract concept of TYPE is partitioned into object types (classes) and datatypes.

ENBF:
Class( ex:Boy superClass(ex:Male) superClass(ex:Child))
Datatype(xs:float)

XML Syntax:
<Class classID="ex:Boy">
  <superclass classID="ex:Male"/>
  <superclass classID="ex:Child"/>
</Class>

<Datatype datatypeID="xs:float"/>

Predicates

The concept of Predicate models the standard concept of a relation and has a special subclass Property which is a binary predicate with two arguments types: One is the domain of the property and the second one is its range.

Predicate

EBNF:
Predicate(ex:borrows argumentType(ex:Person) argumentType(ex:Person) argumentType(xs:positiveInteger))

XML Syntax:
<Predicate predicateID="ex:borrows">
 <argumentType classID="ex:Person" />
 <argumentType classID="ex:Person" />
 <argumentType datatypeID="xs:positiveInteger" />
</Predicate>  

Property

EBNF: 
// age is a property of the class Person
Property(ex:age domain(ex:Person) range(xs:positiveInteger))

XML Syntax: 
<Property propertyID="ex:age" >
 <domain classID="ex:Person" /> 
 <range datatypeID="xs:positiveInteger"/> 
</Property>

Functions

Function preserve the standard concept of a function and includes Operation as a subclass. Operation is a special function which has at least two agruments types: the context type and the return type. This corresponds to the UML concept of operation.

Function

The standard logic concept of function.

EBNF:
// f is a function 
Function(ex:sqrt argumentType(ex:positiveFloat))

XML Syntax:
<Function functionID="ex:sqrt">
 <argumentType datatypeID="ex:positiveFloat" />
</Function> 

Operation

A special type of a user-defined function that corresponds to an operation in a UML class model (UML vocabulary).It may have arguments types both classes and datatypes and has a return type.

EBNF:
// getNthAncestor is an Operation of class Person 
ObjectOperation (ex:getNthAncestor contextType(ex:Person) argumentType(xs:positiveInteger) returnType(ex:Person))

XML Syntax: 
<Operation operationID="eur:getNthAncestor">
 <contextType classID="eur:Person"/>
 <argumentType datatypeID="xs:positiveInteger"/>
 <returnType classID="ex:Person"/>
</Operation>