Abstract. A programming language is described which is built within RDF. Its code, functions, and classes are formalized as RDF resources. Programs may be written using standard RDF syntax, or in a conventional JavaScript–based syntax which is translated to RDF. RDF constitutes not only the means of expression, but also the subject matter of programs: the native objects and classes of the language are RDF resources and DAML+OIL classes, respectively. The formalization of computation within RDF allows active content to be integrated seamlessly into RDF repositories, and provides a programming environment which simplifies the manipulation of RDF when compared to use of a conventional language via an API. The name of the language is "Fabl".

1. Introduction

Fabl¹ is a programming language which is built within RDF[1]. The constituents of the language - its code, functions, and classes - are formalized as RDF resources, as is the data over which computation takes place. This means that programs reside within the world of RDF content rather than being relegated to a separate realm connected to RDF via an API. The starting point for the formalization is DAML+OIL[2].

The language provides an efficient imperative programming framework for the RDF domain. Programs may be expressed as RDF objects using standard RDF syntax, or via a conventional syntax which might be described as JavaScript² enhanced with types and qualified property names. The language is designed to be easy to learn for programmers familiar with the conventional JavaScript/HTML/XML/DOM web–programming model. In fact, the conceptual cleanliness of RDF makes the language and its semantics far simpler than this conventional model. The initial implementation is similar in runtime efficiency to other scripting environments.

As a computational formalism for RDF, the neighboring points of comparison for Fabl are the RDF APIs (eg [3], [4]), in which computation is expressed in conventional ways, but the subject matter of the computation is expressed in RDF. Fabl has several advantages over APIs:

1. Simplicity of programming
   
2. Functions and programs can be managed, inspected, manipulated, and annotated in the same manner as any other RDF resources; they are first–class citizens of the RDF world
   
3. Fabl's type system exploits the RDF property–centric style. This yields a system of a kind different, and in some ways more expressive and flexible, than those found in the main thread of object–oriented type systems running from Simula through C++, Java, C#, and Curl.
   
4. Fabl programs are formalized within RDF in a manner that provides an open framework for extension of the language. The implementation of Fabl is, with the exception of a few low level utilities, written in Fabl itself. Further, the process by which programs are analyzed and converted into an efficiently executable form can be extended by addition of new RDF content. This means that extension of Fabl to include new language facilities, such as new control structures, new syntax, or new typing systems built on different principles can all be carried out in the RDF style: by extending the base of RDF files which describe the language.

Whether or not the particular formalism introduced here is the right one, RDF can and should be used as a vehicle for representing computation as well as passive content. If nothing else, Fabl shows the practicality of this idea.

2. An Application

Our initial Fabl application illustrates one way in which the integration of computation with RDF facilitates the development of active RDF content. We have defined relatively simple ontologies for geography (themed maps, as in GIS), and for events located in a geographical context. This geographical and historical information is depicted by interactive web-delivered maps in the Macromedia Flash format (see our web site[5] for examples). The active aspect of our RDF repository consists primarily of handlers which generate interactive maps from the underlying geographical and historical information, and which maintain consistency between the data and its depiction as changes are made. The handlers are RDF resources and their relationship to other data is expressed by RDF statements. Regularities (eg all resources in this class have that handler) are asserted by DAML+OIL restrictions.

This application provides a template for a wide range of possible applications, wherein complex situations are represented in RDF, and where consistency constraints are automatically maintained by associated constraint propagation mechanisms which are at least partly algorithmic (rather than strictly deductive) in nature. The kind of complete integration proposed here is not the only possible approach to this kind of application, but we would argue that first-class status for computational entities in the RDF world removes a layer of indirectness and complexity that would otherwise be necessary.

3. An Example

Consider the simplest of data structures, a point on the plane with two coordinates, which can be expressed in Java by:

public class  Point {
    double xc;  
    double yc;
}

