Contexts for Information Modelling in RDF

10/10/00

D:\Ctech\Activities\WTFI2\rdfcontexts.sdw

21:25:54



Contexts for RDF Information Modelling

Graham Klyne
Content Technologies Ltd

This memo describes some experimental work that is being undertaken with the goal of simplifying the application of RDF to a number of information modelling problems, particularly involving relationships between physical-world objects and trust modelling. It is our goal that, by using contexts, a degree of modularity can be introduced that will ease the construction of RDF information models.

Created: 31 August 2000
Revised: 18 October 2000
Status: draft for discussion





1. Introduction

As a mechanism for representing information, RDF [1], [2] is very general, but very primitive. It might be viewed as a kind of “assembly language” for knowledge and metadata representation. There are some metadata applications, such as adding properties to web pages, for which basic RDF is well suited. But there are others, particularly describing detailed relationships between physical-world objects, where one soon becomes lost in a tangle of graph nodes and edges, loosing sight of the overall structure of the information.

The above conclusion was reached when trying to model configuration and interworking options between a number of computer system components. Despite repeated simplifications of the problem, we kept on running out of whiteboard space to contain the RDF graph of our chosen problem. Assembly language programmers soon adopted the notion of subroutine --grouping instructions into separate, understandable, interacting pieces-- to construct programs consisting of very many primitive instructions. It is a thesis of this proposal that the idea of “contexts” can perform a similar function for information modelling in RDF.

What are the kinds of problem we hope to address using contexts? Some are:

1.1 Document conventions

We shall use the namespace prefix ‘rdfc:’ for RDF classes and properties that are used to represent container and context information. RDF classes are given names starting with an upper case letter, RDF properties with lower case.

In describing RDF statements, square brackets are used to denote RDF resources, containing a name for the resource, or quoted strings to describe literal object values. Specific resource identifiers may be replaced by the expected rdf:Type of the resource in angle brackets. Thus, a general RDF statement might be described as:

[SubjectName] --propertyName--> [ObjectName]

or:

[<rdfs:Resource>] --<rdf:Property>--> [<rdfs:Resource>]

See also Appendix B: Enhanced RDF notation, and also the further notations introduced in section 3 on Statement sets.

NOTE: Explanatory comments like this are not a core elements of this proposal, but are included to provide background rationale about why a particular approach is adopted.

1.2 Terminology

Statement set: a collection of reified statements, whose container is represented as an RDF resource.

Context: a statement set, with additional properties capturing certain structural and logical properties associated with contexts, described in this document.

Lifting rule: any rule that allows us to deduce that truth of some statement in a context from the truth of another statement in a related context.

2. About contexts

The idea of contexts was proposed by McCarthy [6], [3], and some theory and applications were developed in some detail in by R. V. Guha in his PhD thesis [4].

A context is characterized by the fundamental relationship ‘is true in’, or ‘ist’, where:

[Statement] --ist--> [Context]

means that [Statement] is true in [Context]. A context may be taken to be some environment within which some statements are held to be true. Thus, to use a statement in some chain of reasoning, one must determine (or assume) that a context that the statement ‘is true in’ applies to the circumstances of that reasoning.

Guha [4] describes a context as ‘defining its own language’, in the sense that it establishes a framework of meaningful expressions based on first order logic. For the purposes of modelling with RDF, the first order logic is replaced by the structure of basic RDF assertions, possibly taken together with some specified RDF properties and associated set of rules that define a language and deductive framework for that context. Tim Berners-Lee describes in The Semantic Toolbox [5] one possible form of RDF properties and associated rules to describe first order logic.

Thus, RDF provides the basic vocabulary and grammar for representing assertions associated with contexts, and RDF schema may be used to impose constraints on the way that the vocabulary is used, but rules of logical deduction associated with a context (beyond the minimal rules defined by RDF) need to be established by external means.

Another key feature of contexts is the idea of ‘lifting rules’ or ‘lifting axioms’: rules to deduce the truth of statements in one context from the truth of statements in some other context. In the absence of applicable lifting axioms, such deductions are not typically valid. I envisage that the topic of lifting between RDF contexts can be approached gradually, through the introduction of specific types of relationship between contexts, rather than adopting a fully generalized theory of lifting.

McCarthy [3] states that a context is an ‘abstract object’. This suggests that one can make assertions about contexts as well as within contexts. He also describes a context as “a generalization of a collection of assumptions”. These assumptions may concern the vocabulary and language used as well as the statements being assumed; not all such assumptions may be explicitly known. We return later to this idea of context-as-assumptions.

McCarthy [3] points out that, in order to work within a framework of first order logic, we need to reify statements to associate them with contexts. RDF provides a mechanism for reification of statements, but it tends to be cumbersome. For the purpose of discourse, I shall use a notation for RDF in which reification is implicit; see Appendix B: Enhanced RDF notation. (Implementations are, in any case, free to use any appropriate optimizations for their internal representation.).

