Data Model Management for Space Information Systems

1
Data Model Management for Space Information
Systems

• Steve Hughes, Daniel Crichton, Chris Mattmann,
  Paul Ramirez
• November 19, 2009
• SpaceOps 2006
• Advanced Technologies for GS Design/Dev III Track

2
Outline

• Problem Significance
• Data Engineering Challenges
• Proposed Solution
• Case Study and Experience
• Conclusion

3
Example Scenario
PDS Data Model Completed in 1990 Formally
captured using E-R Model
15 years of evolutionary changes represented in
3 models/languages implemented using 3 different
technologies

• How
• Is a data model to be maintained over time,
  independent of its implementation
• Is interoperability between data models to be
  managed

PDS data model adopted by ESA/PSA but managed
independently Interoperability prototype in
development International Planetary Data Alliance
being chartered.
4
Problem Significance

• Example Scenario is a highly representative
  problem for the entire product life-cycle, from
  instrument data collection, to gound data system,
  to archive.
• Cross-domain
• Similar situations exist across all space science
  disciplines planetary science, astrophysics,
  space physics, and earth science.

5
Problem Definition

• The management of data models for diverse domains
  involving a large number of complex entities and
  relations.
• Manage both evolutionary change and continuous,
  significant additions to the model.
• Maintain data model independent of any
  implementation.
• Use model to drive implementation.
• Enable interoperability between domain models.
• Construct a data model framework that can handle
  the above problems across agency boundaries.

6
Challenges

• How do we manage such large, highly complex data
  models?
• What requirements are imposed on these data
  models?
• What are the data engineering challenges
  regularly faced?

7
Requirements

• Independence - Exist as an independent,
  comprehensive source for the data modeling
  information
• Scalability number and complexity of classes,
  relations, and attributes
• Evolvability for classes, relations, and
  attributes.
• Enable translation as required to different
  notations/models for documentation,
  communication, and implementation.

8
Requirements (contd.)

• Maintain the upper bound on semantic richness for
  the domain model
• Provide access for multiple distributed users

9
Key Data Engineering Challenges

• Challenges
• Independence
• Complexity
• Flexibility
• Accessibility
• Usability

10
Data Engineering Challenges

• Independence
• The Reference Architecture for Space Information
  Management (RASIM) suggests the separation of the
  data model from software components to promote
  the development of flexible information
  management systems.
• The data model must be allowed to evolve
  independent of technology.
• Product types evolve over time
• New product types are requested continuously.
• Domain context evolves (Optical media -gt Online
  access, same instrument on multiple hosts flown
  in formation)
• Data model outlives any implementation technology
  (i.e. Centralized, Client/Server, WEB, Semantic
  WEB)

11
Data Engineering Challenges

• Complexity/Scalability
• Solar system exploration missions are flying more
  complex instruments that produce larger numbers
  of data product types for which scientists and
  engineers are requesting evermore information in
  support of mission operations, science data
  processing and analysis, and archive. (Note
  exponential data volume growth issues are
  relatively simple by comparison.)

12
Data Engineering Challenges

• Flexibility
• The data model must be translated into notations,
  languages, and models for documentation,
  communication, and implementation.
• Information loss is only acceptable when due to
  limitations of target notation.

13
Data Engineering Challenges

• Accessibility
• The data model must be available for use by a
  distributed community as an online electronic
  resource.

14
Data Engineering Challenges

• Usability
• The data model must be available for use in a
  commonly accepted notation, understood by readily
  available processors.

15
Ontology Tools

• Primarily the result of Artificial Intelligence
  Research
• Tools designed to capture the information
  resulting from answering the what is question.
• Typically focus on the definition of classes and
  attributes, with relations implemented as
  attribute values of class instances.
• Information is stored in a tool database using a
  number of possible notations. (Frames, XML,
  RDF/XML, OWL)
• Plug-ins are typically developed for the
  translation to external notations (RDF/XML, OWL,
  XMI)

16
Applicability

• Ontologies are receiving increased attention in
  the fields of Earth and Space Sciences and some
  significant development efforts and production
  applications are starting to appear.
• Knowledge representation languages and ontologies
  are providing the formal foundation for encoding
  the semantics in the semantic web and the
  semantic grid.
• Earth and Space Science is well positioned to
  benefit from progress in the areas of the
  Semantic Web and the Semantic Grid.

17
Modeling Principles

• Model everything significant
• Develop common attributes
• Almost everything has at least an unique
  identifier, title, and description
• Capture at least generalization, aggregation, and
  association relations.

18
Case Study NASAs Planetary Data System