<rdf:RDF
  xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#"
  xmlns:daml="http://www.daml.org/2001/03/daml+oil#"
  xmlns:fabl="http://purl.oclc.org/net/nurl/fabl/"
  xmlns:nurl="http://purl.oclc.org/net/nurl/"
>

<daml:DatatypeProperty rdf:ID="xc"/>
<daml:DatatypeProperty rdf:ID="yc"/>

<daml:Class rdf:ID="Point">
  <rdfs:subClassOf>    
    <daml:Restriction>
      <daml:onProperty rdf:resource="#xc"/>
      <daml:toClass rdf:resource=
          "http://www.w3.org/2000/10/XMLSchema#double"/>
      <daml:cardinality>1</daml:cardinality>
    </daml:Restriction>
  </rdfs:subClassOf>    
  <rdfs:subClassOf>    
    <daml:Restriction>
      <daml:onProperty rdf:resource="#yc"/>
      <daml:toClass rdf:resource=
          "http://www.w3.org/2000/10/XMLSchema#double"/>
      <daml:cardinality>1</daml:cardinality>
    </daml:Restriction>
  </rdfs:subClassOf>    
</daml:Class>  

<rdf:RDF
[standard–namespace–declarations]
  xmlns:geom="http://purl.oclc.org/net/fabl/examples/geom#"
>

<fabl:code>
geom:Point function plus(geom:Point x,y)
  {
  var geom:Point rs;
  rs = new(geom:Point);
  rs . geom:xc = x.geom:xc + y.geom:xc;
  rs . geom:yc = x.geom:yc + y.geom:yc;
  return rs;
  }
</fabl:code>
</rdf:RDF>

Note that the syntax resembles that of JavaScript, except that variables and functions are typed. Fabl types are RDF classes, and are named using XML qualified[6] or unqualified names (details below).

Here are the contents of the file http://purl.oclc.org/net/fabl/examples/color:

<rdf:RDF
[standard–namespace–declarations]
>

<daml:Class rdf:ID="Color"/>
<Color rdf:ID="yellow"/>
<Color rdf:ID="blue"/>
<rdf:Property rdf:ID="colorOf">
  <rdfs:range rdf:resource="#Color"/>
</rdf:Property>

<rdf:RDF
[standard–namespace–declarations]
  xmlns:geom="http://purl.oclc.org/net/fabl/examples/geom#"
  xmlns:color="http://purl.oclc.org/net/fabl/examples/color#"
>

<fabl:code>
fabl:void function setColor(geom:Point x)
  {
  if (x . geom:xc > 0) x.color:colorOf = color:yellow;
  else x.color:colorOf = color:blue;
  }
</fabl:code>

The setColor example illustrates the central difference between an RDF class and its counterparts in the object–oriented programming tradition. An RDF class is an assertion about properties possessed by a resource, which does not preclude the resource from having additional properties not mentioned in the class, nor from belonging to other classes, nor even from aquiring new properties and class memberships as time goes on. The progression of data types in programming languages exhibits growing freedom of type members: C or Pascal types exactly determine the structure of their members; C++ and Java classes determine the structure of members to a degree, but allow extension by subclasses; the RDF model leaves the structure of members free except as explicitly limited by the class definition.

Unless a property has been explicitly constrained to have only one value, Fabl interprets the value of a property selection:

x.P

xsd:int function numColors(daml:Thing x)
{
   return cardinality(x.color:colorOf);
}

color:Color function theColorOf(daml:Thing x)
{
   var BagOf(color:Color) cls;
   cls = x.color:colorOf;
   if (cardinality(cls)==1) return cls[0];
   else return fabl:undefined;
}

4. RDF Computation in Fabl

RDF syntax and semantics can be viewed as having three layers: (1) a layer which assigns concrete syntax (usually XML) to RDF assertions, (2) the data model layer, in which RDF content is represented as a set of triples over URIs and literals, and (3) a semantic model, consisting of the objects and properties to which RDF assertions refer. DAML+OIL specifies semantics[7] constraining the relationship between the data model and the semantic model.

