The Mars Odyssey Middleware Architecture for the Planetary Data System

1
The Mars Odyssey Middleware Architecture for
the Planetary Data System

• J. Steven Hughes
• Daniel Crichton
• Quality Mission Software Workshop (QMSW)
• May 7-9, 2002
• MIDDLEWARE SESSION

2
Outline

• An Overview
• The Data
• The Data Model
• The Organization
• The Distribution Problem
• A New Approach
• The Architecture
• Product Servers
• Profile Servers
• Middleware
• Conclusion

3
An Overview
4
The Data

• Variety and Volume
• 5TB of data from 30 years of exploration
• 700 Data Sets
• 1700 Archive Volumes CD/DVDs
• Camera, Spectrometer, LECP, SAR, RS,
• Images, Time_Series, Spectra, Qubes
• Binary and ASCII
• Spacecraft and Earth Based
• Many data representations
• Maintain original bits and emulate as needed

5
The Data Model
Level Group/Element Structure ___________________
______________________ 1 spacecraft instrument
identification group 2 instrument
identification 2 instrument name
2 spacecraft identification 2 instrument
type 1 instrument description ... 1 filter
group 2 filter name 2 filter
number 2 filter type ...
6
An Image Label
DATA_SET_ID "VO1/VO2-M-VIS-5-DIM-V1.0" SPACECRA
FT_NAME VIKING_ORBITER_1, ... TARGET_NAME
MARS IMAGE_ID MG88S045 IMAGE
2 SOURCE_IMAGE_ID "383B23", "421B23",
... INSTRUMENT_NAME VISUAL_IMAGING_SUBSYSTEM
... NOTE "MARS DIGITAL IMAGE
... OBJECT IMAGE LINES 160
LINE_SAMPLES 252 SAMPLE_TYPE
UNSIGNED_INTEGER SAMPLE_BITS 8
SAMPLE_BIT_MASK 211111111 CHECKSUM
2636242 END_OBJECT
7
Categories of Meta-Data

• Data Represenation
• Data Representation
• ITEM_TYPE VAX_INTEGER
• File Attributes
• RECORD_TYPE FIXED_LENGTH
• RECORD_BYTES 252
• Data Organization
• LINES 160
• LINE_SAMPLES 252
• SAMPLE_TYPE UNSIGNED_INTEGER
• SAMPLE_BITS 8
• Catalog
• Identification
• DATA_SET_ID "VO1/VO2-M-VIS-5-DIM-V1.0
• IMAGE_ID MG88S045
• INSTRUMENT_NAME VISUAL_IMAGING_...
• Observation Context
• FILTER_NAME CLEAR

8
The Organization
ATMOSPHERES
GISS
New Mexico State University
ARC
GEOSCIENCES
GSFC
CENTRAL NODE
Stanford
Washington University
UV (tbd)
Wash U
JPL
Brown/Hawaii
MIT

Austria
Germany
Consortium of PDS Nodes
PLANETARY
PLASMA INTERACTIONS
UCLA
NAIF
JPL
Iowa
Stanford
UCLA
Stanford
University of Maryland
PSI
USGS
Flagstaff, AZ
UofHI
IMAGING
Ames Research Center
UofAZ
Budapest
SMALL BODIES
JPL
Johns Hopkins
Stanford
RINGS
9
The Distribution Problem
10
Current PDS Data Distribution

• Receive archive copies of data from flight
  projects
• PDS helps planetary missions to create high
  quality data archives and to release them in a
  timely manner
• Validate data for compliance to PDS standards
• PDS assembles, publishes, distributes, and
  maintains peer-reviewed, documented planetary
  data sets
• Generate CD-ROMs or DVD-ROMs for archive and
  distribution
• Distribute data to the community on media data
  also available on-line

11
Current PDS Online Data Access

• Data product search and retrieval
• Discipline expertise is local, at the nodes
• Data placed online in local repositories
• Product catalogs developed for local repositories
• Voyager images (50 attributes)
• Galileo images (gt100 attributes)
• MGS MOC images (41 attributes)
• Custom user interfaces developed for local
  repositories
