From: Adam Pease ([email protected])
Date: 04/08/02
Drew (and all),
Here's a draft whitepaper. Comments welcome. If there aren't too many
critical comments, maybe it's worth posting on the DAML web site.
Why Use DAML?
Adam Pease
Teknowledge
8 April 2002
When you tell a person something, he can combine the new fact with an old
one and tell you something new. When you tell a computer something in XML,
it may be able to tell you something new in response, but only because of
some other software it has that's not part of the XML spec. That software
could be implemented differently in systems that still conform to the XML
spec. You might get different answers from those systems. If you tell a
computer something new in DAML, it can give you new information, based
entirely on the DAML standard itself. A certain set of conclusions are
required from any system that conforms to DAML. Systems may be able to
provide all sorts of additional services and responses beyond the
requirements of the standard but a certain basic set of conclusions will
always be required. DAML gives computers one extra small degree of
autonomy that can help them do more useful work for people.
A set of DAML statements by itself (and the DAML spec) can allow you to
conclude another DAML statement whereas a set of XML statements, by itself
(and the XML spec) does not allow you to conclude any other DAML
statements. To employ XML to generate new data, you need knowledge
embedded in some procedural code somewhere, rather than explicitly stated,
as in DAML.
For example, "Parenthood is a more general relationship than
motherhood." and "Mary is the mother of Bill" together allow a system
conforming to DAML to conclude that "Mary is the parent of Bill". In this
way, if a user poses a query to a DAML search system such as "Who are
Bill's parents?", the system can response that Mary is one of Bill's
parents, even though that fact is not stated anywhere, but can only be
derived by a DAML application.
More formally stated, give the statements
(motherOf subProperty parentOf)
(Mary motherOf Bill)
when stated in DAML, allows you to conclude
(Mary parentOf Bill)
based on the logical definition of "subProperty" as given in the DAML
spec. The same information stated in XML does not allow you to assert the
third fact. XML itself provides no semantics for its tags. One might
create a program that assigns similar semantics to a "subProperty" tag, but
since that semantics isn't part of the XML spec, applications could be
written which conform to the XML spec, and yet do not make that assertion.
DAML provides a basic infrastructure that allows machine to make
the same sorts of simple inferences that human beings do. It's just a
start, but is a critical foundation for a web of information that machines
can draw upon.
At 01:52 PM 4/5/2002 -0500, Drew McDermott wrote:
> One very brief answer to why use DAML as opposed to XML is that a
> set of
> DAML statements by itself (and the DAML spec) can allow you to conclude
> another DAML statement whereas a set of XML statements, by itself (and
> the
> XML spec) does not allow you to conclude any other DAML statements. To
> employ XML to generate new data, you need knowledge embedded in some
> procedural code somewhere, rather than explicitly stated, as in DAML.
> For example, the triples
>
> (motherOf subProperty parentOf)
> (Mary motherOf Bill)
>
> when stated in DAML, allows you to conclude
>
> (Mary parentOf Bill)
>
> based on the logical definition of "subProperty" as given in the DAML
> spec. The same information stated in XML does not allow you to assert
> the
> third fact. XML itself provides no semantics for its tags. One might
> create a program that assigns similar semantics to a "subProperty"
> tag, but
> since that semantics isn't part of the XML spec, applications could be
> written which conform to the XML spec, and yet do not make that assertion.
>
> Adam
>
>You've hit the nail on the head as far as I'm concerned. Why not
>crank out a little white paper?
>
> -- Drew
Adam Pease
Teknowledge
(650) 424-0500 x571
This archive was generated by hypermail 2.1.4 : 03/26/03 EST