2.1 Representation of contexts in RDF

So, what is a context represented in RDF? We can say:

2.2 Approach to contexts in RDF

In the remainder of this paper, contexts are approached at three levels:

  1. A collection of reified statements – a “statement set”.

  2. RDF classes and properties that convey context-specific structural information

  3. RDF properties that convey context-specific logical properties

3. Statements sets in RDF

RDF defines a way to represent collections of statements which suffers from some practical difficulties:

[[[The final two points above may not be strictly true, but if not it is not clear how to use standard RDF to obtain the effects described.]]]

3.1 A general container for sets of resources

We define here a container class and property that overcomes the above problems when used for statement sets:

Thus, we have:

[Container] -–rdf:type-----> [rdfc:Set]
[         ] --rdfc:member--> [SomeResource]
[         ] --rdfc:member--> [AnotherResource]
[         ]       :
                 etc.

Note that, unlike the standard RDF container classes, this structure does not permit repeated instances of the same resource or value in an rdfc:Set container.

To maximize compatibility with RDF schema [2]:

3.2 Statement sets

Building on the generic set container described above, a statement set and membership thereof are represented by:

Thus, we have:

[SS] -–rdf:type-----> [rdfc:StatementSet]
[  ] --rdfc:quotes--> [SomeStatement]
[  ] --rdfc:quotes--> [AnotherStatement]
[  ]       :
          etc.

3.3 A notation for statement sets

The notation used above requires that an explicit identifier be allocated for each reified statement that is included in a statement set. Sometimes, we wish to simply state that the reified form of some given statements is contained in a statement set.

The following notation is introduced for this purpose:

[StatementSet] --rdfc:quotes-->
  {
  [Sub1] --prop1--> [Obj1]
  [Sub2] --prop2--> [Obj2]
   :
  (etc.)
  }

This is interpreted to mean that the reifications of “[Sub1] --prop1--> [Obj1]” and “[Sub2] --prop2--> [Obj2]”, etc., are quoted by [StatementSet].

The above expression can be expressed using the quadruple notation of appendix B:

S1:   [Sub1] --prop1--> [Obj1]
S2:   [Sub2] --prop2--> [Obj2]
       :
      (etc.)

[StatementSet] --rdfc:quotes--> [S1]
[StatementSet] --rdfc:quotes--> [S2]
 :
(etc.)

This notation is not limited to the rdfc:quotes property: using this notation, any property may be repeated over the reifications of statements the braces.

4. RDF elements for contexts

Here, we introduce a class and some properties used to describe a Context, which is a statement set with some additional structural and logical properties.

Thus, we have:

[SomeContext] -–rdf:type------> [rdfc:Context]
[           ] --rdfc:asserts--> [SomeStatement]
[           ] --rdfc:asserts--> [AnotherStatement]
[           ]       :
                   etc.

The rdfc:quotes property may be used with an rdfc:Context: when used, it means that the indicated reified statement is included in the set of statements comprising the context, but is not asserted by the context. This is needed if the context makes statements about other statements that are not themselves held to be true; e.g. “Graham says ‘the sheep is pink’” might be represented as:

[A] -–rdf:type------> [rdfc:Context]
[ ]
[ ] --rdfc:asserts--> [ ] -–rdf:type-------> [rdf:Statement]
[ ]                   [ ] --rdf:subject----> [Graham]
[ ]                   [ ] --rdf:predicate--> [says]
[ ]                   [ ] --rdf:object-----> [B]
[ ]
[ ] --rdfc:quotes---> [B] –-rdf:type-------> [rdf:Statement]
[ ]                   [ ] --rdf:subject----> [The sheep]
[ ]                   [ ] --rdf:predicate--> [colour]
[ ]                   [ ] --rdf:object-----> [pink]

NOTE: it might be questioned whether non-asserted statements actually belong in a context. One of the motivations for this work is to have a way to collect together related parts of an RDF graph, so this has been adopted as a helpful idea.

4.1 Asserting statements in different contexts

Some statements and their association with two different contexts may be expressed by the following RDF (enhanced notation) model:

s1:   [MyPage] ------author--------> “Graham Klyne”
s2:   [MyPage] ------status--------> “My personal opinions”
s11:  [GKBelieves] --rdfc:asserts--> [s1]
s12:  [GKBelieves] --rdfc:asserts--> [s2]
s21:  [GKAssures] ---rdfc:asserts--> [s1]
s22:  [GKAssures] ---rdfc:asserts--> [s2]