• Primary customers are discipline oriented
• Data set search
• Search for data sets across the entire archive is
  relatively easy because of the single high level
  model

12
The Problems

• Large volumes of data will not allow the
  distribution of hard media due to media costs
• There exists no high level global data product
  search

13
Drivers for PDS On-Line Data Distribution

• Increased data volumes too much for PDS CD
  distribution system
• MGS CD costs exceeded 500K for 600GB
• THEMIS alone will produce over 4TB of data
• CD/DVD distribution too costly and cumbersome
• Data will be physically distributed among various
  sites and sources
• Scientists want online access to all available
  data

14
Mars Exploration Program Very Large Data Volumes
15
A New Approach
16
New PDS Data Distribution Approach Goals

• Online access should be the primary method for
  data distribution, with improved tools to support
  it
• Find out what data exist
• Select data of interest
• Retrieve data
• Correlate data across instruments, missions, and
  nodes
• Data should be made publicly available as soon as
  possible
• Copies on physical media should be available on
  demand
• Special collections containing data of high
  interest should be published on physical media
• Copies of complete data sets on cost-effective
  physical media for long term archives at PDS and
  NSSDC (minimum 3 copies) will still be required

17
New PDS Data Distribution Approach Benefits

• Access for all PDS Mars data across all PDS Nodes
• Design a system to scale to all Mars data
• Begin with Odyssey
• Incorporate THEMIS team as a PDS data node
• Ultimately include entire archive
• Benefits of online access
• Reduces distribution costs
• Provides cross-comparability of data across
  missions
• Moves toward a usable Mars data base
• Allows users who need media to download data
  electronically and write CD/DVD on demand

18
The Plan

• Implement multi-tiered architecture
• Clients
• Middleware
• Data and Metadata Services
• Use existing PDS subsystems
• Custom User Interfaces
• Data repositories
• Catalog databases
• Remain geographically distributed and locally
  managed
• Use archive metadata to its full potential

19
The Architecture
20
Information Architecture in a Nutshell

• Profiles describe and provide location for
  anything of interest
• Things of interest
• Data Sets, Data Set Browsers, Data Products,
  Volumes, Websites, Web Applications, etc
• Written as XML documents
• Grouped
• Data Product profiles grouped by data set
• All others grouped into single database
• Provide sufficient information to describe and
  locate resources
• Helps determines if the resource can resolve a
  user query
• Profile Servers serve profiles
• Allow search and retrieval of profiles
• Distributed for local management and scalability
• Access profile databases
• Static profiles stored as XML documents
• Dynamic profiles generated from information
  stored in databases

21
System Architecture in a Nutshell (cont)

• Product Servers serve Data Products
• Data Products are served from data repositories
• Input unique product identifiers
• Output products in the requested formats
• Middleware
• Uses XML documents for communication
• Common language and protocols
• XML profiles for resource descriptions
• XMLQUERY for queries
• Implements message passing protocol for
  distributed processing
• Web service encapsulation of existing resources
• Product servers for data repositories
• Profile servers for catalogs

22
PDS-D (Distribution) D01
Single Point of Entry Interface (Data Set View)
DVD Volume
Physical Volume
OODT Middleware
Virtual Volume
Virtual Volume
Volume Server
InQuery OutProfiles
InQuery OutData Products
Data Products
Product Servers
Data Products and Metadata
MARIE, PDS PPI
Documents and Ancillary Files PDS CN
THEMIS ASU
Radio Science PDS GEO
SPICE PDS NAIF
GRS PDS GEO
ACCEL PDS ATMOS
23
Product Servers

• Product Servers serve archive data products
• Provide a standard interface to data product
  repositories for the retrieval of data products
• Java server
• Generic server receives and returns XML queries
• Data source interface extends server
• Multiple communication path besides XML
• Scalable Implementation
• Performance
• Deployment
• Automated ability to query status of product
  servers across a community
• Automated ability to automatically update
  software
• Less time required to add new product interfaces
• Support for a variety of backend data system
  interfaces

24
Product Server Requirements

• A product server shall retrieve data products
  from a data repository
• For retrieval, a product server shall return the
  data product identified by a unique product
  identifier. (e.g. volume_id/directory path/ file
  name/ file extension pointing to the PDS label
  file.)