The proper level of description for computation over RDF is the data model; the state of an RDF computation is a set of triples <subject,predicate,object>. This triple set in turn can be construed as a directed labeled graph whose nodes are URIs and literals, and whose arcs are labeled by the URIs of properties.

Fabl is executed by a virtual machine. An invocation of the Fabl VM creates an initial RDF graph which is in effect Fabl's own self description: the graph contains nodes for the basic functions and constants making up the Fabl language. Subsequent activity modifies the RDF graph maintained by the VM, called the "active graph". The Fabl interpreter can accept input from a command shell, or can be configured as a server in a manner appropriate to the application.

The universe of RDF files on the web plays the role of the persistent store for Fabl. The command

loadRdf(U)

The active graph is partitioned into pages. The data defining a page includes: (1) the external URL (if any) from which the page was loaded, (2) the set of RDF triples which the page contains, (3) a dictionary which maps the ids appearing in the page (as values assigned to the rdf:ID attribute) to the resources which they identify, and (4) a set of namespace definitions (bindings of URIs to namespace prefixes). Many pages are the internal representations of external RDF pages, but new pages can be created which are not yet stored externally.

saveRdf(x,U)

A global variable or constant X with value V is represented by a daml:UniqueProperty named X whose value on the URI fabl:global is V. (It doesn't matter what values the property assumes when applied to other resources, nor does fabl:global play any other role.) For example, the following fragment defines the global pi:

<daml:DatatypeProperty rdf:ID="pi">
  <rdf:type rdf:resource="http://www.daml.org/2001/03/daml+oil#UniqueProperty"/>
  <rdfs:range rdf:resource="http://www.w3.org/2000/10/XMLSchema#double"/>
</daml:DatatypeProperty>

<daml:Class rdf:about="http://purl.oclc.org/net/nurl/fabl/global"> 
  <pi>3.14159265358979323846 </pi>
</daml:Class>

<rdf:RDF
[standard–namespace–declarations]
  xmlns:geom="http://purl.oclc.org/net/fabl/examples/geom#"
>

<fabl:code>
xsd:double function timesPi(xsd:double x){return x * geom:pi}
</fabl:code>

x.P

x.P

x.P = E

var Type name;

<daml:UniqueProperty rdf:ID="name">
  <rdfs:range rdf:resource="Type"/>
</daml:UniqueProperty>

new(Type)

x.uri

x.uri = newURI;

5. RDF Computation Via an API: A Comparison

The Java code below uses the Jena API[4] to implement the function presented at the beginning of section 2: vector addition of points. This sample is included to give the reader a concrete sense of the difference between Fabl code, which expresses elementary RDF operations directly as basic operations of the language, and code using an API, in which the same elementary operations must be expressed as explicit manipulations of a representation of RDF content in the host language (here, Java). This is the only purpose of the sample. The details are not relevant to anything that appears later in this paper, and may be safely skipped by any reader who is willing to grant the point that an API adds complexity to the expression of RDF computation. This point applies equally to other RDF APIs.

Here is the definition of vector of addition using Jena:

import com.hp.hpl.mesa.rdf.jena.mem.ModelMem;
import com.hp.hpl.mesa.rdf.jena.model.*;
import com.hp.hpl.mesa.rdf.jena.vocabulary.*;

// The class GeomResources initializes variables
// xc, yc, and Point to RDF resources of the right kind.
public class GeomResources {
    protected static final String URI = "http://purl.oclc.org/net/fabl/examples/geom#";    
    public static String getURI(){return URI;}   
    public static Property xc = null;
    public static Property yc = null;
    public static Resource Point = null;
    static {
        try {
            xc = new PropertyImpl(URI, "xc");
            yc = new PropertyImpl(URI, "yc");
            Point = new ResourceImpl(URI+"Point");
           } catch (Exception e) {
            System.out.println("exception: " + e);          
        }
    }
}

public class GeomFunctions {
// PointPlus is vector addition
    public static Resource PointPlus(Resource x,Resource y) {
           Resource rs = x.getModel().createResource();
           rs.addProperty(RDF.type, GeomResources.Point);
           rs.addProperty(GeomResources.xc,
              x.getProperty(GeomResources.xc).getDouble() +
              y.getProperty(GeomResources.xc).getDouble());
           rs.addProperty(GeomResources.yc,
              x.getProperty(GeomResources.yc).getDouble() +
              y.getProperty(GeomResources.yc).getDouble());
          return rs;
           }
}

6. Nurls

In normal RDF usage, locators (that is URLs) are often used as URIs whether or not the entities they denote exist on the web. However, nothing prevents the use of URIs which are completely unrelated to any web location, for example:

<rdf:Description rdf:about= "my_green_sedan">

Identifying an entity in a manner which does not make use of a WWW locator has two advantages. First, the question of where to find information about the entity is decoupled from naming the entity, which allows all of the different varieties of information about the entity to evolve without disturbing the manner in which the entity is named. Among other things, this simplifies the versioning of RDF data. Second, use of non–locating URIs frees up the content of the URI for expressing hierarchy information about the entities described.

In the Fabl implementation, the triple

<X,fabl:describedBy,U>

means that U denotes an RDF file which provides information about X. (rdfs:isDefinedBy[8] has a closely related, but not quite identical intent; descriptions need not always qualify as definitions). U is also taken as relevant to any subject Y whose URI (regarded as a pathname, with "." and "/" as delimiters) extends that of X. For example, if my_green_sedan is described by U, then so are my_green_sedan.engine, and my_green_sedan/engine but not my_green_sedan_attenna. The Fabl command:

getRdf(Y);

It is desirable that non–locating URIs not conflict with URLs. For Fabl applications, we have reserved the URI http://purl.oclc.org/net/nurl/ as a root URI whose descendants will never serve as locators. This line appears in our standard namespace declaration:

  xmlns:nurl="http://purl.oclc.org/net/nurl/"

The following fragment tells the Fabl VM where to find the description of the Fabl language, and illustrates the points just made:

<rdf:Description about= "http://purl.oclc.org/net/nurl/fabl">
   <fabl:describedBy  rdf:resource="http://purl.oclc.org/net/fabl/languageV0"/>
</rdf:Description> 

If U is the source URL of a page in the active graph, and the triple <X,fabl:describedBy,U> is present in the active graph, then X is said to be a subject of the page. That is, the page has as its subject matter the part of the hierarchical URI name space rooted at X. A page may have more than one subject. When a new triple <A,P,B> is created in the course of computation, and the URI of A is an extension of the subject of a page, the new triple is allocated to that page. (Slightly more complex rules - not covered here - govern the case where the subjects of pages overlap.)

7. Identifiers

Identifiers in Fabl represent XML qualified or unqualified names. However, since the "." character is reserved for property selection, "." is replaced by "\" when an XML name is transcribed into Fabl. For example:

fablex:automobiles\ford

fablex:automobiles.ford

8. Types

Any RDF type is a legal Fabl type.

X.rdf:type = T;

Fabl also includes its own primitives for constructing new types, that is, for introducing new resources whose type is rdfs:Class. The following lines of Fabl introduce the type Point which was discussed earlier.

class('Point');
var xsd:double geom:xc;
var xsd:double geom:yc;
endClass();

Here are the details. A Fabl class definition starts with

class('classname');

endClass();

var pathname = expression;

var [qualifier] [type] pathname;

var [qualifier] type pathname;

var [qualifier] pathname;

The assignment

var pathname = expression;

class('Rectangle');
var Point geom:center;
var geom:width;  //already declared to be a xsd:double in geom:
var geom:height; //already declared to be a xsd:double in geom:
endClass();

class('RedObject');
var color:color = color:red;
endClass();

class('RedRectangleCenteredOnXaxis');
var Rectangle && RedObject this;
var geom:center.geom:xc = 0.0;
endClass();

var A this;

The translation of Fabl class definitions into DAML+OIL RDF is straightforward. Assertions translate into toClass restrictions, and their qualifiers to cardinality or maxCardinality restrictions. Assignments translate into hasValue restrictions. The only minor complication is that, when pathnames of length greater than one appear, helper classes are automatically generated which express the constraints on intermediate values in path traversal (details ommitted).

9. Dynamic Installation of Classes

Recall that

x.rdf:type = C;

var rect = new(Rectangle);

rect.rdf:type = RedRectangleCenteredOnXaxis;

<x,rdf:type,RedRectangleCenteredOnXaxis> 
<x,color:colorOf,color:red>, 
<x,geom:center,center–uri>,
<center–uri,rdf:type,geom:Point>
<center–uri,geom:xc,0.0>

10. Parametric Types

Fabl includes constructors BagOf(T), ListOf(T), SeqOf(T), and Function(O,I₀,...,I_N) which generate parametric types denoting the set of all bags (resp. lists,sequences) with members in type T, and of all functions from input types I₀,...,I_N to output type O, respectively. Here is the definition of BagOf:

class('BagOf');
var daml:Class this;
var memberType;
endClass();

daml:Class function BagOf(rdfs:Class tp)
{
  var BagOf rs;
  rs = new(BagOf);
  rs . memberType = tp;
  rs . uri = 'nurl:fablParametricTypes/' + 'BagOf(' + uriEncode(tp.uri) + ')';
  return rs;
}

The implementation of the other parametric types ListOF, SeqOf, and Function are analogous. Fabl programmers can introduce their own parametric types using the same strategy.

11. Types of Fabl Expressions

Fabl is not just a language in which types may be created and manipulated, but a typed language in the more usual sense that each Fabl expression E is assigned an rdfs:Class. Of course, any particular Fabl value (ie node in the active graph) may have arbitrarily many types, but a Fabl expression is assigned one of the types which the values of the expression is expected to assume. Types of function applications are deduced in the usual way. If a Fabl function f is defined by

O function f(I0 a0,... IN aN)
{
...
}

<P,rdfs:range,T>

x.P;

E ~ T

12. Functions and Methods

A function definition:

O function fname (I0 a0,... IN aN))
{
...
}

