1

Information Architecture Working GroupApril 20, 2023

Information Information Architecture WGArchitecture WG

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

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

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

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

Information Object

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

Information Object

Data Object

MetadataObject

describes

1 *

1

1 1

*

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

Metadata Object

MetadataObject

Representation Information

Preservation Description

Structure Information

Semantic Information

Context Information

ReferenceInformation

ProvenanceInformation

Fixity Information

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

Complex Information Object

Complex Information

Object

Application Information

Object

MetadataObject

describes

1 1

*

1 1

1

11

Conceptual Information Architecture Interoperability

Layers

Middleware and Messaging

Comm Layer

Metamodel

Information Components

ApplicationInformation

Object

Domain Model

Metamodel

Information Components

ApplicationInformation

Object

Domain Model

Middleware and Messaging

Comm LayerCommon Protocols - TCPIP, ...

Common Messaging - SOAP, JMS, ...

Common Functions - Registry, Repository, ...

Common or Mediated Metamodel - DEDSL, ISO1179, UML

Common or Mediated Domain Models --Planetary Data Systems, EOSDIS, ...

Information Exchange - Science, Mission, etc, Data Products, Observations, SLE Objects, ...

Communications

Software/Application

Data Architecture/ Content

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

Modeling Concepts

Application Information Object

(AIO)

Data Object

Metadata Object

described by

Metamodels

Domain Models

DataDictionary

Schema/Ontology

prescribed by

instance of

prescribed by

• 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

OMG Modeling Hierarchy

M3

M2

M1

M0

ISO11179 UML model

MOF( Meta- Oject Facility)

Domainmodel

DataDictionary

MODELS

XMLSchema

M3

M2

M1

M0

ISO11179 UML model

MOF( Meta- Oject Facility)

Domainmodel

Application Information

Object

DataDictionary

MODELS

XMLSchema

OMG - Hierarchy of Models

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

Interoperability Across Domains

Classification Category

Normative Constructs

Normative AbstractedStructure (Metaphor)

Structuring Rules

Meta Model

Domain AData Model

Domain BData Model

Domain BData Model

Prescribes Prescribes Prescribes

Domain A Domain B

Describes

DescribesDescribes

Something to beinterchanged

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

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

Advanced Information Management Objects Types

• Repository Service Objects

• Registry Service Objects

• Product Service Objects

• Archive Service Objects

• Query Service Objects

20

Repository Service Object

<<Component>>

Repository Service Object

<<Component>>

Data Store Object

1

1

<<Interface>>

Repository Request

+get(identifier): AIO+put(AIO):identifier

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

21

Taxonomy of Repository Classes

Repository Object Type Object Properties Object Description

Data Store Primitive 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 Archive Component 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 Archive Stores 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

Registry Service Object

<<Component>>

Registry Service Object

1

1

<<Component>>

Query Object

<<Component>>

Data StoreObject

1

1

Has a

Has

a

<<Interface>>

Metadata Query

+query(expression):metadata object

• The registry service object provides an interface to find/retrieve metadata objects from backend data stores.

23

Taxonomy of Registry Classes

Registry Type Return Object Types Query Interface Parameters

Metadata Registry Data Dictionaries, Data Elements

Query for Data Element properties, or Data Element IDs, or Data Dictionary IDs

Service Registry Service Endpoints, Service Metadata (interface properties, interface type, return schema)

Query for Service properties

Resource Registry Data Products, Resource Registry Locations

Data Resource properties

24

Product Service Objects

<<Component>>

Product Service Object

1

1

<<Component>>

Query Object

<<Component>>

Repository Service Object

1

1

Has a

<<Component>>

Domain Processing Object

1

1U

ses

<<Interface>>

Product Service

+query(expression):IO

• 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

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.

<<Component>>

Archive Service Object

1

1

<<Component>>

IngestService Object

<<Component>>

Repository Service Object

1

1

Uses

<<Component>>

Registry Service Object

1

1

Has A

<<Interface>>

Archive Service

+ingestPackage(IO):Identifier+retrievePackage(Identifier):IO

26

Query Service Object

<<Component>>

Query Service Object

1

1

<<Component>>

Query Object

1

*

Com

municates

With

<<Component>>

Domain Processing Object

1

1

<<Component>>

Registry Service Object

1

*

<<Component>>

Repository Service Object

<<Interface>>

Query Service

+query(expression):IOs

Has a

• 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

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

Map of Software Components to Candidate Space Domain Functional

Objects in RASDS

MissionPlanning

MissionAnalysis

Monitor &Control

DirectiveGeneration

DataAcquisition

DirectiveManagement

Domain Data

Models

Local Data

Models

RepositoryService

RegistryService

QueryService

ProductService

Common Schema &

Dictionaries

RepresentativeFunctional

Objects

InformationManagement

FunctionalObjects

Metadata /Resources

DataObjects

Query /Results

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

Architectural Patterns/Best Practices

• Data Architecture

• Software/Service Information Architecture– Mission Operations– Science

• Mapping to Functional Architectures

31

Concept of Data Architectural Model

Data Object

<TITLE>Cassini Saturn Image

</TITLE><MimeType>

Image/JPEG<MimeType><Resource Location>

http://…</Resource Location>

<TARGET_NAME>Saturn

</TARGET_NAME><SPACECRAFT_NAME>Cassini

</SPACECRAFT_NAME>

MetadataObject

Schema(aka XSD)

Implements

Describes…

Data Dictionary Defines…

Data Elements

Data Element Model(ISO 11179)

Vocabulary

Information Object

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 1Profile Server

XML Request

Information Object

XML Request

Info

Ob

ject

XM

L R

eque

st

ResourceCatalogs

Repository Product Server

Information Object

Sci/Eng Products

Sci/EngProducts

Web I/F

Desktop I/F

XML Request

Information Object

Name Server

Repository Product Server

Sci/Eng Products

Node 1Profile Server

Node 1Profile Server

Registry Server

Repository/ArchiveServer

…

Name ServerService Registry

XML Request

Information Object

WSDL WSDL

33

Planetary Data Access Protocol

• Pattern from NASA PDS/ESA PSA interoperability pilot

34

Example Science Service Information Architecture – Archive/Capture

Pattern

Repository Server

(Process, Catalog, Version andArchive)

MetadataRegistry

Data Dictionary, XML Product Schemas

Validate

Data setRule-base

Data set1

Data set2

Data setn

Agent 1

ProductCatalog (DE-based)

Science & Engineering Applications

Information Objects (incl Information Packages)

Agent 2

Agent N

Science Missions

Ingest Data ProductsIOs (Meta + Data)

ProcessExecute

Database

Repositories

Repository Server

(Process, Catalog, Version andArchive)

Repository Server

(Process, Catalog, Version andArchive)

Information Objects (incl Information Packages)

Science & Engineering

Portals

35

Mapping IA to Functional Architecture Space Domain

Model

External Science

Community

Data Acquisition

and CommandMission

OperationsInstrument /Sensor Operations

ScienceData

Archive

ScienceData

Processing

Data Analysis and

Modeling

Science Information Package

Science Team

Relay Satellite

Spacecraft / lander

Spacecraft andScientific Instruments

Primitive Information Object

Primitive Information Object

Simple Information Object

Telemetry Information Package

Science Information Package

Instrument Planning

Information Object

Science Information Package

Science Products - Information Objects

PlanningInformation

Object

Science Information Package

• Common Meta Models for Describing Space Information Objects• Common Data Dictionary end-to-end