1. | Abstract | ||||||||||||||||||||
2. | Introduction | ||||||||||||||||||||
|
|||||||||||||||||||||
3. | Expressions | ||||||||||||||||||||
4. | Queries | ||||||||||||||||||||
|
|||||||||||||||||||||
5. | (Query-related) Actions | ||||||||||||||||||||
6. | Rules | ||||||||||||||||||||
7. | Use-cases | ||||||||||||||||||||
|
|||||||||||||||||||||
8. | References | ||||||||||||||||||||
This specification defines the syntax and semantics of RDF Inference Language (RIL), a means of expressing expert systems rules and queries that operate on RDF models. RIL is an open format for complex queries on a directed graph established for knowledge representation.
RIL is allows the definition of rules and the composition of queries that operate on an RDF model. This is done using an XML vocabulary for instructions to the RIL processor.
Where used in this document, the keywords "SHOULD", "MUST", and "MUST NOT" are to be interpreted as described in RFC 2119 [RFC2119]. However, for readability, these words do not appear in all uppercase letters in this specification.
In this version of the specification the ril namespace prefix shall be used to represent the namespace reference http://xmlns.rdfinference.org/ril/0/1.
In addition, several namespaces will be used as examples in this specification. To improve readibility, these namespaces will be represented using XML namespace Qnames with common prefixes as shown in the following table the ril namespace prefix shall be used to represent the namespace reference http://xmlns.rdfinference.org/ril/0/2.
Please note that all these prefixed abbreviations are mere convenience, and that any such qualified names must be interpreted as if the prefix represents the full namespace URI.
The version of RIL specification used in a particular instruction is indicated using its namespace.
The version of RIL represented by this specification is 0.2, and conforming instances should use the http://xmlns.rdfinference.org/ril/0/2 namespace, but processing applications can generically refer to RIL instances as http://xmlns.rdfinference.org/ril, which is interpreted as the highest available version of RIL, or http://xmlns.rdfinference.org/ril/0/2, which is interpreted as the highest version of RIL that is lesser than version 1.0. This is in accordance with the namespace URI versioning scheme suggested by Eric van der Vlist [EV200103]
In this specification the term "RIL namespace" refers to the namespace that identifies the RIL vocabulary: http://xmlns.rdfinference.org/ril/0.1.
A set of RIL instructions to be executed in concert is written as a RIL expression. An expression comprises a list of top level instructions. An instruction may define a rule or a query, or it can call for a particular action. An instruction might optionally produce as a result value. The RIL expression itself is an instruction whose result is a list of the results of each top-level instruction.
<ril:expression id = [unique identifier] > <!-- Content: (top-level-element+) --> </ril:expression>
If a top-level element is in the RIL namespace, it must be one of the following instructions:
Any element in any other namespace is allowed at top-level element. Such elements are extension instructions, and must be handled according to the rules for extension processing.
A query allows one to request data from the RIL model.
The RIL model can be viewed as a collection of logical predicates. RIL allows a simple means of evaluating predicates for query.
Using the prolog functor syntax, a simple predicate could be represented as follows:
creator(newton)
This is a predicate of one argument. In the RIL model, this predicate is true if there exists an RDF statement with the predicate name as predicate and the predicate argument as subject. This check is done regardless of the value of the object.
So in the above example creator(newton) is is true if and only if there exists an RDF statement with predicate "creator" and object "newton". A query based on this can be represented in RIL as in listing 1.
<ril:query> <dc:creator> <ril:value>newton</ril:value> </dc:creator> </ril:query>
This query would evaluate to true given the following universe:
{b:principia, dc:creator, h:newton} {b:aljabr, dc:creator, h:kwarizmi} {b:principia, dc:date, ""}
The first statement is equivalent to the test predicate. The query can also be posed to retrieve a variable mapping rather than a plain boolean response as in listing 2.
<ril:query> <dc:creator> <ril:variable name="X"/> </dc:creator> </ril:query>
This query operating in the above universe would result in the variable X being assigned to the following list:
[h:newton, h:kwarizmi]
Using the prolog functor syntax, a predicate with two arguments could be represented as follows:
creator(newton, principia)
In the RIL model, this predicate is true if and only if there exists an RDF statement with the predicate name as predicate, the first argument as object and the second argument as subject.
So in the above example creator(newton, principia) is is true if there exists an RDF statement with subject "principia", predicate "creator" and object "newton". A query based on this can be represented in RIL as in listing 3.
<ril:query> <dc:creator> <ril:value>newton</ril:value> <ril:value>principia</ril:value> </dc:creator> </ril:query>
Which would also evaluate to true given the example universe. Listing 4 is an example of how this query can be cast so as to map values to variables.
<ril:query> <dc:creator> <ril:value>newton</ril:value> <ril:variable name="X"/> </dc:creator> </ril:query>
Using the prolog functor syntax, a predicate with two arguments could be represented as follows:
creator(newton, principia, royal-acada-sciences)
Let us say this models the natural language "The royal academy of sciences asserts that Newton was the creator of the book Principia.
In the RIL model, this predicate is true if and only if there exists a reified RDF statement with the predicate name as predicate, the first argument as object and the second argument as subject; and there is also a statement with the first reified statement itself as subject and the third argument as object.
So in the above example creator(newton, principia) is is true if there exists an RDF statement with subject "principia", predicate "creator" and object "newton"; and this statement is reified and the subject of another statement with object "royal-acada-sciences".
Issue: is this flexible enough? Furthermore, it seems to lack congruence with the method of mapping predicates of 1 and 2 artuments. Finally, it's somewhat unclear how to extend this idea congruently to predicates of 4 or more arguments.
A conjunction of RIL predicates can be expressed using the ril:and instruction. For instance listing 5 could be interpreted as the prose "Check whether uogbuji's last login was 2001-01-01 and there is a file of name 'happy-millenium.txt'".
<ril:query> <ril:and> <s:last-login> <ril:value>2001-01-01</ril:value> <ril:value>u:molson</ril:value> </s:last-login> <s:file-name> <ril:value>happy-millenium.txt</ril:value> </s:file-name> </ril:and> </ril:query>
Therefore it would return true for the following universe:
{u:uogbuji, s:last-login, "2001-01-01"} {u:molson, s:last-login, "2001-03-04"} {http://home/molson/happy-millenium.txt, s:file-name, "happy-millenium.txt"} {http://home/molson/happy-millenium.txt, s:owner, u:molson} {http://home//uogbuji/memo.doc, s:owner, u:uogbuji} {http://home/uogbuji/memo.doc, s:file-name, "memo.doc"}
A conjunction over predicates with variable mappings results in each variable's being set to a list created by selecting each list item that appears in all of the predicates.
Issue: what about repeated items, such as identical strings?
<ril:query> <ril:and> <s:last-login> <ril:value>2001-01-01</ril:value> <ril:variable name="X"/> </s:last-login> <s:file-name> <ril:variable name="X"/> <ril:value>http://home/molson/happy-millenium.txt</ril:value> </s:file-name> </ril:and> </ril:query>
The query in listing 6 made on the above universe would result in the following variable mapping:
X = [ u:molson ]
This technique can be used for predicates based on resource type.
<ril:query> <ril:and> <rdf:type> <ril:value>urn:sysadmin.net:schema#File</ril:value> <ril:variable name="X"/> </rdf:type> <s:name> <ril:value>happy-millenium.txt</ril:value> <ril:variable name="X"/> </s:name> </ril:and> </ril:query>
The query in listing 7 made on the following universe:
{u:uogbuji, rdf:type, urn:sysadmin.net:schema#User} {u:uogbuji, s:name, "Uche Ogbuji"} {u:uogbuji, s:last-login, "2001-01-01"} {u:molson, rdf:type, urn:sysadmin.net:schema#User} {u:molson, s:last-login, "2001-03-04"} {u:molson, s:name, "Mike Olson"} {http://home/molson/happy-millenium.txt, rdf:type, urn:sysadmin.net:schema#File} {http://home/molson/happy-millenium.txt, s:name, "happy-millenium.txt"} {http://home/molson/happy-millenium.txt, s:owner, u:molson} {http://home//uogbuji/memo.doc, rdf:type, urn:sysadmin.net:schema#File} {http://home/uogbuji/memo.doc, s:name, "memo.doc"} {http://home//uogbuji/memo.doc, s:owner, u:uogbuji}
would result in the following variable mapping:
X = [ http://home/molson/happy-millenium.txt ]
RIL also provides the ril:rdf-type instruction for convenience in this case. Listing 8 is equivalent to listing 7.
<ril:query> <ril:and> <ril:rdf-type id="urn:sysadmin.net:schema#File"> <ril:variable name="X"/> </ril:rdf-type> <s:name> <ril:value>happy-millenium.txt</ril:value> <ril:variable name="X"/> </s:name> </ril:and> </ril:query>
Issue: is this abbreviation necessary?
A disjunction of RIL predicates can be expressed using the ril:or instruction. For instance listing 9 could be interpreted as the prose "Check whether uogbuji's last login was 2001-01-01 or there is a file of name 'happy-millenium.txt'".
<ril:query> <ril:or> <rdf:type> <ril:value>urn:sysadmin.net:schema#File</ril:value> <ril:variable name="X"/> </rdf:type> <s:name> <ril:value>happy-millenium.txt</ril:value> <ril:variable name="X"/> </s:name> </ril:or> </ril:query>
A disjunction over predicates with variable mappings results in each variable's being set to a list created by aggregating all valued represented in each variable set by the the predicates.
A negation of a RIL predicates can be expressed using the ril:not instruction. For instance listing 10 could be interpreted as the prose "Determine whether alkwarizmi is not the creator of Principia.".
<ril:query> <ril:not> <dc:creator> <ril:value>alkwarizmi</ril:value> <ril:value>principia</ril:value> </dc:creator> </ril:not> </ril:query>
A negation over predicates with variable mappings results in a list for each variable of the possible values in the universe that did not match any child predicate of the negation, or that was not selected by any child conjunction or disjunction.
Issue: As it is, this could be a real performance pig. Do we allow variables in descendants of ril:not? Is this the right behavior in case we do? At any rate, this section needs better explanation and examples.
RIL provides a set of utility functions that can operate on partial query results for refinement.
These instructions operate on the list of statements generated as a result of their child instructions, generating a list of strings as result. They return a list constructed by iterating over each of the statements and selecting the target attribute as a separate string.
RIL provides a set of instructions to perform actions that may operate on query results.
A rule allows the user to prescribe certain actions according to the state of the target RDF model and RIL workspace.
A rule consists of a premise and a conclusion. The premise executes a series of queries, and a series of variables are assigned values according to the processing of the given queries. The conclusion executes a series of actions which usually operate on the variables set up by the premise.
A rule is made up of two parts, a premise and a conclusion. The premise is a series of RDF completes. An argument to a predicate can either be an unset skolem variable, a set skolem variable, a variable, or a constant. The predicate used in the complete is the fully qualifed name of the tag. If the premise has only argument, the argment is the subject of the complete. If the predicate has two arguments, then the second argument is the object in the complete. If an argument is not a skolem variable it must resolce to a list of strings. Each value in the list will be used in a complete. In a predicate with 2 arguments all combinations will be used. If the argument is a skolem variable the action is based on the type of predicate and wether or not the skolem variable was set in a previous predicate. If the skolem variable was not set by a previous predicate, then the skolem variable will contain the results from all of the completes. If the skolem variable was already set, then the action is dependent on the type of the predicate
One note, a not predicate cannot be evaluated if it uses a skolem variable that is un set.
Some premise examples.
Initial State of the Repository: ("user-1","title","molson") ("user-2","title","uogbuji") ("book-1","creator","user-1") ("book-2","creator","user-1") ("bool-3","creator","user-2") RIL Expression <?xml version = "1.0"?> <ril:expression xmlns:ril = "http://namespaces.rdfInference.org/ril"> <ril:rule> <ril:premise> <title> <ril:variable name='X'/> <ril:string>molson</ril:string> </title> <creator> <ril:variable name='Y'/> <ril:variable name='X'/> </creator> </ril:premise> </ril:rule> State after execution X = ['user-1'] Y = ['book-1','book-2']
More complex example
Initial State of the Repository: ("user-1","title","molson") ("user-2","title","uogbuji") ("book-1","creator","user-1") ("book-2","creator","user-1") ("bool-3","creator","user-2") ("book-1","genere","Sci-Fi") ("book-2","genere","Romance") ("bool-3","genere","Tecnical") RIL Expression <?xml version = "1.0"?> <ril:expression xmlns:ril = "http://namespaces.rdfInference.org/ril"> <ril:rule> <ril:premise> <title> <ril:variable name='X'/> <ril:string>molson</ril:string> </title> <creator> <ril:variable name='Y'/> <ril:variable name='X'/> </creator> <ril:not> <genere> <ril:string>Romance<ril:string> </genere> </ril:not> </ril:premise> </ril:rule> State after execution X = ['user-1'] Y = ['book-1']
Once all of the premises have been executed, the conclusions are evaluated. The conclusions are evaluated like all other definitions. Conclusions can contain all definitions except rules
Variable ActionsCertain actions reference and manipulate variables. RIL is a declarative language. A variable cannot be modified. If a varaibale is set and there is already a variable set with this name, a new variable will be created.
Variables can be passed in from the external world with the param tag.
<ril:param name="Foo">
The children of the param must resolve to a list. This list will be used as the default value if there is no parameter passed in
Variables can be referneced anywhere a list is expected. If a variable reference references a variable that has not been set, then an empty list will be returned.
<ril:variable-ref name="X"/>
Variables can be set to any list of strings. The children of the element must resolve to a list of strings.
<ril:variable-set name="X"/>
Assert actions are used to add content to the repository. When execution of an expression begins, the inference engine connects to the actual RDF repository and creates an in memory "temporary" repository. By default all asserts are placed in the current temporary repository. New tempoaray repositories are created and removed using the push and pop commands. The repository that the new assertion is added to can be changed with the optional depth attribute. The depth attribute is an attribute value template. If the depth is 0 or positive workspaces are indexed from the core repository (0) towards the current. If the depth is negative, repositories are referenced from the top temporary (-1) towards the core.
An assertion can take 1 or 2 arguments, both must resolve to lists of strings. In both cases the name of the tag is the predicate. In the case of only one parameter, the argument will be the subjects of the assertion and the object will always be 1. In the case of two arguments, the first argument will be the subjects, and the second argument will be the objects.
<ril:assert> <tired><ril:string>Mike</ril:string></tired> </ril:assert> Will add the following triple to the temporary repository ('Mike','tired','1')
A Double argument example
<ril:assert> <creator> <ril:string-list> <ril:string>Book-1</ril:string> <ril:string>Book-2</ril:string> <ril:string-list> <ril:string-list> <ril:string>Mike</ril:string> <ril:string>Uche</ril:string> <ril:string-list> </creator> </ril:assert> Will add the following triple to the temporary repository ('Book-1','creator','Mike') ('Book-2','creator','Mike') ('Book-1','creator','Uche') ('Book-2','creator','Uche')
Query actions are used to retrieve content from the minder. Parameters are resolved just like assertion parameters. However, skoloem variables can be used as wild card place holders
Initial state of minder ('Book-1','creator','Mike') ('Book-2','creator','Mike') ('Book-1','creator','Uche') ('Book-2','creator','Uche') The Query: <ril:query> <creator> <ril:string>Book-1</ril:string> </creator> <ril:query> The results: [('Book-1','creator','Mike'),('Book-1','creator','Uche')] The Query: <ril:query> <creator> <ril:string>Book-1</ril:string> <ril:string>Mike</ril:string> </creator> <ril:query> The results: [('Book-1','creator','Mike')]
ril:if test = "" ril:choose ril:when test = "" ril:otherwise ril:method name="" ril:call-method name = ""
ril:subject ril:predicate ril:subject ril:paths ril:reverse-paths ril:index ril:sort ril:slice ril:reverse ril:intersection ril:union
Allow variable references. Number calculations
$X > 1 $X = $Y len($X) != 3 "Foo" in $X $X + 15 < $Y
fire stop push pop depth message
Get all resources of type document
Get all documents with dc:title of "RDF 101"
Get all people with a manager named "Bob"
All books written by an author from a town in Wisconsin.
All users or developers with a manager named "Bob"
The name of the second oldest ancestor of Joe
All companies that provide a weather service that is is trusted by the UN business registry.
If there exists a person with any three of the following: e-mail address, a pager, and instant messaging account, PDA, cell phone, laptop, neural implant, then he is a geek.
If there is no pending litigation and the stock is rising and the stock has risen more than 30% in the past week, then buy.
If a person is running and out of shape or wet and not swimming, then he or she is sweating.
If an employee's attendance is in the bottom 10% percentile of the company then fire him.