Note that a statement may be marked to be true in any number of different contexts. Thus, the rdfc:asserts property may be applied any number of times using a given statement. Naturally, any number of statements may be by a given context: this kind of grouping of statements into larger units is one of the driving motivations for this proposal.

Later, we explore extending the range of rdfc:asserts to allow certain relationships between contexts to be expressed.

5. Using contexts: logical constructs

So far, RDF elements have been introduced to represent statement sets and contexts, and to describe the essential structures relating them and (reified) statements.

In this section, we explore some ways contexts can be used to organize information, and use these explorations to suggest additional constructs to express some logical properties of contexts.

5.1 Contexts as containers

The most obvious use of a context is as a container for some collection of statements. An RDF document may contain a number of statements. Assertions applied to the document might be taken to apply to each of the statements contained in the document.

For example, a signature applied to a document creates some kind of assurance about the content of that document. This assurance would reasonably be considered to apply to each of the statements within the document. To apply such assurances individually to each statement seems cumbersome, especially given the fine-grained nature of individual RDF statements. Thus, we have one application for contexts that is to facilitate making assertions about collections of statements.

5.1.1 A possible approach

One might imagine saying that any properties applied to a context are taken to be equivalent to applying the same properties (and values) individually to each of the reified statements that hold for that contexts. Then:

s1:   [MyPage] -----author---------> “Graham Klyne”
s2:   [MyPage] -----status---------> “My personal opinions”
s3:   [GKContext] --rdfc:asserts---> [s1]
s4:   [GKContext] --rdfc:asserts---> [s2]
s5:   [GKContext] –-assuredBy------> “Graham Klyne”
s6:   [GKContext] -–assuredBy------> “Independent”

would be interpreted to imply:

s1:   [MyPage] --author-----> “Graham Klyne”
s2:   [MyPage] --status-----> “My personal opinions”
a1:   [s1] ------assuredBy--> “Graham Klyne”
a2:   [s2] ------assuredBy--> “Graham Klyne”
a3:   [s1] ------assuredBy--> “Independent”
a4:   [s2] ------assuredBy--> “Independent”

5.1.2 A preferred approach

The simple approach described above conflicts with other possible uses for contexts, so we propose a level of indirection that makes more explicit the distribution of assertions over the contained statements. This follows the idea of ‘interpretation properties’ described by Tim Berners-Lee [7]. In this case, the proposed ‘interpretation property’ is one that explicitly applies the properties to all of the contained statements:

s1:   [MyPage] -----author-----------> “Graham Klyne”
s2:   [MyPage] -----status-----------> “My personal opinions”
s3:   [GKContext] --rdfc:asserts-----> [s1]
s4:   [GKContext] --rdfc:asserts-----> [s2]
s5:   [GKContext] --rdfc:applyToAll--> [_stmt]
s5:   [_stmt] ------assuredBy--------> “Graham Klyne”
s6:   [_stmt] ------assuredBy--------> “Independent”

Here rdfc:applyToAll indicates that all properties applied to the object resource are to be applied individually to each statement that holds in the subject context; [_stmt] is a local place-holder resource of implied type rdf:Statement.

NOTE: rdfc:applyToAll is presented here as a one-off case for use with contexts. Appendix A generalizes this idea to be applicable to an arbitrary container class.

NOTE: This is an alternative way to model statements about statements than that described in the RDF Model and Syntax [1], section 4.2. A significant difference is that this approach represents the distributed referent structure within the RDF graph, and therefore can be applied to context statements possibly not available when the RDF is de-serialized.

5.2 Contexts as statements

As noted previously, McCarthy has described a context as “a generalization of a collection of assumptions”. This suggests that asserting the applicability of a context is equivalent to asserting the assumptions that it contains. Some of those assumptions may be explicitly stated.

In this respect, a context may assume some of the attributes of a statement: it may be regarded as true or false (or unknown) in the sense that the assumptions that it embodies are all true, or otherwise. Its truth (or otherwise) may depend upon the applicability of some other context. The kinds of metalogical operations that apply to statements (conjunction, implication, negation, etc.) could be usefully applied to contexts, treating a context as a kind of composite statement. It could even make sense to combine statements and contexts in metalogical expressions.

Treating contexts as statements in this way, the rdfc:asserts property could be interpreted thus:

[Context] --rdfc:asserts--> [Statement]

meaning:

[Context] implies [Statement]

That is, if the set of assumptions, implicit and explicit, contained in a context are held to be true then, by implication, any statement asserted by the context must also be true.

These considerations suggest some new constructs for using contexts:

  1. a way to indicate explicitly known assumptions that are engendered by a context,

  2. a way to indicate that one context is subsumed by another context, and

  3. a class for the properties that contexts and statements have in common.

5.2.1 Representing explicit assumptions

