Representing Facts and Rules in RDF (original) (raw)

Bridging conventional predicate representations and RDF

Graham Klyne Created: 19 July 2001
Revised: 02-Dec-2002

[[[NOTE: Work in progress]]]

This note has roots in my work with Baltimore Technologies' research group, where I was involved in designs for an RDF-driven expert system shell to experiment with applying expert system techniques to web-based RDF data [1]. While RDF on the Web may be a useful open-ended source of knowledge from which an expert system may reason, it is not obvious how to use it as a basis for defining facts and rules needed to develop, test and prime an expert system shell.

Table of Contents

1. Background

1.1 Facts

In common with many similar systems, our base facts are represented as n-place predicate functions; i.e. an asserted fact is an n-place predicate that is presumed to have the value true; e.g.

parents( Alfred, Bob, Carol )

may be used to assert that the parents of Alfred are Bob and Carol.

1.2 Rules

Rule, or inference rules, are constructs that are used to infer new facts from other facts; e.g. the inference rule:

IF parents( ?a, ?b, ?c ) AND parents( ?b, ?d, ?e ) AND parents( ?c, ?f, ?g )
THEN grandparents( ?a, ?d, ?e, ?f, ?g )

may be used to infer from:

parents( Alfred, Bob, Carol ) AND
parents( Bob, David, Ethel ) AND
parents( Carol, Fred, Gill )

the new fact:

grandparents( Alfred, David, Ethel, Fred, Gill )

For our expert system shell design, we chose a slightly richer form of rule that allows several facts to be inferred by a single rule:

IF a1 AND a2 AND ... THEN c1 AND c2 AND ....

Some work to represent rules in the Web, and in particular using XML, is being undertaken by the RuleML Initiative [2] (Rule Markup Language).

1.3 RDF

RDF is defined as a standard metadata format for the Web [4] [5]. There are several ways of looking at RDF and how it represents information (e.g. [3]). For our purposes here, these are the salient considerations:

1.4 Names: URIs and QNames

URIs have certain advantages, but they can be somewhat cumbersome to use as names. Ther XML namespace specification [8] introduces the concept of Qualified Names, or QNames, as a relatively convenient way to use URIs as identifiers. A QName consists of a prefix, a colon (':') and a local name part, where the prefix is bound separately to a namespace URI (in XML, by a namespace declaration attribute). RDF further defines that a URI is derived from a QName by concatenating the namespace URI with the local part.

In the rest of this note, QNames may be used in place of URIs, in some cases with an appropriate namespace binding assumed. A small extension to the QName format defined by the XML namespace recommendation is needed so that every URI can be represented thus; the 'LocalPart' of a QName may be empty, thus allowing QNames of the form 'prefix:'. This allows URIs that end with a non-name character to be represented in the QName format.

2. Non-RDF format for facts and rules

This section describes some formats for input and display of facts and rules that are used by the RDF expert system shell, in addition to RDF formats. The syntax description notation used here is defined in the XML specification [11].

This is a representation that is intended to be reasonably human-friendly and "scribblable". Some of the ideas are taken from N3 [9]. Subsequent sections will look at how this can be encoded in RDF.

2.1 Values, resources

Values, which in RDF are resources, are represented by a QName [8], which in turn maps to a URI of the resource value.

Value ::= QName

QName ::= Prefix ':' (LocalName)? | (':')? LocalName

LocalName ::= Name

Prefix ::= Name

Name ::= ( Letter | '_' ) (NameChar)*

NameChar ::= ( Letter | Digit | '.' | '-' | '_' )

A QName of the form 'Prefix:' maps to the URI associated with the given prefix (this is not allowed for QNames per XML namespaces [8].) A QName of the form ':LocalName' or 'LocalName' is associated with the default namespace.

Where appropriate, namespace prefixes are declared using the following syntax (adopted from N3 [9]):

PrefixDef ::= "@prefix" Name ":" URI-ref '.' | "@prefix" ":" URI-ref '.'