• Planetary Data System
• Official NASA Archive for all Planetary Data
• Data ingestion required as part of Announcement
  of Opportunity (AO) for a mission
• 9 Nodes with data located at discipline sites
• Common Data Model
• Different data systems located at the sites
• Interoperability being explored with
  international agencies

19
PDS Data Model

• Intially captured as structure diagrams and data
  dictionary
• Formalized using E-R Model
• Implemented in relational model (Planetary
  Science Data Dictionary)
• Captured in archive using Object Descrition
  Language (ODL)
• Initially over 50 entities and 1200 data elements

20
PDS Ontology

• Used Stanfords Protégé ontology tool
• Entities became Classes
• Attributes became Slots
• Relations implemented as class hierarchy or
  simple value slots or slots with value type of
  class instance
• Information extracted directly from relational
  data dictionary tables and referential integrity
  rules
• Hardcopy documentation used to complete model

21
Documenting and Visualization

• Web browsing of HTML
• Novel visualization plugins
• UML Class diagrams from XMI export

22
Information Export
ltrdfsClass rdfabout"rdf_Data_set
rdfslabel"Data_set"gt ltrdfssubClassOf
rdfresource"rdfsResource"/gt lt/rdfsClassgt ltrd
fProperty rdfabout"rdf_archive_status
rdfslabel"archive_status"gt ltrdfsdomain
rdfresource"rdf_Data_set"/gt ltrdfsrange
rdfresource"rdfsLiteral"/gt lt/rdfPropertygt ltr
dfProperty rdfabout"rdf_data_set_name
rdfslabel"data_set_name"gt ltrdfsdomain
rdfresource"rdf_Data_set"/gt ltrdfsrange
rdfresource"rdfsLiteral"/gt lt/rdfPropertygt

• Schema export to RDFS/XML
• Data export to RDF/XML
• Export to OWL

ltrdf_Data_set rdfabout"rdf_vo1/vo2-m-vis-2-ed
r-v2.0" rdf_data_set_name"VO1/VO2 MARS
VISUAL IMAGING SS EXPRMNT DATA RECORD V2.0"
dctitle"VO1/VO2 MARS VISUAL IMAGING SS EXPRMNT
DATA RECORD V2.0"gt ltrdf_target_namegt
ltrdfDescription rdfabout"termsmars"gt
ltrdfslabelgtMARSlt/rdfslabelgt
lt/rdfDescriptiongt lt/rdf_target_namegt
ltrdf_archive_statusgt ltrdfDescription
rdfabout"termsarchived"gt
ltrdfslabelgtARCHIVEDlt/rdfslabelgt
lt/rdfDescriptiongt lt/rdf_archive_statusgt lt/rdf
_Data_setgt
23
Semantic Browsing

• RDF/XML - RDFS/XML Knowledge Base configured for
  Semantic Browsing
• (Longwell/Knowle)
• Supports facet- and text-based search
• Data and Schema information is collocated.
• Multiple name spaces/ models may be collocated

24
Interoperability

• Something to be interchaged between two or more
  domain models
• Requires common meta-meta model

25
Related Work

• A Reference Architecture for Space Information
  Management, Proposed CCSDS Green Book
• Semantic Technologies
• RDF/XML, RDFS/XML, OWL, XMI
• Protégé Ontology Tool
• Longwell Suite of Semantic Browsers

26
Conclusion

• An ontology tool framework provides many
  capabilities for managing data modelinging issues
• Management of data models for diverse domains
  involving a large number of complex entities and
  relations.
• Manage both evolutionary change and continuous,
  significant additions to the model
• Maintain data model independent of any
  implementation.
• Provides means for the model to drive
  implementation.
• Enables interoperability between domain models.
• Management of data models across agency
  boundaries.

27
Recent Refereed Papers

• J. Steven Hughes, D. Crichton, S. Kelly, C.
  Mattmann, J. Crichton, and T. Tran. Intelligent
  Resource Discovery using Ontology-based Resource
  Profiles. Data Science Journal, Vol. 4, No. 31,
  December 2005.
• C. Mattmann, D. Crichton, N. Medvidovic and S.
  Hughes. A Software Architecture-Based Framework
  for Highly Distributed and Data Intensive
  Scientific Applications. In Proceedings of ICSE,
  Shanghai, China, May 20th-28th, 2006.
• J. Steven Hughes, D. Crichton, S. Kelly and C.
  Mattmann. The Semantic Planetary Data System. In
  Proceedings of the 3rd Symposium on Ensuring
  Long-term Preservation and Adding Value to
  Scientific and Technical Data (PV-2005), The
  Royal Society, Edinburgh, UK, November 21-23,
  2005.

28
Questions?

• Thanks for your attention!