The property rdfc:assumes can be used to indicate explicitly stated assumptions for a context. The assumption might be represented as a single rdf:Statement, or as an rdfc:Context in which case all of the statements that are explicitly assumed by the object context are also assumed in the subject context.

[<rdfc:Context>] --rdfc:assumes--> [<rdf:Statement>]

or

[<rdfc:Context>] --rdfc:assumes--> [<rdfc:Context>]

By asserting the RDF statements assumed by one context, one might try to deduce that all statements asserted by that context are also true in the referencing context. But not all assumptions are necessarily stated explicitly, so this deduction is not generally valid. Thus, a distinction must be made between the explicit assumptions associated with a context, and the statements that are asserted to be true. Assertions in one context do not necessarily carry over with the explicitly stated assumptions -- see the next section.

5.2.1.1 Example

For an example, let us expand on two contexts introduced by John McCarthy [3]:

  1. SHS: “Sherlock Holmes Stories”, in which “Holmes” is a detective.

  2. USL: “U.S. Legal History”, in which “Holmes” is a Supreme Court justice.

Then, we have in the first context::

[ ] --rdf:type--> [Person]
[ ] --surname---> “Holmes”
[ ] --isa-------> “detective”

And in the second context:

[ ] --rdf:type--> [Person]
[ ] --surname---> “Holmes”
[ ] --isa-------> “justice”

Introduce a third context:

  1. LAO: “Law and Order”, in which it is explicitly assumed that (a) detectives solve crimes, and (b) justices sit in court. It is implicitly assumed that this context refers to characters in real life rather than finction, so let this context also assert that justices are well-paid, and detectives are poorly paid.

Finally, let us assume that the “Law and Order” context is explicitly assumed by the other two contexts.

Expressing this as extended RDF quadruples (see Appendix B):

S1:   [Anon(1)] --rdf:type--> [Person]
S2:   [Anon(1)] --surname---> “Holmes”
S3:   [Anon(1)] --isa-------> “detective”
S4:   [Anon(1)] --isa-------> “justice”

S5:   [Anon(2)] --isa-------> “detective”
S6:   [Anon(2)] --does------> “solve crimes”
S7:   [Anon(2)] --pay-------> “low”

S8:   [Anon(3)] --isa-------> “justice”
S9:   [Anon(3)] --does------> “sit in court”
S10:  [Anon(3)] --pay-------> “high”

C11:  [SHS] --rdf:type------> [rdfc:Context]
C12:  [SHS] --rdfc:asserts--> [S1]
C13:  [SHS] --rdfc:asserts--> [S2]
C14:  [SHS] --rdfc:asserts--> [S3]
C15:  [SHS] --rdfc:assumes--> [LAO]

C21:  [USL] --rdf:type------> [rdfc:Context]
C22:  [USL] --rdfc:asserts--> [S1]
C23:  [USL] --rdfc:asserts--> [S2]
C24:  [USL] --rdfc:asserts--> [S4]
C25:  [USL] --rdfc:assumes--> [LAO]

C31:  [LAO] --rdf:type------> [rdfc:Context]
C32:  [LAO] --rdfc:assumes--> [S5]
C33:  [LAO] --rdfc:assumes--> [S6]
C34:  [LAO] --rdfc:asserts--> [S7]
C35:  [LAO] --rdfc:assumes--> [S8]
C36:  [LAO] --rdfc:assumes--> [S8]
C37:  [LAO] --rdfc:asserts--> [S8]

(Note the use of anonymous resources to make assertions about a person designated by associated properties, rather than by formal identifier. NOTE: LAO really needs a way to express universal quantification and implication here. Also note, the statements C15 and C25 make use of a feature introduced in section 5.2.3 below.)

S1-S10 are simply statements. No claim is made here that they are true, or even consistent (which they clearly are not).

C11-C14 introduce a context identified as SHS in which it is asserted that there is a person whose surname is Holmes and who is a detective. C15 indicates that the explicit assumptions of the context LAO (“Law and Order”) are also assumptions of SHS.

C21-C24 introduce a context identified as USL in which it is asserted that there is a person whose surname is Holmes and who is a justice. C25 indicates that the explicit assumptions of the context LAO (“Law and Order”) are also assumptions of USL.

Finally, C31-C37 introduce the explicit assumptions and assertions of context LAO.

Thus, we have the context of “Sherlock Holmes stories” assuming the (explicit assumptions of the) “Law and order” context, from which we may deduce that Holmes solves crimes. But we cannot deduce that Holmes is poorly paid because there is an implicit assumption of the “Law and order” context that it describes non-fictional people.

5.2.2 Subsuming contexts

The property rdfc:asserts can be used to describe one context being subsumed by another; i.e. all assumptions and statements from one context being taken in to the other:

[Context1] --rdfc:asserts--> [Context2]

