Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Information Architecture Working Group October 24, 2015 Information Architecture WG.

Similar presentations


Presentation on theme: "1 Information Architecture Working Group October 24, 2015 Information Architecture WG."— Presentation transcript:

1 1 Information Architecture Working Group October 24, 2015 Information Architecture WG

2 2 Outline Introduction and Current Status DRAFT RASIM Green Book Updates/Suggestions RASIM Specifics IAWG Charter Updates Architectural Patterns from RASIM –Data Architecture –Software/Service Information Architecture Mission Operations Science –Mapping to Functional Space Domain Architecture

3 3 Status of WG RASIM DRAFT Green Book – May 2006 version –Major updates since Fall CCSDS Meetings (and NASA TIMs) Significant Discussions w/ MOIMS in terms of linking IA architectural models and MOIMS IPR work Ontology developed based on white book. Captured in Protégé Draft paper mapping CCSDS IA and Grid Concepts/Projects –Discussions w/ U.S. grid efforts at USC/ISI and Argonne Labs Portions are being included as part of the NASA Exploration Systems C3I/CEV JPL Instruments and Science Division defining a division architecture called “TDA” based on green book International Planetary Data Alliance using architecture as a guide

4 4 Info Arch DRAFT Green Book Suggestions/Updates General Changes/Suggestions 1.Some wording/phrasing suggestions implemented 2.Focus on service architecture for IA Response: Plan a best practice document specifically for this (see related item below) Section 2: 1. Reference meta models in section 2.3.1 in the registry taxonomy section 2. Clarify the use of the word “Object” vs “Class” 3. 1.2 Terminology - Model - Object -> Class 4. 2.1 Introduction - "An application information object is an independent, flexible model" -> "An application information object is an instance of an independent, flexible model" 5. 2.1 Introduction - "The main guiding principle of the information object is to separate the models of information..." -> "The guiding principle is to separate the models of information...“ 6. 2.1.1 Data Object - "This document focuses on the digital object specialization of the data object; the physical object specialization is not considered." -> "This document focuses on the digital object; the physical object is not considered.“ 7. 2.1.2 Metadata Objects - "a metadata object in this" -> "the class of metadata objects in this“ 8. Information Objects - "Information objects are components in information architecture that model both a granule of information" -> "Information objects are components in information architecture that model both a granule of information“ 9. Modeling Concepts - "Models are important in information architecture because they provide the means to describe and use objects. " -> "Models are important in information architecture because they provide the means to define object classes, instantiate objects, and use objects 10. Several other edits in the text to clarify "object instance" from "class". (I got tired of listing them all.) 11. This is old, but we did change “simple information object” to “standard information object” per Lou Reich

5 5 Info Arch DRAFT Green Book Updates Section 3: 1. In Section 3 talk about how systems and local/domain architectures will be devised Response: Plan a best practice document specifically for this 2. While physically it might not be evident that there are catalogs (i.e., in SSRs) make it clear they are there logically, at least 3. Table 3.1, add Solid State Recorder 4. Add metadata and meta-metadata objects as return object types for Metadata registry in taxonomy Section 4: 1. Ease up on implementation of IA concepts. Rather, discuss the relationships. Also, some changes to NVO/IVOA since IVOA is the international activity and NVO is local to the U.S. 2. Ease up on Globus Toolkit. NVO -> building grid middleware, didn't just adopt the Globus Toolkit. 3. Add sub-section on international interoperability efforts in space/earth sciences PDAP/IVOA 4. Add relationship to standards, future directions section at the end

6 6 Information Object Information Object: An information object consists of a data object and one or more metadata objects

7 7 Data and Metadata Objects Data Objects: Physical or digital objects. A physical object is a tangible thing (e.g., a moon rock) together with some representation information bringing to light the fact that any object that can be described with data is a data object. Without a metadata object the utility is decreased. No data structure is known… Metadata Objects: consistent with OAIS, RASIM metadata objects comprise representation and preservation description information as two broad classifications of metadata

8 8 Metadata Object

9 9 Taxonomy of Information Objects Information Objects based on concept of Application Information Object Various classes of information objects –Primitive Information Object – Those classes of objects which have no explicit descriptive metadata (E.g. Telemetry Packet) –Standard Information Object – Those classes of objects which have explicit descriptive metadata (E.g. Science observation such as an image) –Complex Information Package – information objects that encapsulate one or more information objects

10 10 Complex Information Object

11 11 Conceptual Information Architecture Interoperability Layers

12 12 Information Object Examples Planetary Data System: Information objects that are representative of the archival objects (metadata + data) from a NASA solar system mission Service Link Exchange: Information ojbects that are representative of service management objects used to establish a service agreement between agencies

13 13 Modeling Concepts An IO is prescribed by a domain model which is prescribed by a meta model Domain models model that relationship and attributes for a particular domain –Implemented with a meta model –Identify objects and attributes within the domain –Are necessary for describing domain information A meta-model is simply a model that prescribes another model. Meta models are useful for normalizing the definition of object models.

14 14 OMG Modeling Hierarchy

15 15 Meta Models Meta models are useful for normalizing the definition of object models. For example, –All data dictionaries can be described by a common meta model (E.g. DEDSL, ISO 11179) –Software models can be described by a common meta model (i.e. UML) Meta model definitions are fairly fluid. CCSDS needs to identify and define common meta models for its architecture and standards specifications.

16 16 Interoperability Across Domains

17 17 Software Components for Information Architecture Information Management Objects are used in space data software systems deployed onto a multitude of hardware hosts –Primitive Information Management Objects (pIMO) Simple functional objects Put, Get, and Find operations on the underlying data store –Advanced Information Management Objects (aIMO) Composed from one or more pIMOs Ingestion, retrieval, processing, distribution, and querying Defined within RASIM at an abstract level. Deployment style left to the domain architecture.