'f' + hash(uri_encode(I0.uri),...uri_encode(IN.uri),fname)+'_'+fname;

f[I0,...In]

supplyArguments(functionalValue,a0,...aN)

class('Displayable');
var Function(fabl:void) Displayable\display;
...
endClass();

fabl:void function display(Rectangle r)
{
....
}

class('DisplayableRectangle');
var Displayable && Rectangle this;
var Displayable\display = supplyArguments(display[Rectangle],this);
endClass();

someRectanglePreviouslyUndisplayable.rdf:type = DisplayableRectangle;

class('Xob');
//atomic Xob classes such as Xlocal do not require flattening
var optional Function(Xob,Xob) Xob\flatten; 
var rdfs:Class Xob\valueType; 
endClass();

class('Xconstant'); //Constant appearing in code
var Xob this;
var Xconstant\value;
endClass();

class('Xlocal'); //Local variable
var Xob this;
var xsd:string Xlocal\name;
endClass();

class('Xif');
var Xob this;
var Xob Xif\condition;
var Xob Xif\true;
var optional Xob Xif\false;
endClass();

class('Xapply'); //application of a function to arguments
var Xob this;
var AnyFunction Xapply\function;
var SeqOf(Xob) Xapply\arguments;
endClass();

if (test(x)) action(2);

