"A Web of Rules": positional RuleML

This message responds to Kendall Grant Clark's ISWC article in
XML.com[1].

I believe that the positional nature of RuleML enables it to provide
n-ary predicates (contrast with RDF's binary predicates). A series of
statements (atoms in RuleML parlance) is still a logical conjunction
and therefor unordered. Otherwise, the query in Harold reply would
only
  discount(XMAS-sale, "bob", $10)
if
  offer(XMAS-sale, "special", $50)
  customer("bob", "gold")
and not if
  customer("bob", "gold")
  offer(XMAS-sale, "special", $50)

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/> ?
If so, Kendall's assertions hold: (sorry for the long quote)

[[ http://www.xml.com/pub/a/2003/10/23/iswc.html
Harold Boley also made one of the more XML.com-salient points I've
heard at ISWC thus far: XML supports a kind of positional knowledge
representation wherein parent elements are focus points applied to
ordered child elements. RDF supports a kind of role knowledge
representation wherein unordered descriptions focus a resource that
has various properties associated with it by way of predication. This
tension between the ordered and the unordered aspects of XML and RDF
has been a subject of intense debate and interest -- even if not
always in these precise terms -- among XML developers. We might
consider this an inflection point of the other kind; that is, a point
at which XML developers might be able to learn valuable lessons from
old AI hands. Consider all the ink that's been spilled about using
unorderable RDF as a syndication format, for example.
]]


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

<HiddenData>
  offer(XMAS-sale, "special", $50)
  customer("bob", "gold")
</HiddenData>

does not make much use of XML (beyond some character encoding
normalization). At the other end of the continuum,
<IntimateData>
  <offer><XMAS-sale/><special/><$50/></offer>
  <customer><bob/><gold/></customer>
</IntimateData>
requires a special DTD or schema (something like this:)
  IntimateData: offer*, customer*
  offer: o_name, category, price
  customer: c_name, status
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).

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-
able.

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.

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

[1] http://www.xml.com/pub/a/2003/10/23/iswc.html

PS. I'm not a member of XML.com so I'm mailing you both directly.
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Thursday, 27 November 2003 01:46:59 UTC