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
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
The Data Model
Level Group/Element Structure_________________________________________
1 spacecraft instrument identification group 2 instrument identification 2 instrument name 2 spacecraft identification 2 instrument type1 instrument description
...1 filter group 2 filter name 2 filter number 2 filter type
...
TargetData Set describehas
produce
InstrumentSpacecraft
Reference
instinfo
instid instname ...insttype scid
OBJECT = INSTRUMENT INSTRUMENT_ID = VISA SCID = VO1 INSTRUMENT_NAME = VISUAL_IMAGING... INSTRUMENT_TYPE = VIDICON_CAMERA ...END_OBJECT
An Image Label
DATA_SET_ID = "VO1/VO2-M-VIS-5-DIM-V1.0"SPACECRAFT_NAME = {VIKING_ORBITER_1, ...TARGET_NAME = MARSIMAGE_ID = MG88S045^IMAGE = 2SOURCE_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 = 2#11111111# CHECKSUM = 2636242END_OBJECT
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
•Interpretation•MAP_PROJECTION_TYPE =SINUSOIDAL•MAP_RESOLUTION =64<PIXEL/DEG>
Iowa
Stanford
ATMOSPHERESGISS
ARC
GSFCCENTRAL NODE
JPL
New MexicoState
University
RINGS
AmesResearch
Center
NAIF JPL
PLANETARYPLASMA INTERACTIONS
UCLA
Consortium
of PDS Nodes
GEOSCIENCES
Stanford
MIT
WashingtonUniversity
Brown/Hawaii
GermanyAustria
Wash U
SMALL BODIES
University of Maryland
UofAZ
UofHI
Budapest
PSI
IMAGING
JPL
USGS –Flagstaff, AZ
UCLA
Stanford
Stanford
UV (tbd)
Johns Hopkins
Stanford
The Organization
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 (>100 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
CD/DVD Distribution Costs
0
200
400
600
800
1000
1200
1400
1600
1800
Fiscal 1998 Fiscal 1999 Fiscal 2000 THEMIS only
Distribution
Do
llars
K
Mars Data Only
Non-Mars Data
14
Mars Exploration Program: Very Large Data Volumes
Growth in Size of PDS Archive
5 10
300
0
50
100
150
200
250
300
350
2001 (Current) 2003 (Mars Odyssey) 2007(MRO)
Year
Terabytes
Archive
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
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
VolumeServer
ProductServers
QueryManager
Single Point of Entry Interface(Data Set View)
Default Data SetBrowsers
In:QueryOut::Data Products
In:QueryOut::Profiles
In:QueryOut::Data Products Data Products
Virtual Volume
OODTMiddleware Virtual Volume
Physical Volume DVDVolume
In:QueryOut::Profiles
PDS-D (Distribution) D01
Custom Data SetBrowsers
In:QueryOut::Data Products
ProfileServers
MARIE,PDS PPI
Data Productsand Metadata
Documents andAncillary FilesPDS CN
GRSPDS GEO
THEMISASU
Radio SciencePDS GEO
SPICEPDS NAIFACCEL
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
DistributedProductServers
HTTP, IIOP, Java, C++
APIs
THEMISData Set
Data Source InterfaceFor
Dynamically Loaded Query Handlers
Java Server Framework
File system access
GRSData Set
Java Server Framework
Database access
XMLQUERY
Data Source InterfaceFor
Dynamically Loaded Query Handlers
HTTP, IIOP, Java, C++
APIs
XMLQUERY
DistributedDataRepositories
Product Server Architecture
26
DistributedProductServers
HTMLUser Interface
PDS JAVAUser Interface
PDS C++User Interface
GRSData Set
GRSProduct ServerGeoscience
THEMISData Set
THEMISProduct ServerASU
Middleware
IDLUser Interface
ISYSUser Interface
ENVIUser Interface
RSData Set
RSProduct ServerGeoscience
DistributedClients
Product Server Interfaces
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
THEMISData Set
Product ServerPDS.ASU.PRODSERV.ODY_M_THEMIS
Data Source InterfaceFor
Dynamically Loaded Query Handlers
Java Server Framework
File system access
http://starbrite.jpl.nasa.gov/servlet/jpl.oodt.servlets.Product_Servlet?
keywordQuery={FILE_SPECIFICATION_NAME=/ody_2001/xxx/H0133.DAT
&object= PDS.ASU.PRODSERV.ODY_M_THEMIS
&mimeType=octet & mimeType=*/*}
Client
IIOP://PDS.ASU.PRODSERV.ODY_M_THEMIS Message = XMLQuery [{FILE_SPECIFICATION_NAME=/ody_2001/xxx/H0133.DAT}]
WebServerhttp://starbrite.jpl.nasa.gov/servlet/jpl.oodt.servlets.Product_Servlet
ResultXMLQuery [{FILE_SPECIFICATION_NAME=/…},MIME(BASE64(ZIP(H0133.DAT))]
29
XML Query Example (1 of 2)
<query> <queryAttributes> <queryId>1.2.3.4…</queryId> <queryTitle>Query Example</queryTitle> <queryDesc>Query for INSTRUMENT_ID = HEND</queryDesc> <queryType>QUERY</queryType> <queryStatusId>ACTIVE</queryStatusId> <querySecurityType>UNKNOWN</querySecurityType> <queryRevisionNote>2000-05-12 JSH V1.2 Updated for new prof.dtd</queryRevisionNote> <queryDataDictId>1.2.3.5…</queryDataDictId> </queryAttributes> <queryResultModeId>ATTRIBUTE</queryResultModeId> <queryPropogationType>BROADCAST</queryPropogationType> <queryPropogationLevels>N/A</queryPropogationLevels> <queryMaxResults>100</queryMaxResults><queryResults>0</queryResults> <queryKWQString>INSTRUMENT_ID = HEND</queryKWQString>
30
XML Query Example (2 of 2)
<querySelectSet></querySelectSet> <queryFromSet></queryFromSet> <queryWhereSet> <queryElement> <tokenRole>elemName</tokenRole> <tokenValue>INSTRUMENT_ID</tokenValue> </queryElement> <queryElement> <tokenRole>LITERAL</tokenRole> <tokenValue>HEND</tokenValue> </queryElement> <queryElement> <tokenRole>RELOP</tokenRole> <tokenValue>EQ</tokenValue> </queryElement> </queryWhereSet> <queryResultSet>….</queryResultSet></query>
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
<!ELEMENT profiles (profile*)>
<!ELEMENT profile (profAttributes, resAttributes, profElement*)>
<!ELEMENT profAttributes (profId, profVersion?, profType, profStatusId, profSecurityType?, profParentId?, profChildId*, profRegAuthority?, profRevisionNote*, profDataDictId?)>
<!ELEMENT resAttributes (Identifier, Title?, Format*, Description?, Creator*, Subject*, Publisher*, Contributor*, Date*, Type*, Source*, Language*, Relation*, Coverage*, Rights*, resContext+, resAggregation?, resClass, resLocation*)>
<!ELEMENT profElement (elemId?, elemName, elemDesc?, elemType?, elemUnit?, elemEnumFlag, (elemValue* | (elemMinValue, elemMaxValue)), elemSynonym*, elemObligation?, elemMaxOccurrence?, elemComment?)>
34
Data Product Profile (ODYSSEY HEND)-<profile> -<profAttributes> <profId>1.3.6.1.4.1.1306.2.104.10018791</profId> <profVersion>null</profVersion> <profType>profile</profType> </profAttributes> -<resAttributes> <Identifier>ODY-M-HEND-EDR-2-V1.0+H0133</Identifier> <Title>Data_Set_Name: ODYSSEY-MARS-HEND-EDR-2-V1.0 +
Product_Id:H0133</Title> <Description>null</Description> <resContext>NASA.PDS</resContext> <resAggregation>null</resAggregation> <resClass>data.granule</resClass> <resLocation>iiop://PDS.ProfServer.GEO.ODY.GRS</resLocation> </resAttributes> -<profElement> <elemName>FILE_SPECIFICATION_NAME</elemName> <elemValue>/ody_2001/xxx/H0133.DAT</elemValue> </profElement> -<profElement> <elemName>INSTRUMENT_ID</elemName> <elemValue>HEND</elemValue> </profElement>
…
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
Query Server
Node 1Profile Server
Node 2Profile Server
Node 2Product Server
XMLQuery
XMLQuery
XMLQuery
XM
LQ
ue
ry
XM
LQ
ue
ry
Node 1 Catalog
Que
ryC
lien
tWeb
se
rver
Plu
gin
s
Web
Ser
ver
Node 1Product Server
XMLQuery
Node 1 Products
Node 2 Catalog
Node 2 Products
Web I/F
Desktop I/F
XMLQuery
XMLQuery
XMLQuery
XMLQuery
Name Server
CentralNode
ClientEnvironment 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
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
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/presentations)
• JPL Enterprise Data Architecture White Paper (e-mail: [email protected])
• 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
<profile> <profAttributes> <profId>1.3.6.1.4.1.1306.2.102</profId> <profType>profile</profType> </profAttributes> <resAttributes> <Identifier>VO1/VO2-M-VIS-5-DIM-V1.0</Identifier> <Title>VO1/VO2_MARS_VISUAL_IMAGING_SUBSYSTEM_DIGITAL… <Format>text/html</Format> <resContext>NASA.PDS</resContext> <resClass>data.dataSet</resClass> <resLocation>http://pdsproto.jpl.nasa.gov/catalog/dataset/Resultsds.CFM?… </resAttributes>
64
XML Profile ExampleMDIM Data Set (cont)
<profElement> <elemName>MISSION_NAME</elemName> <elemType>ENUMERATION</elemType> <elemValue>VIKING</elemValue> </profElement><profElement> <elemName>TARGET_NAME</elemName> <elemType>ENUMERATION</elemType> <elemValue>MARS</elemValue></profElement> <profElement> <elemName>MAXIMUM_LATITUDE</elemName> <elemType>REAL</elemType> <elemMinValue>-87.50000</elemMinValue> <elemMaxValue>90.00000</elemMaxValue> </profElement>
65
XML Profile ExampleProduct Server for MDIM Data Set
<profile> <profAttributes> <profId>1.3.6.1.4.1.1306.2.54</profId> <profDataDictId>1.3.6.1.4.1.1306.2.10</profDataDictId> </profAttributes> <resAttributes> <Identifier>PDS Product Server</Identifier> <Title>PDS Product Server <Format>image/pds</Format> <Language>en</Language> <resContext>PDS</resContext> <resAggregation>data.granule</resAggregation> <resClass>system.productServer</resClass> <resLocation>iiop://JPL.PDS.Product_Server.MDIM</resLocation> </resAttributes>
66
XML Profile ExampleProduct Server for MDIM Data Set (cont)
<profElement> <elemName>MISSION_NAME</elemName> <elemType>ENUMERATION</elemType> <elemValue>VIKING</elemValue> </profElement><profElement> <elemName>TARGET_NAME</elemName> <elemType>ENUMERATION</elemType> <elemValue>MARS</elemValue></profElement> <profElement> <elemName>MAXIMUM_LATITUDE</elemName> <elemType>REAL</elemType> <elemMinValue>-87.50000</elemMinValue> <elemMaxValue>90.00000</elemMaxValue> </profElement>
Note: Profile Elements for product server are the same as for the data set.