is interpreted as meaning that Context1 subsumes Context2; i.e. every assumption made by Context2 is also taken to be an assumption in Context1, and every statement asserted in Context2 is also asserted in Context1.

Interpreting rdfc:asserts as a logical implication:

[Context1] implies [Context2]

i.e. from the thruth of Context1 we can deduce the truth of Context2.

This leads us to consider what it means for a context (as opposed to a statement) to be true. The definition offered here is:

Definition: a context is true iff all of the explicit and implicit assumptions of that context are true. Then, by implication, if a context is true then all statements true in it are also held to br true.

5.2.2.1 Example

Returning to the example of section 5.2.1.1, consider that the description of context USL is re-stated so that the “Law and order” context is asserted bu the “US legal history” context:

C21:  [USL] --rdf:type------> [rdfc:Context]
C22:  [USL] --rdfc:asserts--> [S1]
C23:  [USL] --rdfc:asserts--> [S2]
C24:  [USL] --rdfc:asserts--> [S4]
C25:  [USL] --rdfc:asserts--> [LAO]

In this case, we might deduce that Holmes is well paid because all the implicit and explicit assumptions, and hence the stated assertions, of the LAO context are subsumed into the USL context.

5.2.3 A unifying class for contexts and statements

The preceding discussion illustrates a motive to use statements and contexts interchangeably, when a context is being used to represent some collection of statements or assumptions. Defining one as a subclass of the other is not satisfactory because each has properties not shared by the other. (A statement has a very specific structure and relationship to the RDF model; a context can be used in ways not applicable to a statement.)

Instead, the class rdfc:Assertion is defined to be a superclass of both rdf:Statement and rdfc:Context. Where a statement or a context may be used as the domain or range of some property, this can be described using the rdfc:Assertion class.

These ideas are captured very easily by redefining the range of rdfc:asserts and rdfc:assumes to include contexts. The old range values allowing statements of the form:

[<rdfc:Context>] --rdfc:asserts--> [<rdfc:Statement>]
[<rdfc:Context>] --rdfc:assumes--> [<rdfc:Statement>]

Are changed so that the rdfc:asserts and rdfc:assumes properties might be used in statements of the form:

[<rdfc:Context>] --rdfc:asserts--> [<rdfc:Assertion>]
[<rdfc:Context>] --rdfc:assumes--> [<rdfc:Assertion>]

Where rdfc:Assertion can be an rdf:Statement or an rdfc:Context.

5.2.3.1 Example

          An example of this usage can be found in statements C15 and C25 of the example in section 5.2.1.1.

5.3 Contexts as resources

One of the great difficulties that has been observed in trying to use RDF to model real world situations is that it is very difficult to construct a model of meaningful complexity without becoming utterly lost in the details of the RDF graph. The idea of contexts as containers leads quite naturally to a treatment of contexts as first class resources in their own right, representing the collection of statements describing some physical-world object. Further, the idea of contexts as statements (introduced above) suggests that the statements contained within a context might themselves be contexts.

Using these ideas, we can construct high-level models in terms of high-level resource and property concepts. The validity or consequences of these high-level relationships can be discovered by looking inside the corresponding contexts to find the component parts and the local interactions between them.

Consider the example of equipment power supplies mentioned previously. At the highest level, one might model three components:

[MainsSupply]
[PowerSupplyUnit]
[Equipment]

These could be related as follows:

[MainsSupply] ------supplyTo--> [PowerSupplyUnit]
[PowerSupplyUnit] --supplyTo--> [Equipment]

To examine the validity of each of these relationships, we need to look to the component features of each part.

[MainsSupply] might contain assertions corresponding to output voltage, supply current capability, AC or DC, supply quality, connector type, etc.

[PowerSupplyUnit] might contain components [MainsInput] and [EquipmentOutput]. The [MainsInput] component would itself contain assertions that must be compatible with the [MainsSupply] context associated with the supplyTo property. Similarly, the [EquipmentOutput] property would contain assertions that must be compatible with the [Equipment] value indicated.

Some initial exercises have suggested that using contexts in this way very greatly improves our ability to design models for related physical world objects.

5.4 Contexts as languages

McCarthy and Guha both allow that different contexts may contain different linguistic assumptions; that a given symbol or name or string may have a different meaning in different contexts. To this extent, a context embodies a language (or at least some linguistic elements). The extent to which the linguistic constructs of one context are valid in another context depends crucially on the relationship between those contexts. If there is no (known) relationship then the corresponding statements are not usefully combined. When contexts are closely related, we can hope to map the linguistic constructs from one to another.

What is meant here by “language”? Language consists of:

With RDF, every resource and every property is identified by a URI (or, strictly, a URI-reference). Most URIs are expected to be globally unique, or unique within the environment within which they are used. The basic rules of construction are defined by the RDF model.

