![]() |
Home : Current Projects : Darpa Markup Language : Homework 3 |
|
|
Homework 3Deployment plans represented using the DAML Schedule OntologyDescriptionThe 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
Korea Deployment Plan
Lessons LearnedThe 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 -
|