This is a proposal for DAML-Rules.
It builds off significant previous work:
- several previous proposals
- my experience with several applications
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
both of which are ordered DAML+OIL lists of
(to support implementations where order is important).
provide for the following
Variables are defined as DAML+OIL objects.
Variable names will generally be scoped within the containing page;
variable bindings are scoped only within a specific rule.
- 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
I used a RDF(S)-compatible subset of
for my definitions
because it's easier to read than DAML+OIL.
New readers are advised to read the following pages in order:
The following files are available:
- introduction above
- dumpont of rules.daml
- gedcom-relations background
- gedcom-relations.n3 example
- hyperdaml of gedcom-relations.daml
- Notes below
- 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.
Match don't currently allow variables for
We could add a
to support this.
- There's currently no way to express the
(not (match ...))
- There's currently no form of ignored variable
(like a standalone
? in JESS).
The suggested work-around is to declare as many variables named
as are needed.
- I currently use the
.daml suffix in
namespaces because www.daml.org and the current APIs
I'd prefer not to use the
is somewhat limited in viewing ontologies defined using N3
because cwm never emits
Initial discussion should take place on the
I suggest that we prioritize discussion as follows:
- the general approach (classes and variables as instances, etc.)
- details (naming, rdfs:domain values,
addition/removal of Builtins, etc.)
$Id: index.xml,v 1.6 2001/08/03 19:53:04 mdean Exp $