URI-ref ::= '<' URI-reference '>' | QName

The empty namespace name defines a default namespace.

2.2 Literals

Literal values are enclosed in double quote characters. Within a literal, any non-quote ('"'), non-escape ('\'), non-control, non-surrogate Unocode character may appear, or any of the following escape sequences:

Escape Sequence Meaning
\\ Backslash (\)
\" Double quote (")
\n ASCII Linefeed (LF)
\r ASCII Carriage Return (CR)
\t ASCII Horizontal Tab (TAB)
\u_hhhh_ Unicode character with hex value hhhh
\U_hhhhhhhh_ Unicode character with hex value hhhhhhhh

Except for the numeric escape convention, this is a subset of the literal values allowed for N3. The syntax for literals is defined as:

Literal ::= '"' LitElem* '"'

LitElem ::= LitChar | Escape

LitChar ::= Char - '"' - ''

Escape ::= '\' | '"' | '\n' | '\r' | '\t' | '\u' HexDigit HexDigit HexDigit HexDigit | '\U' HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit

HexDigit ::= [0-9a-fA-F]

// Non-control, non-surrogate UNICODE characters Char ::= [#x0020-#x007E] | [#x0080-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

2.3 Variables

Rules use variables to range over values to which the rule may be applied. The scope of a variable name is limited to the rule in which it appears. (Future developments may allow variables in the extended goal statement).

Variable ::= '?' Name

Variables may sometimes appear in facts, indicating that any value may be used in its place.

2.4 Facts

A fact is defined using a predicate form:

Fact ::= QName '(' Value ( ',' Value )* ')'

Value ::= QName | Literal | Variable

NOTE: there is no restriction here on where a literal may appear in a fact. This must be taken into account when mapping to RDF, which restricts the use of literals.

2.5 Rules

A rule contains anumber of antecedent facts and a number of consequent facts that can be inferred to be true when all of the antecedent facts are determined to be true.

Rule ::= Fact ( '&' Fact )* '->' Fact ( '&' Fact )*

NOTE: any variables that appear in an inference rule must all bind to the same value when using the rule to infer some fact. In the current use, the scope of a variable name is the rule in which it appears. Future use may create alternative variable scopes for use in goal statements.

2.6 Ranging rules over predicates

The formulation of facts and rules described above requires that the name of any predicate predicate used is explicitly named in any fact or rule; i.e. the predicate cannot be a variable.

There are some rules of inference, and other cases, where it is helpful to have a fact or part of an inference rule that can match a number of different predicates; e.g.

?p1(Item1,?val) -> ?p1(Item2,?val)

might be used to say that any binary predicate that is true of 'Item1' is also true of 'Item2'. This is not allowed under the syntax given above.

[[[For future development -- proceed with caution]]]

2.7 Goal statements

A goal statement contains a sequence of goal steps to be resolved, each of which may resolve a single goal by forward or backward chaining, or be a composite consisting of its own sequence of goal steps. In each case, the goal may be augmented by directives that direct the expert system shell how to resolve that goal. Currently, the options are forward chaining and backward chaining, but this is an area for ongoing investigation and other resolution strategy options may be added in future.

To resolve a goal (or subgoal), each of its goal steps must be resolved in turn, and any new facts inferred in the process added the the knowledge base, before proceeding to the next step. The overall process succeeds if all of the goal steps can be resolved in turn.

Goal ::= GoalStep ( ';' GoalStep )*

GoalStep ::= ( Fact ( ',' Fact )* '->' Fact | Fact | '{' Goal '}' ) ( '/' Option )*

Option ::= [[[options -- TBD]]]

NOTE: any variables that appear in an inference rule must all bind to the same value when using the rule to infer some fact. In the current use, the scope of a variable name is the rule in which it appears. Future use may create alternative variable scopes for use in goal statements.

Example:

Parents(?A,?B,?C) -> GrandParents(?A,?D,?E,?F,?G) ; Cousin(?A,?B)