• A product server shall return the data product in
  the specified format. (based on local
  requirements)

25
Product Server Architecture
HTTP, IIOP, Java, C APIs
HTTP, IIOP, Java, C APIs
Distributed Product Servers
Java Server Framework
Java Server Framework
Data Source Interface For Dynamically Loaded
Query Handlers
Data Source Interface For Dynamically Loaded
Query Handlers
Database access
File system access
Distributed Data Repositories
26
Product Server Interfaces
HTML User Interface
PDS JAVA User Interface
PDS C User Interface
IDL User Interface
ISYS User Interface
ENVI User Interface
Distributed Clients
Middleware
Distributed Product Servers
27
Product Server PDS-D D01 Implementations

• THEMIS - PDS.ASU.PRODSERV.ODY_M_THEMIS
• to be used by the Atlas
• GRS - PDS.GEO.PRODSERV.ODY_M_GRS
• to be used by the Atlas
• MARIE - DITDOS
• SPICE - DITDOS?
• ACCEL - PDS.ATMOS.PRODSERV.ODY_M_ACCEL
• to be used by a Default Browser
• RS - PDS.GEO.PRODSERV.ODY_M_RS
• to be used by a Default Browser

28
Product Server Query
http//starbrite.jpl.nasa.gov/servlet/jpl.oodt.ser
vlets.Product_Servlet? keywordQueryFILE_SPECIFI
CATION_NAME/ody_2001/xxx/H0133.DAT
object PDS.ASU.PRODSERV.ODY_M_THEMIS
mimeTypeoctet mimeType/
IIOP//PDS.ASU.PRODSERV.ODY_M_THEMIS Message
XMLQuery FILE_SPECIFICATION_NAME/ody_2001/xxx/H
0133.DAT
XMLQuery FILE_SPECIFICATION_NAME/, MIME(BASE6
4(ZIP(H0133.DAT))
Result
29
XML Query Example (1 of 2)
ltquerygt ltqueryAttributesgt ltqueryIdgt1.2.3.4lt/qu
eryIdgt ltqueryTitlegtQuery Examplelt/queryTitlegt
ltqueryDescgtQuery for INSTRUMENT_ID
HENDlt/queryDescgt ltqueryTypegtQUERYlt/queryTypegt
ltqueryStatusIdgtACTIVElt/queryStatusIdgt
ltquerySecurityTypegtUNKNOWNlt/querySecurityTypegt
ltqueryRevisionNotegt2000-05-12 JSH V1.2 Updated
for new

prof.dtdlt/queryRevisionNotegt ltqueryDataDictIdgt1.
2.3.5lt/queryDataDictIdgt lt/queryAttributesgt
ltqueryResultModeIdgtATTRIBUTElt/queryResultModeIdgt
ltqueryPropogationTypegtBROADCASTlt/queryPropogationT
ypegt ltqueryPropogationLevelsgtN/Alt/queryPropogatio
nLevelsgt ltqueryMaxResultsgt100lt/queryMaxResultsgtltq
ueryResultsgt0lt/queryResultsgt ltqueryKWQStringgtINST
RUMENT_ID HENDlt/queryKWQStringgt
30
XML Query Example (2 of 2)
ltquerySelectSetgtlt/querySelectSetgt
ltqueryFromSetgtlt/queryFromSetgt ltqueryWhereSetgt
ltqueryElementgt lttokenRolegtelemNamelt/tokenRolegt
lttokenValuegtINSTRUMENT_IDlt/tokenValuegt
lt/queryElementgt ltqueryElementgt
lttokenRolegtLITERALlt/tokenRolegt
lttokenValuegtHENDlt/tokenValuegt lt/queryElementgt
ltqueryElementgt lttokenRolegtRELOPlt/tokenRolegt
lttokenValuegtEQlt/tokenValuegt lt/queryElementgt
lt/queryWhereSetgt ltqueryResultSetgt.lt/queryResultS
etgt lt/querygt
31
Profiles

• Profiles describe and provide the location for
  anything of interest
• Things of interest (data and system resources)
• Data Sets, Data Set Browsers, Data Products,
  Volumes, Websites, Web Applications, etc
• Written as XML documents
• Grouped
• Data Product profiles grouped by data set
• All others grouped into single database
• Provide sufficient information to determine if
  the resource can resolve a user query

32
Profiles (cont)

• The profAttributes (Profile Attributes) section
  describes the profile.
• The resAttributes (Resource Attributes) section
  describes the resource using a common set of
  keywords (Dublin Core)
• The profElement (Profile Element) section
  describes the resource using domain specific
  attributes (PDS keywords)

33
PROFILE DTD
lt!ELEMENT profiles (profile)gt lt!ELEMENT
profile (profAttributes, resAttributes,
profElement)gt lt!ELEMENT profAttributes
(profId, profVersion?, profType,
profStatusId, profSecurityType?, profParentId?,
profChildId, profRegAuthority?,
profRevisionNote, profDataDictId?)gt
lt!ELEMENT resAttributes (Identifier,
Title?, Format, Description?, Creator,
Subject, Publisher, Contributor, Date,
Type, Source, Language, Relation,
Coverage, Rights, resContext,
resAggregation?, resClass, resLocation)gt
lt!ELEMENT profElement (elemId?, elemName,
elemDesc?, elemType?, elemUnit?,
elemEnumFlag, (elemValue (elemMinValue,
elemMaxValue)), elemSynonym,
elemObligation?, elemMaxOccurrence?,
elemComment?)gt
34
Data Product Profile (ODYSSEY HEND)

• -ltprofilegt
• -ltprofAttributesgt
• ltprofIdgt1.3.6.1.4.1.1306.2.104.10018791lt/prof
  Idgt
• ltprofVersiongtnulllt/profVersiongt
• ltprofTypegtprofilelt/profTypegt
• lt/profAttributesgt
• -ltresAttributesgt
• ltIdentifiergtODY-M-HEND-EDR-2-V1.0H0133lt/Iden
  tifiergt
• ltTitlegtData_Set_Name ODYSSEY-MARS-HEND-EDR-2
  -V1.0 Product_IdH0133lt/Titlegt
• ltDescriptiongtnulllt/Descriptiongt
• ltresContextgtNASA.PDSlt/resContextgt
• ltresAggregationgtnulllt/resAggregationgt
• ltresClassgtdata.granulelt/resClassgt
• ltresLocationgtiiop//PDS.ProfServer.GEO.ODY.GR
  Slt/resLocationgt
• lt/resAttributesgt
• -ltprofElementgt
• ltelemNamegtFILE_SPECIFICATION_NAMElt/elemNamegt
• ltelemValuegt/ody_2001/xxx/H0133.DATlt/elemValue
  gt
• lt/profElementgt

35
Profile Server

• Profile Servers serve profiles
• Allow search and retrieval of profiles
• Retrieves from profile databases
• Static profiles stored as XML documents
• Dynamic profiles generated from information
  stored in databases
• Distributed for local management and scalability

36
Profile Server Requirements

• A profile server shall search and retrieve
  profiles from a profile database
• For search, a profile server shall allow any
  profile attribute as a query constraint. Profile
  attributes include those from the profile
  element, resource attribute, and profile
  attribute sections of the profile document.
• For retrieval, a profile server shall return
  matching profiles. The user can request the
  complete profile or any subset of the profile.

37
Profile Server Specialization

• A profile server can be either Type A or Type B
• A type A (static profile) profile server,
  searches and retrieves profiles stored as XML
  documents.
• A type B (dynamic profile) profile server stores
  the profile information in a database (e.g.
  relational). It formats search results into XML
  document formats. Type B profile servers are
  appropriate as interfaces to traditional
  catalogs.

38
Profile Server Interfaces

• Accepts an XMLQUERY XML document as input
• Optional servlet to convert keyword/value query
  to XMLQuery

39
Object Oriented Data Technology (OODT)Principles

• Location Independence
• Information Hiding
• Model driven architecture
• Decouple solutions from platform specific
  technology
• Adopted by OMG
• Allows data architecture and technology
  architecture to evolve independently
• The technology architecture supports the data
  architecture (i.e. it supports the model)
• Scalable, Extensible
• Client APIs for locating and accessing
  distributed data products

40
OODT Architecture

• Address two key architectural focuses
• Technology Architecture
• Basic communication between geographically
  distributed data systems
• Framework for plugging in new data systems
• Data Architecture
• Standard method for describing data (profile)
• Standard method for exchanging data (XMLQuery)

41
OODT Technology Architecture

• Implemented in Java
• Data layer implemented with XML
• Uses CORBA for remote object invocation
• JacORB
• SSL for data encryption
• Uses a standardized XML DTD (XMLQuery) as the
  messaging format (See oodt/dtd/xmlquery.dtd)
• Supports a variety of client access methods
• Java API
• HTTP
• C API

42
Conceptual PDS Implementation
Name Server
Web I/F
Query Server
Node 1 Profile Server
XMLQuery
Web server Plugins
Web Server
XMLQuery
Node 1 Catalog
Node 1 Product Server
XMLQuery
QueryClient
XMLQuery
Desktop I/F
XMLQuery
Node 1 Products
XMLQuery
Node 2 Profile Server
XMLQuery
XMLQuery
XMLQuery
Node 2 Catalog
XMLQuery
Node 2 Product Server
Node 2 Products
Client Environment
Central Node
Discipline Node
43
About OODT

• Object Oriented Data Technology (OODT) was funded
  starting in 1998 by the Office of Space Science
  to address future data system architectures and
  interoperability needs. It's major focus has
  been the capture, location, access and exchange
  of distributed data products.
• OODT has focused on PDS needs as a key customer
• Input from the ISAIA project
• Specifically addresses distributed heterogeneous
  data system interoperability issues
• Prototype developed to demonstrate applicability
  to PDS
• PDS-D D01 implementation

44
About OODT (cont)

• OODT has addressed needs across a wide variety of
  science disciplines and is working with several
  groups
• National Institutes of Health
• National Cancer Institute (Early Detection
  Research Network)
• Seawinds, Quikscat
• DSMS standards program (Peter Shames area)
• Virtual Pediatric Intensive Care Unit (pilot data
  sharing architecture between Children's Hospital
  LA and Johns Hopkins Medical Institute)
• JPL Institutional Computing and Information
  Services for enterprise data management services
• Research in simulation and modeling

45
PDS-D Data Distribution

• PDS-D designers examined three ways to get to
  the data
• Subscription/Notification - data or notification
  sent to users
• Global Product View - product-level search across
  all data sets in the PDS
• Data Set View - ability to browse and access data
  within the context of a data set (or a small
  number of data sets)
• In D01 Subscription/Notification is implemented
  as Notification
• Global Product View is difficult
• Technical problems cartographic registration,
  object model deficiencies, keywords depending on
  context
• Political problems CN prohibited from product
  level search
• In D01 No Global Product View
• In D01 Implements the Data Set View for all
  Odyssey data sets and all PDS 3 compliant
  archived data sets

46
Data Set View - Description

• A data set search provides a web-based interface
  for finding data sets based on data set-related
  parameters, such as MISSION, TARGET, etc.
• The data set search returns a list of data sets
  (see drawing).
• For each data set in the list, the user has the
  following options
• Get information about the data set
• Use a Data Set Browser to find and retrieve
  data and ancillary files
• Use other resources (e.g., Map-a-Planet) to view
  the data set
• A product server retrieves the data for the user.

47
Data Set View Proof of Concept Screen 1

• DRAFT

48
Data Set View Proof of Concept Screen 2
49
Data Set View Proof of Concept Screen 3
50
Data Set Browser (Custom) Screen 1
51
Data Set Browser

• A web-based user interface that enables the user
  to find and retrieve data products and ancillary
  files from a single data set (or a small number
  of data sets)
• Vary in design, as they are designed for specific
  data sets.
• A very small data set with only a handful of data
  products may be a simple HTML framework that
  directly accesses data directly through a product
  server
• A very large data set with thousands of data
  products may offer a sophisticated, multi-tiered,
  data set search capability, as shown below
• In D01, there will be a default data set browser
  automatically generated for every PDS 3-compliant
  data set in the archive
• The discipline nodes that are the curators of a
  data set have control over the interface to that
  data set. And therefore, they may substitute a
  custom data set browser for the default data set
  browser.

52
Scalability

• To add NEW data repository to PDS-D
• Enable data product search and retrieval
• Develop catalog
• Install product server and profile server
• Generate default or develop custom data set
  browser
• Enable Data Set Search
• Add profiles (Data set, Data Set Browser,
  Ancillary Resources)
• Data space remains partitioned as needed by
  discipline, expertise, geography, facilities, etc
• System components remain distributed as needed by
  discipline, expertise, geography, facilities,
  performance, etc

53
Scalability (cont)

• Number of system component interconnections
  increases linearly
• One systematic connection required from each
  component to middleware
• Exponential number of inter-operational
  connections made dynamically via message passing
• Since distribution system is built as a light
  layer on top of the archive system, it will scale
  as long as the archive system scales

54
Simple Correlative Searches

• Background (the mysterious stuff)
• Resources
• Can be data products, data set browsers, product
  servers, and profile servers
• Profiles
• Profiles describe data products using information
  from label keywords
• Profiles for data sets are the union of the data
  product profiles
• Profiles for resources associated with data sets
  are equivalent to the data set profiles (e.g.
  product server)
• Profiles contain sufficient information to
  determine whether the resource can resolve an
  incoming query
• Provide sufficient information for on-the-fly
  user interfaces
• Profile servers
• Allow search and retrieval of profiles
• Profiles for profile servers are equivalent to
  the profiles of associated data sets and product
  servers

55
Simple Correlative Searches (cont)

• Example Scenario
• Query enters into system
• Query is used to identify all profile servers
  that can resolve the query
• Query is broadcasted to the identified profile
  servers
• Resulting data product profiles are collected
  into solution set
• Product ids, links to data product profiles, and
  links to product servers serving the products are
  available for display in user interface
• Assumptions
• A set of profile servers profile all data
  products of interest
• A top level profile server contains profiles for
  all such profile servers
• ? Submit a query that describes what you want and
  system will respond with descriptions of all
  matching resources

56
Conclusion
57
Status

• First release scheduled for July 22
• Operational release at end of September
• After two months of implementation
• Not all data products are designed
• Few data products are available
• PDS system resource upgrades on track for
  archive, search, and retrieval
• Middleware installation on track

58
Lessons Learned

• Technology is not the problem
• Integration of the OODT middleware into the PDS
  will have little impact on existing PDS
  subsystems
• The PDS can evolve its technology base
• The data model is the real problem

59
Lessons Learned

• The Importance of a Formal Model
• Defines context for user
• Defines context for search
• Maintains consistency
• Supports validation
• The Model Fitting Problem
• Meta-data collection involves work
• Meta-data must be modified to fit model
• Model must evolve
• The Importance of Meta-Data Validation
• Critical for consistency
• Ensures usefulness of data
• Builds user confidence

60
Backup
61
Governing Standards

• PDS Standards Reference
• Planetary Science Data Dictionary
• W3C Extensible Markup Language (XML) 1.0 (Second
  Edition) (Recommendation 6 October 2000)
• W3C HTML 4.01 Specification (Recommendation 24
  December 1999)
• W3C XHTMLT 1.0 The Extensible HyperText Markup
  Language (Recommendation 26 January 2000)
• ISO/IEC 11179 - Specification and
  Standardization of Data Elements, Parts 1-6,
  ISO/IEC specification, http//www.iso.ch/iso.
• Dublin Core Metadata Initiative. The Dublin Core
  Element Set Version 1.1, Dublin DMCI, July 1999.

62
References

• OODT Papers (http//oodt.jpl.nasa.gov/doc/papers)
• Science Search and Retrieval using XML by OODT
  Team. Presented at Second National Conference on
  Scientific and Technical Data, National Academy
  of Sciences, Washington D.C. March 2000.
• A Distributed Component Framework for Science
  Data Product Interoperability by OODT Team. 17th
  Annual International CODATA conference. Baveno,
  Italy. October 2000.
• A Component Framework Supporting Peer Services
  for Space Data Management by OODT Team, IEEE
  Space Data SystemsBig Sky Montana, March 2002.
• OODT Presentations (http//oodt.jpl.nasa.gov/doc/p
  resentations)
• JPL Enterprise Data Architecture White Paper
  (e-mail Dan.Crichton_at_jpl.nasa.gov)
• Hughes, J.S., et al. A Multi-Discipline
  Metadata Registry for Science Interoperability,
  Santa Fe Open Forum on Metadata Registries,
  ISO/IEC JTC1/SC32, Data Management and
  Interchange, 2000.
• Federal CIO Statement on Metadata -
  http//www.cio.gov/docs/metadata.htm

63
XML Profile ExampleMDIM Data Set
ltprofilegt ltprofAttributesgt
ltprofIdgt1.3.6.1.4.1.1306.2.102lt/profIdgt
ltprofTypegtprofilelt/profTypegt
lt/profAttributesgt ltresAttributesgt
ltIdentifiergtVO1/VO2-M-VIS-5-DIM-V1.0lt/Identifiergt
ltTitlegtVO1/VO2_MARS_VISUAL_IMAGING_SUBSY
STEM_DIGITAL ltFormatgttext/htmllt/Formatgt
ltresContextgtNASA.PDSlt/resContextgt
ltresClassgtdata.dataSetlt/resClassgt
ltresLocationgthttp//pdsproto.jpl.nasa.gov/catalog/
dataset/Resultsds.CFM? lt/resAttributesgt
64
XML Profile ExampleMDIM Data Set (cont)
ltprofElementgt ltelemNamegtMISSION_NAMElt/elem
Namegt ltelemTypegtENUMERATIONlt/elemTypegt
ltelemValuegtVIKINGlt/elemValuegt
lt/profElementgt ltprofElementgt
ltelemNamegtTARGET_NAMElt/elemNamegt
ltelemTypegtENUMERATIONlt/elemTypegt
ltelemValuegtMARSlt/elemValuegt lt/profElementgt
ltprofElementgt ltelemNamegtMAXIMUM_LATITUDElt/el
emNamegt ltelemTypegtREALlt/elemTypegt
ltelemMinValuegt-87.50000lt/elemMinValuegt
ltelemMaxValuegt90.00000lt/elemMaxValuegt
lt/profElementgt
65
XML Profile ExampleProduct Server for MDIM Data
Set
ltprofilegt ltprofAttributesgt
ltprofIdgt1.3.6.1.4.1.1306.2.54lt/profIdgt
ltprofDataDictIdgt1.3.6.1.4.1.1306.2.10lt/profDataDic
tIdgt lt/profAttributesgt ltresAttributesgt
ltIdentifiergtPDS Product Serverlt/Identifiergt
ltTitlegtPDS Product Server
ltFormatgtimage/pdslt/Formatgt
ltLanguagegtenlt/Languagegt
ltresContextgtPDSlt/resContextgt
ltresAggregationgtdata.granulelt/resAggregationgt
ltresClassgtsystem.productServerlt/resClassgt
ltresLocationgtiiop//JPL.PDS.Product_Server.MDI
Mlt/resLocationgt lt/resAttributesgt
66
XML Profile ExampleProduct Server for MDIM Data
Set (cont)
ltprofElementgt ltelemNamegtMISSION_NAMElt/elem
Namegt ltelemTypegtENUMERATIONlt/elemTypegt
ltelemValuegtVIKINGlt/elemValuegt
lt/profElementgt ltprofElementgt
ltelemNamegtTARGET_NAMElt/elemNamegt
ltelemTypegtENUMERATIONlt/elemTypegt
ltelemValuegtMARSlt/elemValuegt lt/profElementgt
ltprofElementgt ltelemNamegtMAXIMUM_LATITUDElt/el
emNamegt ltelemTypegtREALlt/elemTypegt
ltelemMinValuegt-87.50000lt/elemMinValuegt
ltelemMaxValuegt90.00000lt/elemMaxValuegt
lt/profElementgt
Note Profile Elements for product server are the
same as for the data set.