<fabl:Xif>
   <fabl:Xif.condition>
      <fabl:Xapply>
          <fabl:Xapply.function rdf:resource="#f001a0e6f_test"/>
          <fabl:Xapply.arguments>
              <rdf:seq>
                  <rdf:li>
                      <fabl:Xlocal>
                          <fabl:Xlocal.name>x</fabl:Xlocal.name>
                      </fabl:Xlocal>
                  </rdf:li>
              </rdf:seq>
          </fabl:Xapply.arguments>
      </fabl:Xapply>
   </fabl:Xif.condition>
   <fabl:Xif.true>
      <fabl:Xapply>
          <fabl:Xapply.function rdf:resource="#f001a0e6f_action"/>
          <fabl:Xapply.arguments>
              <rdf:seq>
                  <rdf:li>
                      <fabl:Xconstant Xconstant.value=2/>
                  </rdf:li>
              </rdf:seq>
          </fabl:Xapply.arguments>
      </fabl:Xapply>
   </fabl:Xif.true>
<fabl:Xif>

<rdf:type rdf:resource = "http://purl.oclc.org/net/nurl/fabl/Xob"/>
<fabl:Xob.valueType rdf:resource = "http://www.w3.org/2000/10/XMLSchema:int"/>

class('Xfunction'); 
var xsd:string Xfunction\name;
var rdfs:Class Xfunction\returnType;  
var SeqOf(Xlocal) Xfunction\parameters;
var SeqOf(Xlocal) Xfunction\localVariables;
var Xob Xfunction\code;
var SeqOf(xsd:byte) Xfunction\byteCode;
endClass();

