W3C home > Mailing lists > Public > www-rdf-rules@w3.org > November 2003

RE: "A Web of Rules": positional RuleML

From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
Date: Fri, 28 Nov 2003 20:31:27 -0500
Message-ID: <10C94843061E094A98C02EB77CFC3287026DF708@nrcmrdex1d.imsb.nrc.ca>
To: 'Eric Prud'hommeaux' <eric@w3.org>
Cc: www-rdf-rules@w3.org, Kendall Grant Clark <kendall@monkeyfist.com>

Hi Eric,

let me try to answer most of your questions.

You wrote:
I believe that the positional nature of RuleML enables it to provide
n-ary predicates (contrast with RDF's binary predicates).

Well, OO RuleML (http://www.cs.unb.ca/~boley/ruleml/ruleml-rgs.pdf)
has F-Logic's non-positional ('roled') nature, rather than Prolog's
positional (ordered) nature.

In PR Syntax (http://www.ruleml.org/submission/ruleml-shortation.html)
roled atoms are written like
discount(offer name->XMAS-sale; customer name->"bob"; awarded amount->$10)
discount(offer name->THGI-sale; customer name->"ann"; awarded amount->$15)
and corresponding ordered atoms like
discount(XMAS-sale, "bob", $10)
discount(THGI-sale, "ann", $15)
where the roles 'offer name', 'customer name', and 'awarded amount'
should be remembered as "column headings" of the 1st, 2nd, and 3rd
arguments, respectively (e.g., via a 'discount' signature declaration).

Such roles can represent RDF's binary properties, with each roled atom
becoming an RDF description. The above examples thus become

  <rdf:Description about="#discount1">
    <rdf:type resource="http://offercore.org/offerclasses#discount"/>
    <s:offer_name rdf:resource="#XMAS-sale"/>
  <rdf:Description about="#discount2">
    <rdf:type resource="http://offercore.org/offerclasses#discount"/>
    <s:offer_name rdf:resource="#THGI-sale"/>

You wrote:
                                                          A series of
statements (atoms in RuleML parlance) is still a logical conjunction
and therefor unordered. 


You wrote:
Otherwise, the query in Harold reply would
  discount(XMAS-sale, "bob", $10)
  offer(XMAS-sale, "special", $50)
  customer("bob", "gold")
and not if
  customer("bob", "gold")
  offer(XMAS-sale, "special", $50)

I used an OO RuleML rule adapted from the above ruleml-rgs.pdf
(the pretty-print was lost in the XML.com archive):

      <_r n="offer name"><var>off</var></_r>
      <_r n="customer name"><var>cust</var></_r>
      <_r n="awarded amount"><ind>10</ind></_r>
        <_r n="name"><var>off</var></_r>
        <_r n="category"><ind>special</ind></_r>
        <_r n="price"><var/></_r>
        <_r n="name"><var>cust</var></_r>
        <_r n="status"><ind>gold</ind></_r>

Yes, the 'and' of (OO) RuleML is commutative, so semantic query
optimization can be done for the _body, although an ordered 'and'
in rule bodies and top-level queries (cf. Lisp/Prolog) can be useful
operationally. Similarly, in (OO) RuleML the textual order of the underlying
facts and rules is not relevant, so relational indexing
methods can be used, although an ordered clause base (cf. Prolog)
can make sense operationally.

You wrote:
Harold, is <body><atom1/><atom2/></body> (as distinct from
<body><and><atom1/><atom2/></and></body>) defined? Does it
match only data where <atom1/> was expressed before <atom2/> ?

The abridged <_body><atom1/><atom2/></_body> is used in RuleML Lite
(http://www.daml.org/listarchive/joint-committee/1490.html) exactly
like <_body><and><atom1/><atom2/></and></_body> in normal RuleML:
In http://www.daml.org/listarchive/joint-committee/1411.html we give
the reduction (using _bodya instead of _body for the short form);
meanwhile, XSLT transformers have been developed back and forth.

You wrote:
Also, Harold, I'm interested in the trade-offs in validating the
data expressed in an XML proposition language separately from the
well-formedness of the proposition language. Clearly
  offer(XMAS-sale, "special", $50)
  customer("bob", "gold")
does not make much use of XML (beyond some character encoding
normalization). At the other end of the continuum,
requires a special DTD or schema (something like this:)
  IntimateData: offer*, customer*
  offer: o_name, category, price
  customer: c_name, status

First: The actual markup of this was shown in the rule _body above.
Yes, the HiddenData version uses (top-level-only) *generic* markup.
The IntimateData version uses *non-generic* markup. This important
distinction was made by XOL (http://xml.coverpages.org/xol-03.html,
5. The Generic Encoding Approach) already in 1999. The OO RuleML
markup above, like all RuleML markup, has always been generic.

You wrote:
But this data is unembedable in a document with a closed content
model, for instance, XHTML. RuleML uses a language where all the
domain-specific terms (offer, XMAS-sale, ...) are in attribute
values, hidden from conventional validation tools. This allows
one to make sure the encoding is well formed (atoms have an opr
and some number of _rs).

Right, all domain-specific terms of generic markup languages are
in attribute values or in the content between tags (see above).
Interchanging, e.g., business rules embedded into valid XHTML
documents will be essential (paralleling "literate programming"

You wrote:
My concearn is that the compromise postion, imposing a regular
encoding for facts, offers not advatage over the IntimateData
approach (unless we want to talk about the facts and not just
assert them). Yes, it is generically validatable, but only that
information that we've added by encoding the data is validat-

Well, with generic markup, validation on the XML level concerns
only the syntax of the XML application -- the semantics must be
defined outside. The above ruleml-rgs.pdf discusses one aspect
of this: types for RuleML variables that are URI-referenced out
of definitions from an RDF Schema document.

You wrote:
This is analogous to saying that plain text is "validatable" when
encoded XHTML. The presence of <p></p> around a paragraph offers
no additional validation than they expression of the paragraph
in the original plain text document. It does enable other, non-
plain text data to be interspersed, but that is a separate issue.

In RuleML's Initial Steps (http://www.ruleml.org/insteps.html) we
worked on progressing from natural language to rules such that all
intermediate steps are already in a (semi-formal but valid) markup.
This will be an important topic for the stepwise formalization of,
e.g., business rules.

You wrote:
Does RuleML ever talk about the atoms? Can an atom declared in
one place be referenced in an _r in another atom?

Not about atoms themselves, but about the enclosing facts/rules:
the third aspect of ruleml-rgs.pdf discusses this "URI grounding".

Received on Friday, 28 November 2003 21:17:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:15 UTC