Which says that the system should first forward chain from all Parents(...) facts to establish new GrandParents(...) facts, then use backward chaining from Cousin(...) to find all any cousins. This presumes that 'Cousin' is defined in terms of the 'GrandParents'. (In the context of a closed knowledge base this may offer little advantage over direct backward chaining; this composite goal facility is intended to provide hooks for further exploratory work.)

2.8 Knowledge base structure

[[[TBD -- Overall syntax for a knowedge base with facts, rules and/or goal statement]]]

[[[Add notation for import]]]

3. RDF format for facts and rules

In this section, we explore ways in which the structures described above can be coded in the standard RDF model, which consists of triples, or binary predicates.

The challenges to be addressed are:

It is important to recognize that RDF alone does not address all of these goals. It would be easy to simply encode all the facts and rules into RDF triples, and declare victory. But that overlooks an important point: the whole reason for building an expert system shell driven by RDF is to be able to leverage information from other applications that also use RDF. So the proposals below are a combinatiopn of using RDF directly, and creating encodings in RDF for new structures.

In the sections that follow, Notation 3 [9], and its derivative N-triples [12], are used to present RDF structures that would typically be represented in RDF/XML [4]. The use here of these alternative presentation formats is for legibility, and should not be interpreted as precluding the use of RDF/XML, or any other syntax for RDF.

3.1 Naming of values

A problem often encountered when looking at converting information to an RDF-based format is that the original does not use URIs for identifiying values. In such situations, it is tempting to represent the non-URI identifiers as literals. While this can work for an isolated application, it fails to take advantage of one of the great strengths of RDF, viz the potential for other RDF applications to access or add to the information thus expressed. So, to be a first-class citizen in the world of RDF appliucations, the naming format used but be based upon or mapped to a URI or equivalent form [7].

Compared with some other conventions for representing facts and rules, the structures outlined in the previous section have addressed this issue of web-friendly naming by using QNames for all value identifiers (with one small extension). Through the mechanisms of XML namespaces, these can be used with RDF, either directly or mapped to URIs depending upon context.

3.2 Dyadic ground facts

By "ground fact", we mean an assertion that uses specified values or literals, without variables.

RDF has a direct representation for dyadic ground facts: the triple. Using N-triples [12] to represent RDF constructs:

@prefix x: http://example.org/# x:p(x:s,x:o)

would map to the following N-triples statement:

http://example.org/#s 

       <http://example.org/#p>  

       <http://example.org/#o> .

3.3 Monadic ground facts

Monadic ground facts can be represented in RDF using the rdf:type property. Under this regime:

@prefix x: http://example.org/# . x:m(x:s) .

This can be represented as a dyadic form using the rdf:type predicate:

@prefix x: http://example.org/# . rdf:typw(x:s,x:m) .

which would map to the following N-triples statement:

http://example.org/#s http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://example.org/#m .

That is, the monadic predicate is presented as a type label. This convention is established in typed logic, as presented by John Sowa in section 1.3 of his book Knowledge Representation [13].

3.4 Facts of arbitrary arity

In formulating rules and knowledge bases for our expert system shell, to facilitate their construction we have not wanted to be constrained to express all facts in terms of monadic or dyadic predicates that RDF can represent directly. Thus, we have also created an encoding into RDF of arbitrary n-place facts.

NOTE: this section discusses representation of asserted facts; i.e. facts that are stated to be true. For a discussion of representing facts that are used without being asserted, as in the expression of inference rules, see section 3.5: Using facts in other expressions.

The RDF expert system shell design used the rdf:Seq container type to represent the n arguments of a predicate, but this is felt to be unsatisfactory, partly because of the quirks of RDF container types, and partly because this structure is gratuitously different from the RDF representation of dyadic predicates.

For consistency with the normal RDF representations of ground facts (see above), a format is adopted that has the form of a normal RDF statement whose subject is the first argument of the predicate on which the fact is based, whose property is the predicate, and whose object is a list of any remaining arguments. Thus, the predicate:

ex:pred( ex:subj, ex:val2, ex:val3, ... ) .

