Yet Another DAML-Rules Proposal Home | About DAML | Announcements | Roadmap | Site Search

• several previous proposals [1] [2] [3]
• RuleML
• my experience with several applications [4] [5]

The basic approach is to encode rules and variables as DAML+OIL instances, avoiding the need to add additional RDF syntax, make non-asserted statements, etc. A rule consists of an if part and a then part, both of which are ordered DAML+OIL lists of Atom (to support implementations where order is important). Subclasses of Atom provide for the following

• matching against existing triples in the a DAML+OIL model
• matching against specific DAML+OIL constructs (typing, subclasses, etc.) which are not trivially expressible as triple matches
• calls to named user procedures (DAML-Rules identifies the name -- binding to actual code is implementation dependent) that can perform "lightweight" computations such as conversions, comparisons, printing debugging information, etc.
• constraints on variable bindings (e.q. expressing that 2 distinct variables must not bind to the same value)
• adding triples to the current DAML+OIL model

Downloads

New readers are advised to read the following pages in order:

1. introduction above
2. dumpont of rules.daml
3. rules.n3
4. gedcom-relations background
5. gedcom-relations.n3 example
6. hyperdaml of gedcom-relations.daml
7. Notes below

1. I used DAML+OIL constraints such as cardinality for clarity even though we've avoided doing so in the DAML+OIL spec itself to avoid circularities in the semantics. If DAML-Rules ends up as a layer on top of the current DAML+OIL, this should be fine. If it ends up in the same layer, we can remove these constraints if necessary.
2. Match don't currently allow variables for :p. We could add a PMatch to support this.
3. There's currently no way to express the (not (match ...)) used in match.clp.
4. There's currently no form of ignored variable (like a standalone ? in JESS). The suggested work-around is to declare as many variables named ignoren as are needed.
5. I currently use the .daml suffix in namespaces because www.daml.org and the current APIs don't consistently favor .daml over .n3 suffices. I'd prefer not to use the .daml suffix.
6. HyperDAML is somewhat limited in viewing ontologies defined using N3 because cwm never emits rdf:ID.

Feedback

I suggest that we prioritize discussion as follows:

1. the general approach (classes and variables as instances, etc.)
2. semantics
3. details (naming, rdfs:domain values, addition/removal of Builtins, etc.)
4. packaging/presentation

Author