From: Mark Burstein (
Date: 04/15/02

A possible transportation/logistics inference might be distinguishing air
vs sea movement requirements. This would enable a kind of classification
for purposes of assigning tasks to different agencies (an activity that
occurs at USTRANSCOM). For example if we had

class TransportationRequirement
with a property 'mode' restricted to a 
TransportMode, one of #Land, #Sea,and #Air, each disjoint from the other. 

If someone else, defined the subclasses 
AirRequirement and SeaRequirement, 
each of which restricted mode to only one of these, we could partition
all TransportationRequirements. So, for example, from any
TransportationRequirement with #mode = #Air we could conclude it was 
an AirRequirement.

I don't know if this is too complex an example for what you have in mind.

Adam Pease writes:
 > Folks,
 >     Since a day has gone by without further comment.  I believe this is a 
 > final version, that addresses smaller errors identified by Tim Finin and 
 > Mark Gorniak.  Unless someone has additional issues, I'd like to request 
 > that Kelly Barber post this as a "Why use DAML" link from the DAML home page.
 > Why Use DAML?
 > Adam Pease
 > Teknowledge
 > 10 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 XML
 > 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.
 >     Other web languages such as RDFS go a step further than XML, and could
 > support the example just given, but DAML offers a host of other standard
 > properties such as equivalence ("childOf" on an English geneology site is
 > the same as "filsDe" on a French site), or that particular properties are
 > unique (a social security number is associated with only one individual).
 >     It should also be easy to see that there is similar utility in just
 > about every domain: in finance where one might query about all bank
 > accounts associated with a particular person (whether they are directly
 > owned by, or held in trust for etc), in logistics where one wants to ask
 > the rates for shipping to any eastern European city (where no such category
 > has been predefined and only the countries in eastern Europe are
 > listed).  Having knowledge that can be dynamically applied to find an
 > answer, rather than predefined procedures, is extremely powerful.
 >     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.
 > Adam Pease
 > Teknowledge
 > (650) 424-0500 x571

*    Dr. Mark Burstein              *     Email:            *
*    BBN Technologies               *     Phone: (617)873-3861               *
*    10 Moulton St.                 *     FAX: (617)873-4328                 *
*    Cambridge, MA 02138            *   *

This archive was generated by hypermail 2.1.4 : 03/26/03 EST