is represented in RDF (using Notation3 [9]) as something like this:

ex:subj ex:pred [ rdf:type rdf:List ; rdf:first ex:val2 ; rdf:rest [ rdf:type rdf:List ; rdf:first ex:val3 ; rdf:rest [ rdf:type rdf:List : ... rdf:rest rdf:nil ]]] .

This of facts representation uses a common representation of lists based on constructor elements that reference a head alement and a tail which is the rest of the list. It introduces a number of special resource identifiers, associated here with the namespace prefix rul:, which indicates the namespace URI <http://id.mimesweeper.com/RDFExpert/V1.0/ess#>:

Reducing to a list of RDF triples, the above list would look something like this:

@prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . @prefix ex: http://example.org/# .

ex:subj ex:pred _:genid1 . _:genid1 rdf:type rdf:List . _:genid1 rdf:first ex:val2 . _:genid1 rdf:rest _:genid2 . _:genid2 rdf:type rdf:List . _:genid2 rdf:first ex:val3 . _:genid2 rdf:rest _:genid3 . _:genid3 rdf:type rdf:List . _:genid3 ... : ... rdf:rest rdf:nil .

Thus describing a list structure something like this:

+-------+ |ex:subj| +-------+
ex:pred
+-----+-----+ | | | +-----+-----+ /
rdf:first rdf:rest /
+-------+ +-----+-----+ |ex:val2| | | | +-------+ +-----+-----+ /
rdf:first rdf:rest /
+-------+ +-----+-----+ |ex:val3| | | | +-------+ +-----+-----+ /
: :
rdf:rest
+-------+ |rdf:nil| +-------+

3.4.1 Examples of the general fact representation

This sub section gives some specific examples of facts represented using the framework described above. In each case, the non-RDF predicate form from the previous section, the standard RDF form where there is a direct representation, followed by the representation using the generic fact representation framework outlines above.

Modadic predicate

Non-RDF predicate:

@prefix ex: http://example.org/# . ex:pred( ex:subj ) .

Standard RDF/N3:

@prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . @prefix ex: http://example.org/# . ex:subj rdf:type ex:pred .

Generic fact RDF/N3:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix ex: http://example.org/# . > ex:subj ex:pred rdf:nil .

Dyadic predicate

Non-RDF predicate:

> @prefix ex: http://example.org/# . > ex:pred( ex:subj, ex:val2 )

Standard RDF/N3:

> @prefix ex: http://example.org/# . > ex:subj ex:pred ex:val2 .

Generic fact RDF/N3:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix ex: http://example.org/# . > ex:subj ex:pred [ rdf:type rdf:List ; > rdf:first ex:val2 ; > rdf:rest rdf:nil ] .

In this case, the object resource value is equivalent to a list containing just that value.

Triadic predicate

Non-RDF predicate:

> @prefix ex: http://example.org/# . > ex:pred( ex:subj, ex:val2, ex:val3 )

Standard RDF/N3:

> (No standard representation)

Standard RDF/N3:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix ex: http://example.org/# . > ex:subj ex:pred [ rdf:type rdf:List ; > rdf:first ex:val2 ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:val3 ; > rdf:rest rdf:nil ] ] .

#### 3.4.2 Statements with literal first arguments

The representation described above does not allow facts whose first argument is a literal value. The first argument is used as the RDF subject of a statement; RDF permits only resources, not literals, to be subjects.

To overcome this limitation, the following construction may be used, where required, to represent any literal value:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . > [ rdf:type rdfs:Literal ; rdf:value "Literal" ] ...

The anonymous resource in this example is equivalent to the literal string:

> "Literal" ...

but, being a resource, may be used in some contexts where RDF does not allow a literal. (NOTE: it is possible that future work will provide a standard way to treat literals as resources.)

For example, the fact:

> @prefix ex: http://example.org/# . > ex:shorterThan( "short string", "a longer string" ) .