Thus, the linguistic elements that are associated with a context would seem to be limited to the framework of logic used. RDF has been explicitly defined to not impose or define any single system of logic on statements that it represents; using a context to associate a particular system of logic used with statements seems to be a useful idea.

Defining any such logic is, by its nature, outside the scope of current RDF so associating a logic with a context would seem to be likewise something that must be defined separately. This might be treated as one of the implicit assumptions of a context. (For example, see Tim Berners-Lee’s Semantic Toolbox [5].)

5.5 Contexts as frames (local name binding)

The discussion above suggests that the global nature of URIs means that the language element of a context does not need to include a context-dependent vocabulary. Our experience in trying to construct models of real systems seems to suggest that some kind of “local variable” facility seems to be desirable.

For example, if I want to use a context to collect the statements describing “my car”, some resources may be needed to stand for parts of my car, such as “the chassis”, “the engine”, “the registration, etc., used as subjects of statements that describe my car.

One way to do this, used in the example in section 5.2.1.1, is to introduce anonymous resources whose properties constitute a “definite description” [9]. In some circumstances, this approach seems rather cumbersome when access to some resource denoted by a “surrounding” or referencing context more simply achieves the same end.

For example, I may wish to describe “my car” as a “Ford Escort”, and have many of its properties defined by statements in a common context describing that kind of car. But if the generic description of a Ford Escort uses global URIs, they cannot apply to my car, and also some other car that also happens to be a Ford Escort.

Contexts can overcome this problem by allowing certain names to have meaning that is defined by the nesting of contexts within which the name-use occurs. Within an RDF context, such names must ultimately stand for a URI reference, but allowing a local name to stand for different URI-references when used in different contexts (or in contexts referenced by different contexts).

Here is an illustration of some of these ideas:

[MyCar] --isa--> [FordEscort]
[     ] --rdfc:asserts-->
  {
  [TheBody] ----color-----> “red”
  [TheEngine] --capacity--> “1600cc”
  }

[FordEscort] --asserts-->
  {
  [TheBody] ----material---> “steel”
   :
  [TheEngine] --cylinders--> “4”
  [         ] --valves-----> “8”
   :
  (etc.)
  }

When [MyCar] references [FordEscort], the desired effect is that references to [TheBody] and [TheEngine] become descriptions of those components of [MyCar], rather than some other car that happens to be a Ford Escort.

[[[Mechanisms for name binding to be researched/defined/evaluated]]]

[[[Anonymous resources?]]]

5.6 Relationships between contexts

Here, we examine some ways in which contexts may be related. Such relationships may define how assertions can be ‘lifted’ from one context to another.

5.6.1 Specialization of context

Some context Context2 may be regarded as a specialization of Context1 if every statement true in Context1 is also true in Context2, and there may be further assertions that are true in Context2 but not in Context1. This can be expressed by an rdfc:asserts relationship:

[Context2] --rdfc:asserts--> [Context1]

indicates that Context2 is a specialization of Context1, assuming both employ compatible language.

(This is an instance of subsuming contexts -- see above.)

5.6.2 Component of context

A context as a component of another context has been discussed above. A context as a component of another context is expressed by an rdfc:asserts relationship:

[Context1] --rdfc:asserts--> [Context2]

indicates that Context2 is a component of some larger set of assertions from Context1, assuming both employ compatible language. This is equivalent to saying that the containing context is a specialization of the component (see above), which is reasonable as the component is placed into a specified usage.

5.6.3 Projection of context

Projection is the general case of the kind of relationship described by McCarthy [3] as specialize-time. It involves assuming a value or values in one context that are not specified in a more general context. As such, statements that are true in the projected context cannot be asserted in the more general context unless the assumed value is also mentioned. In conventional first order logic frameworks, this is achieved by changing the arity of a predicate so that the assumed value is stated explcitly in the more general context; i.e. it involves a change to the language of the context.

Suppose that Context1 is a projection of Context2 in which the current year is assumed to be 2000. Then, the following relationship holds:

[Context1] --rdfc:asserts--> [Context2]

Further, any statement that is true in Context1 is also true in Context2 if the year is explicitly qualified to be 2000. Thus we have:

[Context1] --rdfc:asserts--> (NumberOfDays(February)=29)

and can also deduce from the projection:

[Context2] --rdfc:asserts-->
    ( (year=2000) implies (NumberOfDays(February)=29) )

Note that this is one form of lifting rule.

Thus, projection can be regarded as a kind of specialization in which the exact nature of the additional assumptions is known, hence rules for lifting assertions into the more general context can be derived.

In this way, projection can be expressed through through multiple rdfc:asserts or rdfc:assumes relationships, which explicitly state the projection assertions.

5.6.4 Default context