The following steps are involved in translating the source code of a Fabl function or command into an Xfunction:

Source code [Parser] ->
Parse tree   [Analyzer] ->
Type–analyzed form (Xob) [Flattener]->
Flattened form (Xob) [Assembler] ->
Byte Code (executed by the Fabl virtual machine)

The analysis step is table driven: it is implemented by an extensible collection of constructors for individual tokens. The constructor property of a token is a function of type Function(Xob,daml:List) which, when supplied with a parse tree whose operator is the token, returns the analysis of that tree. Here is the code for the constructor for if. The parse of an if statement is a list of the form (if <condition> <action>).

Xob function if_tf(daml:List x)
  {
  var Xob cnd,ift,Xif rs;
  cnd = analyze(x[1]); //the condition
  if (cnd.Xob\valueType!=xsd:boolean) error('Test in IF must return a boolean');
  ift = analyze(x[2]);
  rs = new(Xif);
  rs . Xif\condition = cnd;
  rs . Xif\true = ift; //no value need be assigned for Xif\false in this case
  return rs;
  } 

ifToken.constructor = if_tf[daml:List];

The Xif class, like other non–primitive control structures, includes a method for flattening away occurences of the class into a pattern of jumps and gotos (details omitted). Constructors and flattening methods rely on a library of utilities for manipulating Xobs, such as the function metaApply, which constructs an application of a function to arguments, and metaCast which yields a Xob with a different type, but representing the same computation, as its argument.

This simple architecture implements the whole of the Fabl language. The crucial aspect of the architecture is that it is fully open to extension within RDF. New control structures, type constructors, parametrically polymophic operators, annotations for purposes such as aspect–oriented programming[11], and other varieties of language features can all be introduced by loading RDF files containing their descriptions. The core Fabl implementation itself comes into being when the default configuration file loads the relevant RDF; a different configuration file drawing on a different supply of RDF would yield another variant of the language. This is the sense in which the implementation provides an open framework for describing computation in RDF, rather than a fixed language.

Finally, note once again that Xobs provide a formalism for representing computation in RDF which does not depend for its definition on any particular source language nor on any particular method for execution. That is, it formalizes computation within RDF, as promised by the title of the paper, and can yield the benefits sketched in the introduction.

14. Implementation

The practicality of an RDF–based computational formalism is a central issue for this paper, so size and performance data for our initial implementation are relevant.

The implementation consists of a small kernel written in C. The size of the kernel as a WinTel executable is 150 kilobytes. The kernel includes the byte–code interpreter, a generation–scavenging garbage collector, and a loader for our binary format for RDF. The remainder of the implementation consists of Fabl's RDF self description, which consumes approximately one megabyte in our RDF binary format. A compressed self–installing version of the implementation, which includes the Fabl self description, consumes 420 kilobytes. Startup time (that is, load of the Fabl self description) is about one third of a second on a 400MHZ Pentium II. Primitive benchmarks show performance similar to scripting languages such as JavaScript (as implemented in Internet Explorer 5.0 by Jscript) and Python. However, further work on performance should yield much better results, since the language is strongly typed, and amenable to many of the same performance enhancing techniques as Java.

