RDF hacking ILRT Home

RDF and MOO notes

Sketchy notes on the similarities between MOO systems and the RDF information model.

author: dan brickley

Initial-version: July 09 2000

Latest-version: http://ilrt.org/discovery/2001/03/rdf-moo/March 12 2001

MOOs are object-oriented, immersive, collaborative text based environments that allow users to extend the objects and behaviour of the database they inhabit (eg. see moo.mud.org). It turns out that MOOs are built around a rather RDF-like information model. Everything is an object in a class hierarchy; objects have flat text properties (color, size, description) and relationships to other uniquely identified objects. Behaviour (verbs) is implemented by attaching MOO scripts to objects, where these scripts are akin to simple javascript plus conventions for navigating the objects/properties/relationships that constitute the MOO.

The rest of this note compares the RDF and MOO modeling systems, and describes how MOO behaviours might have equivalents in some lightweight fictional RDFScript.

RDF/MOO Data Model Comparison

MOOs (using the LambdaMOO engine) use local identifiers (eg. #221) instead of Web-wide URI identifiers. The MOO type system conflates the 'sub-class' and 'type' relationships. Apart from this, the models are much the same.

For example:

MOO:
#221 (danbri) -- moo:parent --> #100 (programmer) -- moo:parent --> #20 (person)

RDF:
[danbri] -- rdf:type --> [programmer] -- rdfs:subClassOf --> [person]

Behaviour / stylesheets: This is what got me interested. In RDF, we have no consensus or conventions for lightweight scripting and 'style sheet' applications. This proves annoying in Web collaboration applications where we want to visualise our squiggly RDF graphs. In a MOO context, UI for MOO data graphs is achieved through the pragmatic hack of associated little script fragments with the data.

MOO scripting example:

Here is a MOO script fragment that creates an object and gives it behaviour (a flushable toilet).

@create $thing named loo
@property loo.lastUser
@verb loo:flush this
@program loo:flush

 Now programming loo:flush(1).
 [Type lines of input; use `.' to end or `@abort' to abort the command.]
        player:tell("You flush the loo. The last player to do this was ",
        this.lastUser.name, ".");
        this.lastUser=player;
        .
 0 errors.
 Verb programmed.

Explanation: We create a new 'thing' and attach a verb 'flush' to it. We have a property of the thing ('loo', which is english for toilet) named 'lastUser' which always points to a thing of type player. The MOO context ensures that the method/verb invocation provides a context for current player ID, allowing us to call the 'tell' method on the object invoking the 'flush' method/verb.

RDF version:
[toilet_3] --rdf:type--> [XYZ:Toilet] --rdf:subClassOf--> [moo:Thing]
[toilet_4] --XYZ:lastUser--> [person_44]

[XYZ:Toilet] --XYZ:flush-->
        '
        player:tell("You flush the toilet. The last player to do this was ",
        this.XYZ:lastUser.vcard:name, ".");
        this.XYZ:lastUser=player;
        '

Concrete scenario for WWW collaboration application:

If MOOs were re-implemented over the RDF data model, including some version of an RDFScript such as that above, behaviours/methods previously implemented in MOO script would need to be migrated to an RDF scripting environment such as that hinted above. Real world organisational models (white page data, todo lists, calendars, document descriptions, ratings) could be poured into the collaborative environment. Users could create scripted views into this data by writing simple code fragments attached to objects and classes.

See also