The motivation for considering default context relationship is that it provides a controlled basis for introducing nonmonotonic reasoning. In nonmonotic reasoning, the introduction of new facts can falsify facts that were previously held to be true, something that does not happen with conventional logic. For example, the expression “birds fly” is generally held to be true. But penguins are birds, and the fact that penguins cannot fly is an exception to the general rule.

A default context relationship is expressed as:

[Context1] --rdfc:default--> [Context2]

meaning that any statement that is true in Context1 is taken to be true in Context2 unless explicitly overridden. Further, any statement that can be deduced in Context2 using facts from Context1 is true unless explicitly overridden.

Thus, Context1 may contain the (default) assertion “Birds fly”, and Context2 may state “Penguins are birds”. From this, one might deduce in Context2 “Penguins fly”. But Context2 may contain an explicit assertion “Penguins cannot fly”, which would override the deduction based on a default assertion in this case.

At this time the means of overriding (negating) an RDF assertion is not specified. It may be dependent on the particular logic being employed, and as such would be dependent on the linguistic assumptions associated with a context.

5.6.4.1 An alternative to rdfc:default?

In a message to the W3C RDF-logic mailing list [8], Pat Hayes has suggested that monotonic logic can be handled to some extent in ordinary logic by representing non-monotonicity as "fungible assumptions" which act as "inference fuses", using which one can build monotonic chains of proof about non-monotonic inferences.

As long as the default assumptions underpinning a chain of reasoning are not known to be false, standard monotonic logic applies. When an exception sitiuation is encountered (e.g. “penguins are birds that cannot fly”) the default assumptions (e.g. “birds fly”) are discounted -- the inference fuse is blown -- and the previous chain of logic must be revised.

This suggests that assertions that are assumed by a context might be a way to introduce non-monotonic reasoning: anything that is included in a context as an assumption must be regarded as questionable, and any inferences based on that assumption, or based on any context that depends on that assumption, must be subject to review if the assumption is challenged.

[[[Needs some discussion]]]

6. Application

We are working on a project to use contexts to model hardware and software components of computer systems using RDF, as part of a project to build a general purpose, RDF-driven, expert system framework.

[[[Work in progress -- further details to be supplied]]]

7. Conclusions and further work

Other than linguistic changes between contexts, the essentioal structural properties of contexts described here are expressed by:

rdfc:Set
rdfc:StatementSet
rdfc:Context
rdfc:Assertion
rdfc:member
rdfc:quotes
rdfc:asserts

Further logical properties of contexts have been described using:

rdfc:applyToAll
rdfc:assumes
rdfc:default

We have found that using contexts to represent components seems to make it very much easier to express some kinds of physical world relationships; further work is planned to test these ideas in a more demanding role. The mechanism of contexts described here seems to be a natural way to attach security- and trust- related information to an RDF model; again, further work is planned to prove these ideas.

There are a number of issues and questions concerning some more esoteric (but potentially useful) applications of contexts that still need to be worked out. One of the complications is that RDF does not contain a generalized framework for logical reasoning, so certain operations that would be needed for some of these applications are not defined. A feature of RDF is that different systems of logic may be employed in different models, or different parts of the same model. It is not clear at this time whether a specific logical framework should be defined for just these applications of contexts, or whether they should be based on a locally applied system of logic. In any case, it seems unhelpful to define a logical framework for this purpose if it is likely that some standard framework will be defined for RDF.

Some specific issues:

Work is under way to implement these ideas in an experimental RDF database and associated visual modelling tool. This implementation will be used to experiment with developing models for relationships between physical world systems, and trust modelling.

8. Acknowledgements

The author would like to thank the following for comments and suggestions made during a meeting at HP Labs in Bristol, and subsequent e-mail discussion: Brian McBride <bwm@hplb.hpl.hp.com>, Stuart Williams <skw@hplb.hpl.hp.com>, Dan Brickley <danbri@w3.org> Libby Miller <Libby.Miller@bristol.ac.uk> Dave Beckett <cmdjb@bristol.ac.uk> Jan Grant <Jan.Grant@bristol.ac.uk> Craig Pugsley <Craig.Pugsley@MIMEsweeper.com>.

9. References

[1] Resource Description Framework (RDF) Model and Syntax Specification
Ora Lassila, Ralph R Swick
W3C Recommendation, 22 February 1999
http://www.w3.org/TR/REC-rdf-syntax

[2] Resource Description Framework (RDF) Schema Specification 1.0
Dan Brickley, R. V. Guha
W3C Candidate Recommendation, 27 March 2000
http://www.w3.org/TR/rdf-schema

[3] Notes on Formalizing Context
John McCarthy
Computer Science Department, Stanford University
http://www-formal.stanford.edu/