can be represented as:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . > @prefix ex: http://example.org/# . > [ rdf:type rdfs:Literal ; rdf:value "short string" ] > ex:shorterThan "a longer string" .

or even:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . > @prefix ex: http://example.org/# . > [ rdf:type rdfs:Literal ; rdf:value "short string" ] > ex:shorterThan > [ rdf:type rdfs:Literal ; rdf:value "a longer string" ] .

### 3.5 Using non-asserted facts in expressions

The syntax outlined above allows us to assert arbitrary facts, but it does not provide us with a way to use facts as part of a larger expression without actually asserting them. This capability is needed, for example, to describe a rule.

The traditional RDF way to do this is reification, but there is currently considerable debate about what reification actually means: is it a mechanism for quoting bits of RDF, or is it a syntactic device for nesting statements without asserting them, or is it something else?

To avoid getting caught in this debate, I propose to define a separate mechanism for using facts in other expressions, but to define it in such a way that it maps directly onto RDF reification if that turns out to be the right mechanism. RDF expressions are sets of triples called statements. Everything referenced by a statement is a resource with some identity, or a literal. In order for some fact to be used in a statement, it must be given an identity, which in turn must correspond to some resource value.

To provide such a representation of a fact, the following resource identifiers, associated here with the namespace prefix rul:, which indicates the namespace URI <http://id.ninebynine.ord/RDFRules/1.0/>:

*** rul:Fact is an auxiliary data type (i.e. an rdfs:Class resource) that is applied to a resource that represents a fact.** *** rul:pred is a property that designates the predicate used by the fact..** *** rul:args is a property that designates a list of predicate arguments used in this fact.**

Given some fact represented in RDF /N3 as:

> ex:subj ex:pred [ rdf:type rdf:List ; > rdf:first ex:val2 ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:val3 ; > rdf:rest [ rdf:type rdf:List > : > ... rdf:rest rdf:nil ]]] .

A resource that represents this fact is constructed as shown in this RDF/N3 example:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rul: http://id.ninebynine.org/RDFRules/1.0/ . > @prefix ex: http://example.org/# . > > [ rdf:type rul:Fact ; > rul:pred ex:pred ; > rul:args [ rdf:type rdf:List ; > rdf:first ex:subj ; > rdf:rest _:genid1 ] ] .

where _:genid1 is the arbitrary identifier allocated to represent the tail of the predicate argument list. This might, alternatively, be described as follows:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rul: http://id.mimesweeper.com/RDFExpert/V1.0/ess# . > @prefix ex: http://example.org/# . > > [ rdf:type rul:Fact ; > rul:pred ex:pred ; > rul:args [ rdf:type rdf:List ; > rdf:first ex:subj ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:val2 ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:val3 ; > rdf:rest [ rdf:type rdf:List > : > ... rdf:rest rdf:nil ]]]]] .

If RDF reification turns out to have a similar interpretation that provides a syntactic device for nesting, the first construction might be re-written as:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rul: http://id.ninebynine.org/RDFRules/1.0/ . > @prefix ex: http://example.org/# . > > [ rdf:type rdf:Statement ; > rdf:predicate ex:pred ; > rdf:subject ex:subj ; > rdf:object _:genid1 ] .

which corresponds to a straight reification of the first statement in the original fact.

[[[Need to check that RDF ground facts are always clearly distinguished without having to know how they are referenced.]]]

### 3.6 Representation of rules

The basic structure of a rule that we use is a set of antecedent facts and a set of consequent facts. A rule also provides a scope for any variables that appear in the facts (see below).

The rule:

> Afact1 & Afact2 & ... -> Cfact1 & Cfact2 & ... .

is represented in RDF (using Notation3 [9]) as something like this:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rul: http://id.ninebynine.org/RDFRules/1.0/ . > > @prefix ex: http://example.org/# . > [ rdf:type rul:Rule ; > rul:from Afact1 ; > rul:from Afact2 ; > ... > rul:infer Cfact1 ; > rul:infer Cfact2 ; > ... ] .