18 18 Primitive Information Objects Two types –Data Store Objects (DSO) –Query objects (QO) No sub-components Operate on a Physical Data Storage (i.e., tape drivers, hard disks, solid state recorders, RAM, flash memory) Physical Data Storage consists of: –Memory: physical location of the data –Handles: index catalog of pointers to the specific memory location

19 19 Advanced Information Management Objects Types Repository Service Objects Registry Service Objects Product Service Objects Archive Service Objects Query Service Objects

20 20 Repository Service Object Repository service objects are responsible for management of an underlying data store object or the physical data store.

21 21 Taxonomy of Repository Classes Repository Object TypeObject PropertiesObject Description Data StorePrimitive Component (e.g., DBMS, and File system). Basic Data Store component described in 3.1 sits behind Data Store Object and supports Repository Interface to get and put data (lower level data such as streams and bits). Operational ArchiveComponent that stores data products and higher level products, possibly including metadata. Supports retrieval of data products through possibly complex methods, and processing. No support for permanence. Stores products for short term (e.g., less than 10 years), and allows retrieval of products. Advanced Component supporting retrieval of possibly complex data products, including their metadata. Repository where writes are frequent and reads are frequent. Data products stored in this type of archive will be updated and versioned. Examples of products stored in this archive are command sequence products sent using spacecraft telemetry. Long-term ArchiveStores products for long term archiving, and supports basic archive functionality. Archive for long-term preservation of data products, and data permanence. Supports basic archive functional interfaces (e.g., get, put).

22 22 Registry Service Object The registry service object provides an interface to find/retrieve metadata objects from backend data stores.

23 23 Taxonomy of Registry Classes Registry TypeReturn Object TypesQuery Interface Parameters Metadata RegistryData Dictionaries, Data Elements Query for Data Element properties, or Data Element IDs, or Data Dictionary IDs Service RegistryService Endpoints, Service Metadata (interface properties, interface type, return schema) Query for Service properties Resource RegistryData Products, Resource Registry Locations Data Resource properties

24 24 Product Service Objects The product service object contains a repository service object, coupled with a query object, and a domain processing or transformation object. It enables applications to be constructed which can find/retrieve information objects from repositories.

25 25 Archive Service Objects Archive service objects are responsible for (a) ingestion of data objects into a repository, and (b) ingestion of metadata objects into an accompanying registry.

26 26 Query Service Object The query service object manages routing of queries in order to discover and locate product service objects, repository service objects and registry service objects which contain information to satisfy user queries.

27 27 Domain Processing Objects The domain processing object is a functional component that provides specialized processing of a data object to transform it from one object type to another.

28 28 Map of Software Components to Candidate Space Domain Functional Objects in RASDS Mission Planning Mission Analysis Monitor & Control Directive Generation Data Acquisition Directive Management Domain Data Models Local Data Models Repository Service Registry Service Query Service Product Service Common Schema & Dictionaries Representative Functional Objects Information Management Functional Objects Metadata / Resources Data Objects Query / Results

29 29 IAWG Charter The focus of this working group is to define a reference Space Information Architecture that encompasses the capture, management and exchange of data for both flight and ground environments across the operational mission lifecycle. Goals: 1. Define a reference end-to-end space information architecture for interoperability and cross-support that encompasses both flight and ground data system operations and provides a common framework for use by standards and systems developers. The reference space information architecture includes: a. standard functional components for information management b. definition of standard interfaces for information management c. standards in information representation d. standards in defining information processes 2. Define and leverage common methods for representing information architectural views; and 3. Address application layer information management issues including application protocols and data handling and ensure that they are dealt with in a clear and consistent way throughout the end-to-end system; and 4. Work with the SEA System Architecture and MOIMS WGs Should we consider generating best practice guides for application of RASIM (e.g., patterns for various domain problem areas)?

30 30 Architectural Patterns/Best Practices Data Architecture Software/Service Information Architecture –Mission Operations –Science Mapping to Functional Architectures

31 31 Concept of Data Architectural Model

32 32 Example Science Service Information Architecture – Discovery/Access Patterns Common Meta Models for Describing Space Information Objects Common Data Dictionary end-to-end Query Integration Node 1 Profile Server XML Request Information Object XML Request Info Object XML Request Resource Catalogs Repository Product Server Information Object Sci/Eng Products Sci/Eng Products Web I/F Desktop I/F XML Request Information Object Name Server Repository Product Server Sci/Eng Products Node 1 Profile Server Node 1 Profile Server Registry Server Repository/Archive Server … Name Server Service Registry XML Request Information Object WSDL

33 33 Planetary Data Access Protocol Pattern from NASA PDS/ESA PSA interoperability pilot

34 34 Example Science Service Information Architecture – Archive/Capture Pattern

35 35 Mapping IA to Functional Architecture Space Domain Model External Science Community Data Acquisition and Command Mission Operations Instrument /Sensor Operations Science Data Archive Science Data Processing Data Analysis and Modeling Science Information Package Science Team Relay Satellite Spacecraft / lander Spacecraft and Scientific Instruments Primitive Information Object Simple Information Object Telemetry Information Package Science Information Package Instrument Planning Information Object Science Information Package Science Products - Information Objects Planning Information Object Science Information Package Common Meta Models for Describing Space Information Objects Common Data Dictionary end-to-end


Download ppt "1 Information Architecture Working Group October 24, 2015 Information Architecture WG."

Similar presentations


Ads by Google