[4] Contexts: A Formalization and Some Applications
Ramanathan V. Guha
Stannford PhD Thesis, 1991
http://www-formal.stanford.edu/

[5] The Semantic Toolbox
Tim Berners-Lee
Personal ramblings, 24 May 1999
http://www.w3.org/DesignIssues/Toolbox.html

[6] Generality in Artificiual Intelligence
John McCarthy
Communications of the ACM, Vol 30, December 1987

[7] Interpretation properties
Tim Berners-Lee
Personal view, 29 Feb 2000
http://www.w3.org/DesignIssues/InterpretationProperties.html

[8] Random thoughts on web logic
Pat Hayes
Message to W3C RDF-logic mailing list, 22 Sept 2000
http://lists.w3.org/Archives/Public/www-rdf-logic/2000Sep/0007.html

[9] Bertrand Russell,
“The Problems of Philosophy”,
Home University Library, 1912
Oxford University Press paperback, 1959
http://www.ditext.com/russell/russell.html
(Chapter V introduces the ‘definite description’ idea.)

Appendix A:
Distributing properties over a collection

This appendix describes a generalized framework for distributing properties over resources in a container, of which the application of rdfc:applyToAll to contexts can be regarded as a special form.

Example. For contexts we would have:

[rdfc:Context] --rdf:type-----------------------> [rdfs:Class]
[            ] --rdfd:distributesOverObjectsOf--> [rdfc:asserts]

[AContext] --rdf:type---------> [rdfc:Context]
[        ] --rdfd:applyToAll--> [ ] --p1--> [v1]
[        ]                      [ ] --p2--> [v2]
[        ]                      [ ] (etc.)
[        ] --rdfc:asserts-----> [s1]
[        ] --rdfc:asserts-----> [s2]

From this, we can infer:

[s1] --p1--> [v1]
[  ] --p2--> [v2]
[  ] (etc.)

and

[s2] --p1--> [v1]
[  ] --p2--> [v2]
[  ] (etc.)

Appendix B: Enhanced RDF notation

First the enhanced notation is introduced, then I shall try to demonstrate informally that it can be mapped into and out of the standard RDF model.

The standard RDF model uses triples to represent RDF statements: each triple consists of a predicate resource, a subject resource and an object resource or literal. Resources are denoted by URIs.

The enhanced notation used here uses quadruples to represent RDF statements. As with the standard model, there are the predicate, subject and object. The fourth element is a URI that denotes the reification of the statement. Thus each quadruple both denotes a statement and identifies its reification.

The quadruple form can be converted to triples by explicit reification as described in RDF Model and Syntax [1]. The resource created to represent a reified statement should be given the statement identifier that appears in the corresponding quadruple.

A standard RDF model consisting of triples can be converted to the quadruple form by:

  1. Identify all statements of the form:
    [<subject>] --rdf:type--> [rdf:Statement]

  2. For each such statement, find all corresponding statements of the form:
    [<subject>] --rdf:predicate--> [<pred>]
    [<subject>] --rdf:subject----> [<sub>]
    [<subject>] --rdf:object-----> [<obj>]
    having the same [<subject>] identifier.

  3. For each such triple of statements, find the corresponding statement consisting of:
    [<sub>] --<pred>--> [<obj>]

  4. Replace each group of five triples found by the above procedure with a single quadruple consisting of:
    [<sub>] --<pred>--> [<obj>]
    and having a statement identifier value the same as the <subject> resource identifier.

  5. Finally, replace any triples not processed by the above procedure by a corresponding quadruple containing the same predicate, subject and object values, and an automatically selected statement identifier (possibly null?).

The conversion described above from a standard RDF model to the enhanced quadruple form is not perfect, but I believe the shortcomings are not of concern for practical purposes:

In the final analysis, everything expressed using the quadruple model described here can be described faithfully using the standard RDF triple-based model. Thus, any construct proposed based on this model can also be handled using the standard model, so using the enhanced model as a basis for discourse does go beyond the capability of standard RDF.

The standard RDF syntax allows a property to be given an identifier; e.g.

<Description rdf:about=‘http://www.example.com/mypage’>
  <author ID=‘http://www.example.com/mypage/statement/author’>
    Graham Klyne
  </author>
</Description>

I understand that SiRPAC (and maybe other RDF parsers) use the presence of such an identifier on a property as a signal to generate a reified statement corresponding to that occurrence of the property, using the identifier for the resource denoting the reified statement. This applies very easily to the enhanced model: the given identifier is simply used for the statement identifier field of the quadruple.

Finally, some comments on notation. I shall use:

StatementId:  [Subject] --predicate--> [Object]

to represent the statement:

[Subject] --predicate--> [Object]

and its reification represented by a resource named ‘StatementId’.

Appendix C: RDF schema for contexts

[[[TBD]]]

Page from 32