This representation of rules introduces some new resource identifiers, associated here with the namespace prefix rul:, which indicates the namespace URI <http://id.mimesweeper.com/RDFExpert/V1.0/ess#>:

*** rul:Rule is an auxiliary data type (i.e. an rdfs:Class resource) that describes a resource that represents a rule.** *** rul:from is a property that designates a resource that represents an antecedent fact of the rule, one of the facts from which inferences may be drawn. See the previous section for construction of such resources. This property is repeated for each antecedent fact of the rule.** *** rul:infer is a property that indicates a conclusion fact that may be inferred if all of the antecedent facts are true. See above for construction of such resources. This property is repeated for each conclusion fact of the rule.**

Thus, the following rule in non-RDF form:

> ex:a1( ex:a1s, ex:a1v2, ex:a1v3 ) & > ex:a2( ex:a2s, ex:a2v2 ) -> > ex:c1( ex:c1s, ex:c1v2, ex:a1v3 ) & > ex:c2( ex:c2s ) .

would be represented in RDF/N3 as:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rul: http://id.ninebynine.org/RDFRules/1.0/ . > > @prefix ex: http://example.org/# . > > [ rdf:type rul:Rule ; > rul:from _:genid1 ; > rul:from _:genid2 ; > rul:infer _:genid3 ; > rul:infer _:genid4 ] . > > _:genid1 rdf:type rul:Fact ; > rul:pred ex:a1 ; > rul:args [ rdf:type rdf:List ; > rdf:first ex:a1s ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:a1v2 ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:a1v3 ; > rdf:rest rdf:nil ]]] . > > _:genid2 rdf:type rul:Fact ; > rul:pred ex:a2 ; > rul:args [ rdf:type rdf:List ; > rdf:first ex:a2s ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:a2v2 ; > rdf:rest rdf:nil ]] . > > _:genid3 rdf:type rul:Fact ; > rul:pred ex:c1 ; > rul:args [ rdf:type rdf:List ; > rdf:first ex:c1s ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:c1v2 ; > rdf:rest [ rdf:type rdf:List ; > rdf:first ex:c1v3 ; > rdf:rest rdf:nil ]]] . > > _:genid4 rdf:type rul:Fact ; > rul:pred ex:c2 ; > rul:args [ rdf:type rdf:List ; > rdf:first ex:c2s ; > rdf:rest rdf:nil ] .

...

### 3.7 Variables and variable scope

So far, the discussion of fact and rule representation in RDF has avoided issue of variables. But, for rules in particular, some concept of a variable is needed if the rule is to have a useful expressive power.

A variable is an identifier that represents some value, but which, unlike a URI, may stand for different values when used in different contexts or in different invocations. For example, the rule:

> parents( ?a, ?b, ?c ) & > parents( ?b, ?d, ?e ) & > parents( ?c, ?f, ?g ) -> grandparents( ?a, ?d, ?e, ?f, ?g )

Can be invoked for any collection of three facts that simultaneously match the rule antecedents; for each such set of facts, the variables will, in general, be bound to different values.

When a variable appears in a fact that is part of a rule, the scope of the variable is the containing rule. That is, all occurrences of a given variable that appear within the rule are required to bind to the same value in any single invocation of the rule.

[[[TBD -- scoping rules for variables in other contexts]]]

A variable is represented by a resource of type rul:Var, and having an rdfs:label property that is the literal name of the variable. Thus, the fact:

> ex:Parents( ?a, ?b, ?c ) .

might be represented in RDF/N3 as:

> @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . > @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . > @prefix rul: http://id.ninebynine.org/RDFRules/1.0/ . > > @prefix ex: http://example.org/# . > > _:genid1 ex:Parents [ rdf:type rdf:List ; > rdf:first _:genid2 ; > rdf:rest [ rdf:type rdf:List ; > rdf:first _:genid3 ; > rdf:rest rdf:nil ] ] . > > _:genid1 rdf:type rul:Var ; > rdfs:label "?a" . > > _:genid2 rdf:type rul:Var ; > rdfs:label "?b" . > > _:genid3 rdf:type rul:Var ; > rdfs:label "?c" .