The full value of formalizing computation within RDF will be realized only by an open standard. We regard Fabl as a proof–of–concept for such a formalization.

15. Future Work

The current Fabl implementation treats the external RDF world as a store of RDF triple sets, which are activated explicitly via loadRdf or getRdf. However, an interesting direction for future work is the definition of a remote invocation mechanism for RDF–based computation. Here is an outline of one possibility.

Values of the fabl:describedBy property might include URLs which denote servers as well as RDF pages. In this case, getRdf(U) would not load any RDF. Instead, a connection would be made to the server (or servers) S designated by the value(s) of fabl:describedBy on U. In this scenario, the responsibility of S is to evaluate properties, globals, and functions in the URI hierarchy rooted at U. Whenever a property E.P, a global G, or a function application F(x) is evaluated in the client C, and the URI of E, G, or F is an extension of U, a request is forwarded to the server S, which performs the needed computation, and returns the result. The communication protocol would itself be RDF–based, along the lines proposed on the www–rdf–interest mailing list[12]. Such an approach would provide simple and transparent access to distributed computational resources to the programmer, while retaining full decoupling of description of computation in RDF from choices about source language and implementation.

16. Other XML Descriptions of Computation

Imperative computational constructs appear in several XML languages. Two prominent examples are SMIL[13] and XSLT[14], in which, for example, conditional execution of statements is represented by the <switch> and <xsl:if> tags, respectively. The aims of these formalizations are limited to specialized varieties of computation which the languages target. Scripting lanuages encoded in XML include XML Script[15] and XFA Script[16].

Footnotes

1. Fabl^TM is a trademark of Map Bureau, and is pronounced "fable".

2. The standardization of JavaScript is ECMAscript[17]

References

[1] W3C RDF Model and Syntax Working Group. Resource Description Framework (RDF) Model and Syntax Specification, February 1999

[2] Ian Horrocks, Frank van Harmelen, Peter Patel-Schneider, eds. DAML+OIL (March 2001), March 2001

[3] Chris Waterson. rdf: back-end architecture, August 1999

[4] Brian McBride. Jena - A Java API for RDF, May 2001 (last update)

[5] Map Bureau, July 2001 (last update)

[6] Tim Bray, Dave Hollander, Andrew Layman, eds. Namespaces in XML. January, 1999

[7] Ian Horrocks, Frank van Harmelen, Peter Patel-Schneider, eds. A Model-Theoretic Semantics for DAML+OIL (March 2001), March 2001

[9] Dan Brickley, R. V. Guha, eds. Resource Description Framework (RDF) Schema Specification 1.0, March 2000

[10] T. Berners-Lee. Uniform Resource Identifiers (URI): Generic Syntax, August 1998

[11] Gregor Kiczales, John Lamping, Anurag Mendhekar and Chris Maeda, Cristina Lopes, Jean-Marc Loingtier and John Irwin "Aspect-Oriented Programming" , 11th Europeen Conference on Object-Oriented Programming, LNCS, vol. 1241, Springer Verlag, 1997

[12] Ken MacLeod, and respondents. Toying with an idea: RDF Protocol, in the www-rdf-interest@w3.org Mail Archives, March 2001

[13] Jeff Ayars et al, eds. Synchronized Multimedia Integration Language (SMIL 2.0) Specification, March 2001

[14] James Clark, ed. XSL Transformations (XSLT), November 1999

[15] DecisionSoft Limited, XML Script, May 2001

[16] XML For All, Inc. XFA Script, May 2001

[17] ECMA. Standard ECMA-262 - ECMAScript Language Specification, December 1999