[Kestrel circling]

Home : Current Projects : Darpa Markup Language : Homework 3
 

Home

About Kestrel

Research Staff

Current Projects

Project Archive

Publications

Technology Transfer

Career Opportunities

Contact Kestrel

Homework 3

Deployment plans represented using the DAML Schedule Ontology

Description

The files below contain large deployment plans generated by Kestrel's Mission Planner. The input to the Mission Planner are a set of movement requirements, specifying the amount of cargo that should be moved between two geographic locations, and the initial resource availability-- aircraft and airport capacity. Based on the availability of resources, the Mission Planner automatically generates missions and flights to satisfy all the movement requirements. A flight correspond to one aircraft trip between two distinct locations. A mission corresponds to a sequence of flights.

I had to break the instances in several smaller files because Internet Explorer was not able to handle very large files. Each file is around 700K. The movement requirement and the initial resource availability files contain the input to the Mission Planner. The Flight and Mission files contain the plan and schedule automatically generated by the system.

Tunisia Deployment Plan

  1. Tunisia Movement Requirements
  2. Tunisia Initial Resource Availability
  3. Tunisia Scheduled Flights
  4. Tunisia Scheduled Missions

Korea Deployment Plan

  1. Korea Movement Requirements 1
  2. Korea Movement Requirements 2
  3. Korea Initial Resource Availability
  4. Korea Scheduled Flights 1
  5. Korea Scheduled Flights 2a
  6. Korea Scheduled Flights 2b
  7. Korea Scheduled Flights 3
  8. Korea Scheduled Flights 4
  9. Korea Scheduled Flights 5
  10. Korea Scheduled Missions 1
  11. Korea Scheduled Missions 2
  12. Korea Scheduled Missions 3
  13. Korea Scheduled Missions 4
  14. Korea Scheduled Missions 5

Lessons Learned

The instance database was automatically created by translating the Mission Planner object model to the ontology representation created in homework 1. Since the scheduling ontology was created based on this object model, the translation process was trivial.

In the object model, each instance has a unique id. In the scheduling ontology, I had previously defined properties to represent these ids. However, since each DAML instance also has a unique id, I am using these internal object identifiers as identifiers for the DAML instances, and not using the corresponding properties as defined in the ontology. I am also using the ID field in the DAML language to represent the values of certain properties. I am not sure this is the correct or intended meaning of this construct. For example, to express the amount of passengers to be moved, I am using the construct:

 <pax-quantity ID="300"/> 

instead of:
 <pax-quantity>300</pax-quantity>

The main difficulty I encountered while generating this database was to check the correctness of the terminology used. I needed to browse through the ontology files to verify if I was using the correct terms and spelling. It is clear that this will be problematic for ontology users not familiar with its content. I was also forced to edit the original ontology files as additional terms that were not originally included in the ontology were needed. It would be useful to have some tools that would validate the database description based on the ontology and that would allow the fast insertion of terms into the original ontology. I also included certain entities in the database that have not been defined in the basic scheduling ontology.

The other problem I encountered was related to the size of the files. Considering the size of the database we are dealing with, the verbosity of the representation creates gigantic files. The Korea plan had initially more than 6M. I was forced to break it into several smaller pieces using a text editor. Since there are no tools currently available that would put the pieces together, one will have to load one file at a time to be able to browse through the entire plan. For transmission purposes, it would be useful to have a mechanism that would send the meta-data -- the structure of the daml schema, and the data as separate pieces. The client then would put the pieces together and fill the schemas with the corresponding data.

 

 

- Back to Top -


- Home - About Kestrel - Research Staff - Current Projects - Project Archive -
- Publications - Technology Transfer - Career Opportunities - Contact Kestrel -