The identity (uniqueness) of a variable is bound to the resource that represents it, not to its name. The variable name may be used (in conjunction with scoping rules) as a syntactic device for deciding which variable occurrences refer to the same variable, and hence which at any instant or invocation must correspond to the same value. Occurrences of the same variable name within a rule is an example of multiple occurrences of the same variable.

### 3.8 Facts containing variables

An asserted fact with a variable argument generally asserts a truth for any value of that argument. But if more than one fact use the same variable (in the sense of the same variable resource discussed above, not just the same name) than the truth of those facts for a particular value of a variable must be asserted simultaneously; e.g.

> personSays(?x) . > > parrotSays(?x) .

might be interpreted to assert that a person, or a parrot have said any possible utterance. But these two facts alone cannot be used to assert that the person has said one thing, and the parrot has said something different.

This is a very arcane point, and should not be a general concern if reasonable syntactic variable scoping rules are applied. The point is made here simply as a caution against careless use of variables in assertions.

### 3.9 Representation of goal statements

A goal statement has a fairly complex structure, which is expected to evolve as the RDFexpert system develops.

For now, the following basic structures are defined:

*** rul:GoalStmt is a resource type that stands for a goal statement, being a subclass of rdf:List. A goal is thus represented as a list of rul:GoalStep values, using rdf:first and rdf:rest properties to reference the list members.** *** rul:GoalStep is a resource type that represents one of a sequence of goals that is to be resolved. Specific goal step types are suptypes of this: rul:GoalFWD, rul:GoalBWD or rul:GoalStmt.** *** rul:GoalFWD is a subtype of rul:GoalStep that represents a goal step to be resolved by forward chaining from a specified set of facts. One or more rul:from properties are used to indicate rul:Fact patterns of existing facts from which forward chaining is performed. An rul:goal property is used to indicate the goal to be satisfied by this step. Optional rul:option properties may indicate resolution options that are to be applied for this step.** *** rul:GoalBWD is a subtype of rul:GoalStep that represents a goal step to be resolved by backward chaining. An rul:goal property is used to indicate the goal to be satisfied by this step. Optional rul:option properties may indicate resolution options that are to be applied for this step.** *** rul:goal is a property that indicates a subgoal to be satisfied by a goal step. The value of this property is an rul:Fact resource.** *** rul:option is a property that indicates an option to be applied for a goal step. Currently, no options are defined.**

[[[To be developed further]]]

...

---

## 4. References

[1]

RDF driven expert system shell project: http://public.research.mimesweeper.com/RDF/RDFExpert/Intro.html

[2]

RuleML initiative home page: http://www.dfki.uni-kl.de/ruleml/

[3]

RDF brief introduction: http://www.ninebynine.org/RDFNotes/RDFBriefIntroduction.htm

[4]

RDF Model and Syntax specification: http://www.w3.org/TR/REC-rdf-syntax

[5]

RDF Schema specification: http://www.w3.org/TR/rdf-schema

[6]

RDF2396, Uniform Resource Identifiers (URI): Generic Syntax: ftp://ftp.isi.edu/in-notes/rfc2396.txt.

[7]

Tim Berners-Lee, comments on webizing applications: http://www.w3.org/DesignIssues/Webize.html

[8]

Namespaces in XML: http://www.w3.org/TR/REC-xml-names/.

[9]

Notation 3: http://www.w3.org/DesignIssues/Notation3.html

[10]

Extensible Markup Language (XML) 1.0 (Second Edition): http://www.w3.org/TR/REC-xml.

[11]

Syntax notation in XML specification: http://www.w3.org/TR/REC-xml#sec-notation.

[12]

N-triples format specification: http://www.w3.org/2001/sw/RDFCore/ntriples/.

[13]

John F. Sowa, Knowledge Representation; Logical, Philosophical and Computational Foundations, Brookes Cole (2000), ISBN 0 534-94965-7.

...

---