CWIC Initial Design
Phase 1 Development
The first stage of CWIC development will implement three major components – 1) a public CSW server interface, 2) a customized back-end for searching the IDN and the various partner systems (currently, NOAA CLASS, NASA ECHO and USGS LANDSAT), and 3) an internal, customizable mapping between the supported CSW queryable and returnable properties and specific elements particular to the partner systems.
The function of CWIC shall be to expose a single, standards-based, http service to the user community for searching the various partner systems and for obtaining results which lead directly to either data granules or, at minimum, to specific identification information which can be linked to ordering systems so that the data granules may be obtained directly.
No user registration functions will be available or necessary in this initial phase and, as a result, only links to freely-available, downloadable data will be provided in the search results returned to the end users.
The CSW v2.0.2 Public Interface
The CWIC server component – that part visible to user clients – will be a conventional http-based query service supporting the CSW v2.0.2 catalog search protocol and the WGISS Inventory Search Criteria (Annex 1).  It will recognize the basic core queryable elements of CSW v2.0.2 and those parts of the ISO Metadata Application Profile that are applicable to the satellite data community. 
In general, the interface will support spatial, temporal and parameter searches.  Several of the core queryable elements specified for CSW v2.0.2 are not particularly relevant to satellite data and will be ignored by the server, but will not generate errors or exceptions.  
In general, search responses will include links to browse graphics.
The CSW protocol mandates support for three returnable sets of results – brief, summary and full – in addition to a simple response indicating only the number of hits to be returned by a search.  These provide a measure of “traffic control” for the search process, allowing the requesting client to explore the results in ways which have less impact on the server than simply retrieving all of the results in bulk.  Specifics for the brief and summary element set requirements are contained in the OGC CSW v2.0.2 specification document (OGC 07-006r1).
CWIC will support these, but the variety of inventory products available through the partner systems preclude a single, well-defined full record description.  Rather than attempting to define one or more XML formats for the inventory data, we will follow the full record implementation of Geospatial OneStop and return a simple full record, based on Dublin Core, and including a link to the data granule or ordering system as returned by the partner system.  This supports the focus of CWIC on online data and is workable because each partner provides an http-based mechanism for retrieving specific data granules.
The CWIC Catalog Federation Service
Background
For scientists who conduct multi-disciplinary research, there may be a need to search multiple catalogs in order to find the data they need.  Such work is very time-consuming and tedious, especially when the catalogs may use different metadata models and catalog interface protocols.  It would be desirable, therefore, for those catalogs to be integrated into a catalog federation, which will present a well-known and documented metadata model and interface protocol to users and hide the complexity and diversity of the affiliated catalogs behind the interface.  With such a federation, users only need to work with the federated catalog through the public interface or API to find the data they need instead of working with various catalogs individually. 
The CWIC Mediator-wrapper Architecture
A mediator-wrapper architecture has been protoyped at the Center for Spatial Information Science and Systems (CSISS) at George Mason University (GMU) by constructing three distinct geospatial catalog services: the NASA Earth Observing System (EOS) Clearinghouse (ECHO), the George Mason University (GMU) OpenGIS Catalogue Service for Web (CSW), and the U.S. Department of Energy (DOE) Earth System Grid (ESG) Simulation Data Catalogue.  This architecture has been proved to be effective in providing a Catalog Federation solution.
Wrappers offer query interfaces hiding the particular data model, access path, and interface technology of the partner catalog systems.  Wrappers are accessed by a mediator, which offers users an front-end integrated access through its global schema.  The user poses queries against the global schema of the mediator; the mediator then distributes the query to the individual systems using the appropriate wrappers.  The wrappers transform the queries so they are understandable and executable by the partner catalog systems they wrap, collect the results, and return them to the mediator.  Finally, the mediator integrates the results as a user response.
This mediator-wrapper architecture has been utilized in designing CWIC.  In particular, OGC CSW interface (core profile and ISO profile) is exposed to CWIC clients on the front-end, and it is also used in the connection between internal mediator and wrappers.  Three wrappers are needed for NASA ECHO, NOAA CLASS, and USGS Landsat Catalog System, as none of them currently support the OGC CSW interface.
Extending CWIC to additional Partner Catalogs
There is no restrictions for connecting CWIC to more partner catalogs.  However, to enable a simple plug & play interface, partner catalogs would need to support the OGC CSW interface (core profile and ISO profile).  Otherwise, dedicated wrappers need to be developed to enable the partner catalogs being accessed by CWIC, as is being done for each of the current partner catalog systems.
Reference
Bai Y., L. Di, A. Chen, Y. Liu, and Y. Wei, 2007. Towards a Geospatial Catalogue Federation Service, Photogrammetric Engineering & Remote Sensing. Vol. 73, No. 6, June 2007, pp. 699-708
The CWIC Partner Interfaces
There will be initially four participating partners – the CEOS IDN for discovery services, and the online data systems from NOAA (CLASS), NASA (ECHO) and USGS (LANDSAT) for inventory searches and data retrieval.
The CWIC NOAA CLASS Interface
Development is underway for an OGC CSW Wrapper for NOAA CLASS system.  See Annex 6 for details of the NOAA CLASS holdings and availability.
The CWIC NASA ECHO Interface
OGC CSW Wrapper for NASA ECHO system has been developed at GMU. This package can be re-used for CWIC with necessary modifications.  See Annex 7 for details of the NASA ECHO holdings and availability.
The wrapper for NASA ECHO will ensure that no results from LANDSAT will be returned in query responses.  This will help ensure that CWIC does not return duplicate records from multiple sources.
The CWIC USGS LANDSAT Interface
The USGS has a RESTful service online to support spatial bounding box queries, with additional parameters for specifying path/row, temporal ranges and cloud cover parameters.  See Annex 8 for details of the USGS LANDSAT holdings and availability.
To be determined from the USGS development staff are responses to the following, which have bearing on the CWIC partner interface:
1)	whether the USGS service allows returning all the matched records in one response. Are there any limitations on the maximum number of records that may be returned in a single response?
2)	whether query spatial footprints that cross 180 degree longitude are supported?
If not, what is the acceptable way for CWIC to express the relevant footprint?
3)	whether query spatial footprints that are bigger than half of the earth are supported?
If not, what is the acceptable way for CWIC to re-generate the relevant footprint?
CWIC will create a unique identifier for user in CSW search responses from the LANDSAT scene ID and sensor name.  This will provide a direct link between individual records in the CSW response and individual LANDSAT records.
The CWIC CEOS IDN Interface
See Annex 9 for details of the CEOS IDN holdings and availability.
Details of the CEOS IDN interface - TBD
The CWIC Internal Data Mappings
CWIC will provide an interpretation (mapping) from each supported CSW queryable parameter and related parameters to each of the partner systems.  The function of CWIC will be to use this mapping to send faithful translations of the end-user query to each of the designated back-end systems using their native, supported protocols.  The responses will then be faithfully translated back to a proper CSW request response which is either compliant with ISO profile, or as core returnables, or sent back to the end user.
The specific details of the parameter mappings for each partner system will be documented in Annexes 2, 3, 4 and 5.

Annex 1 – WGISS Search Criteria based on ISO 19115/19139
This table lists the WGISS Inventory Search Criteria (see http://www.ceos.org/images/WGISS/CWIC/10.03_search-v0.1.ppt) as mapped to attributes of the ISO 19115/19139 specifications. 

�	MD_Metadata > MD_DataIdentification.extent > EX_Extent > EX_GeographicExtent > EX_GeographicBoundingBox or EX_GeographicDescription  (CIP)
�	MD_Metadata > MD_DataIdentification.extent > EX_Extent > EX_GeographicExtent > EX_GeographicBoundingBox or EX_GeographicDescription   (CIP)
�	MD_Metadata > MD_DataIdentification.extent > EX_Extent > EX_GeographicExtent > EX_GeographicBoundingBox or EX_GeographicDescription  (CIP)
�	MD_Metadata > MD_DataIdentification.extent > EX_Extent > EX_GeographicExtent > EX_GeographicBoundingBox or EX_GeographicDescription   (CIP)
�	MD_Metadata > MD_DataIdentification.extent > EX_Extent> EX_TemporalExtent or EX_VerticalExtent   (CIP)
�	MD_Metadata > MD_DataIdentification.extent > EX_Extent> EX_TemporalExtent or EX_VerticalExtent  (CIP)
�	MD_Metadata.fileIdentifier  (CIP)
�	MD_MetaData->CI_ResponsibleParty->organizationName (role=resourceProvider)  (CIP-o)
�	MD_MetaData->CI_ResponsibleParty->organizationName (role=originator)  (CIP-o)
�	MD_MetaData-> MI_DataIdentification->MI_MissionIdentification->name   (CIP-o)
�	MD_MetaData-> MI_DataIdentification->MI_InstrumentIdentification->shortName   (CIP-o)
�	MD_MetaData->MD_ContentInformation->MD_CoverageDescription->MD_ImageDescription->processingLevelCode(CIP-o)
�	MD_Metadata > MD_DataIdentification.abstract  (ISO)MD_Metadata > MD_DataIdentification.topicCategory   (ISO)
�	MD_Format.version  (OGC)
�	MD_Metadata > MD_DataIdentification.citation > CI_Citation.title (ISO)
�	MD_Metadata > MD_DataIdentification.citation > CI_Citation.date (ISO)
�	MD_Metadata.contact > CI_ResponsibleParty.role (ISO)
�	MD_Metadata.dateStamp (ISO)
�	MD_Metadata > MD_Distribution > MD_DigitalTransferOption.onLine > CI_OnlineResource (ISO)
�	MD_Metadata.metadataStandardName (ISO)
�	MD_Metadata.metadataStandardVersion (ISO)
�	MD_Metadata > MD_DataIdentification.spatialRepresentationType (ISO)

The following table lists the complete mapping from Liping Di of the ISO 19115 mappings for the WGISS Search Criteria, along with definitions and annotative text:

CWIC ISO 19115 Search Criteria	Definition	Obligation/ Condition/condition	Note	
MD_Metadata > MD_DataIdentification.extent > EX_Extent > EX_GeographicExtent > EX_GeographicBoundingBox 	Geographic geographic position of the dataset. It has four class member which defines the east bound longitude, west bounding longitude, north bounding latitude, and south bounding latitude.   	C/No (Ex_GeographicDescription or EX_BoundingPolygon)?	One of them shall be presented. Also assuming the extent type is "inclusion".  DLR currently supports bounding polygon search but many other data systems do not. So should we add the bounding polygon or not?	
MD_Metadata > MD_DataIdentification.extent > EX_Extent > EX_GeographicExtent > EX_GeographicDescription   	EX_GeographicDescription provides description of the geographic area using identifiers (geographic name, the description, and authority who defines and maintain the name) (Remove. Portal will translate the name to bouding polygon or box)	C/No ( Ex_GeographicBoundingBox or EX_BoundingPolygon)?		
MD_Metadata > MD_DataIdentification.extent > EX_Extent > EX_GeographicExtent > EX_BoundingPolygon  	boundary enclosing an area of interes, expressed as the closed set of (x,y) coordinates of the polygon (last point replicates first point).  (CWIC will translate to Bbox if not supported by CWIC partner)	C/No (Ex_GeographicBoundingBox or EX_GeographicDescription)?		
MD_Metadata > MD_DataIdentification.extent > EX_Extent> EX_TemporalExtent	EX_TemporalExtent defines time period covered by the content of the dataset (a time instance, multiple time steps, or a time period).	O		
MD_Metadata > MD_DataIdentification.extent > EX_Extent> EX_VerticalExtent  	EX_VerticalExtent defines vertical domain of dataset. It includes lowest and highest vertical extent contained in the dataset, the unit, and the datum.	O		
MD_Metadata.dataSetURI	 Uniformed Resource Identifier (URI) of the dataset to which the metadata applies ("dataset" means granule in ISO;  This maps to granule ID)	O	Need rules for creating unique URI in the CEOS community. This element is only useful if the user wants to search a data by using a URI,  or CWIC server is capable to search data by using URI patterns.	
MD_Metadata>MD_DataIdentification.pointOfContact>CI_ResponsibleParty.organizationName (role=resourceProvider)	Organization who provide the data resource (data distributor)	O		
MD_Metadata>MD_DataIdentification.pointOfContact->CI_ResponsibleParty.organizationName (role=originator) 	originator who produces the data resource (data producer)	O		
MD_Metadata>MD_DataIdentification.pointOfContact > CI_ResponsibleParty.role 	see line 16 and 17.	O	This element is used in combination with line 15 and 16 to specify the role of responsible party. For example, a user wants to find data produced by NASA, the responsible party will be NASA, and the role will be producer.	
MI_Metadata>MI_AcquisitionInformation>MI_Platform.identifier>MD_Identifier.code  	The platform name	O		
MI_Metadata>MI_AcquisitionInformation>MI_Instrument.identifier>MD_Identifier.code	The short name of the instrument. Note: if we would like to use ISO 19115-2, everything should start MI_Metadata	O		
MD_Metadata>MD_ImageDescription.processingLevelCode>MD_Identifier.code 	The processing level of the product.	O		
MD_Metadata > MD_DataIdentification.topicCategory   	main theme(s) of the dataset  (remove  for granule search, more appropriate for directory search)	O		
MD_Metadata>MD_Distribution>MD_Format	The distribution format.   (remove )	O	For specific client of CWIC, such as a processing service which only can take a specific format, this search criteria is needed. In this case,  not only the format version, but also format name and other information should be specified. So MD_Format class is needed instead of only version	
MD_Metadata > MD_DataIdentification.citation > CI_Citation.title 	name by which the cited dataset is known (remove )	O		
MD_Metadata > MD_DataIdentification.citation > CI_Citation.date 	reference date for the cited dataset (acquisition date)	O		
MD_Metadata > MD_Distribution > MD_DigitalTransferOption.onLine > CI_OnlineResource.protocol 	connection protocol to be used (remove)	O	A CWIC users may be only interested in the datasets that are online downloadable using a specific protocol. The three metadata elements will provide the user the capability for such kind of search	
MD_Metadata > MD_Distribution > MD_DigitalTransferOption.onLine > CI_OnlineResource.applicationProfile 	name of an application profile that (remove) Can be used with the online resource	O		
MD_Metadata > MD_Distribution > MD_DigitalTransferOption.onLine > CI_OnlineResource.function	code for function performed by the online resource (remove)	O		
MD_Metadata.metadataStandardName 	name of the metadata standard (including profile name) used  (only from portal to CWIC; not passed to partners)	O	This information sent to the CWIC server from a CWIC client will tell the server the specific metadata standard used to encode the search request. The default is ISO 19115:2003. It is possible that in the future the CWIC server will support multiple versions of ISO 19115 (e.g., ISO 19115-2, NAP) 	
MD_Metadata.metadataStandardVersion 	version (profile) of the metadata standard used (only from portal to CWIC; not passed to partners)	C/MD_Metadata.metadataStandardName?	see line above	
MD_Metadata > MD_DataIdentification.spatialRepresentationType 	method used to spatially represent geographic information, e.g., vector, grid (remove, to be considered in phase II)	O		
MD_Metadata>MD_DataIdentification>MD_Keywords	Descriptive keywords for the datasets (USE GCMD keywords)	O	This is to facilitate the parameter search.  Using GCMD keywords?	
				
MD_Metadata>MD_DataIdentification>MD_Keywords	The topic of the content of the resource (Subject)	O (CSW Common Queryable Element) - same as row 24		
MD_Metadata.identificationInfo.AbstractMD_Identification.citation.CI_Citation.title 	A name given to the resource (Title)	M (CSW Common Queryable Element) -- same as row 17 and use the path reflected in row 17		
MD_Metadata.identificationInfo.AbstractMD_Identification.abstract 	A summary of the content of the resource (Abstract)	O? (CSW Common Queryable Element)		
MD_Metadata	A target for full-text search of character data types in a Catalogue (AnyText)	M (CSW Common Queryable Element)	All inquiries will be encoded in ISO starting with MD_Metadata (In the CWIC case, since 19115-2 is used, MI_Metadata should be used) as the top class. Inquiries with MD_Metadata but without contents means to return any catalog contents.	
MD_Metadata.distributionInfo.MD_Distribution.distributionFormat.MD_Format.name 	The physical or digital manifestation of the resource (Format)	M (CSW Common Queryable Element) - removed from CWIC partners - dummy return		
MD_Metadata.fileIdentifier	An unique reference to the record within the catalogue (Identifier)	M (CSW Common Queryable Element) - removed from CWIC partners - dummy return; will use URI instead		
MD_Metadata.dateStamp.Date	Date on which the record was created or updated within the Catalogue (Modified)	M (CSW Common Queryable Element) -removed from CWIC partners - no one interested when metadata created? For updated metadata?		
MD_Metadata.hierarchyLevel.MD_ScopeCode/@codeListValue. If MD_Metadata.hierarchyLevel is missing, ‘Type’ will be considered as “Dataset” (default).	The nature or genre of the content of the resource. Type can include general categories, genres or aggregation levels of Content (Type)	M (CSW Common Queryable Element) - indicate directory or inventory search		
Compound element (Authority+ID+Version)	Geographic Coordinate Reference System (Authority and ID) for the BoundingBox (CRS)	M? (CSW Common Queryable Element) - correct the path;  will be filled in by portal to interpret the bbox coordinates;  will need to limit to a predefined set	Maybe use the RS that are supported by EOSDIS.	
				
MD_Metadata.identificationInfo.AbstractMD_Identification.citation.CI_Citation.date.CI_Date[dateType.CI_DateTypeCode.@codeListValue='revision'].date.Date	Revision date of the Resource (RevisionDate)	O (CSW ISO Queryable Element) ; already have	See Line 17. Set DateType Code = "revision"	
MD_Metadata.identificationInfo.AbstractMD_Identification.citation.CI_Citation.alternateTitle	Alternate title of the Resource (AlternateTitle)	O (CSW ISO Queryable Element); doesn't apply at granule level;  may apply at directory level		
MD_Metadata.identificationInfo.AbstractMD_Identification.citation.CI_Citation.date.CI_Date[dateType.CI_DateTypeCode.@codeListValue='creation'].date.Date	Creation Date of the Resource (CreationDate)	O (CSW ISO Queryable Element); already have	See Line 17. Set DataTypeCode = "creation"	
MD_Metadata.identificationInfo.AbstractMD_Identification.citation.CI_Citation.date.CI_Date[dateType.CI_DateTypeCode.@codeListValue='publication'].date.Date	Publication Date of the Resource (PublicationDate)	O (CSW ISO Queryable Element);  already have	See Line 17. Set DataTypeCode = "publication"	
MD_Metadata.identificationInfo.AbstractMD_Identification.pointOfContact.CI_ResponsibleParty.organisationName	Name of the organisation providing the resource (OrganisationName)	O (CSW ISO Queryable Element);  already have	See Line 8. The abstract class "AbstractMD_Identification" cannot be institiated, and have to use real class either MD_DataIndentification or MD_ServiceIdentification. In CWIC case, we have to use the DataIdentification.	
MD_Metadata.AbstractMD_Identification.resourceConstraints.MD_SecurityConstraints	Are there any security Constraints? (HasSecurityConstraints)	O (CSW ISO Queryable Element);  remove;  doesn't apply;  do access constraints another phase		
MD_Metadata.language	Language of the Metadata (Language)	O (CSW ISO Queryable Element); remove; only english currently supported		
MD_Metadata.identificationInfo.AbstractMD_Identification.citation.CI_Citation.identifier.MD_Identifier.code	Identifier of the resource (ResourceIdentifier)	O (CSW ISO Queryable Element);  use URI;  removed		
MD_Metadata.parentIdentifier	Fileidentifier of the metadata to which this metadata is a subset (child) (ParentIdentifier)	O (CSW ISO Queryable Element);  		
MD_Metadata.identificationInfo.Abstract.MD_Identification.descriptiveKeywords.MD_Keywords.type	Methods used to group similar keywords (KeywordType)	O (CSW ISO Queryable Element);  have already;  	See line 24. Please note that the notation for CWIC search criteria does no include the association rule in order to shorten the expression. 	
				
MD_Metadata.identificationInfo.MD_DataIdentification.topicCategory	Main theme(s) of the Dataset. (TopicCategory)	O (CSW ISO Dataset, DatasetCollection or Application Queryable Element);  already have, remove	See line 14	
MD_Metadata.identificationInfo.MD_DataIdentification.language	Language(s) used within the dataset (ResourceLanguage)	O (CSW ISO Dataset, DatasetCollection or Application Queryable Element);  already have, remove		
MD_Metadata.identificationInfo.MD_DataIdentification.extent.EX_Extent.geographicElement.EX_GeographicDescription.geographicIdentifier.MD_Identifier.code; 	Description of the geographic area using Identifiers. (GeographicDescriptionCode)	O (CSW ISO Dataset, DatasetCollection or Application Queryable Element);  already have, remove	This one was defined in the early version of CWIC search criteria. But we decide to remove it because it should be client function to interpret the identifer into geographic extent.	
	Factor which provides a general understanding of The density of spatial data in the dataset. (SpatialResolution)	O (CSW ISO Dataset, DatasetCollection or Application Queryable Element);  collection level		
	Temporal extent of the Resource (TemporalExtent)	O (CSW ISO Dataset, DatasetCollection or Application Queryable Element);  important for ECHO		

Annex 2 – CWIC – CEOS IDN connection
2.1 Queryable Parameter Mapping from ISO to IDN interface
2.2 Metadata Response Elements Mapping from IDN interface to ISO and CSW Core Returnable

Annex 3 – CWIC – NOAA CLASS connection
3.1 Queryable Parameter Mapping from ISO to NOAA CLASS interface
3.2 Metadata Response Elements Mapping from NOAA CLASS interface to ISO and CSW Core Returnable

Annex 4 – CWIC – NASA ECHO connection
4.1 Queryable Parameter Mapping from ISO to NASA ECHO interface
4.2 Metadata Response Elements Mapping from NASA ECHO to ISO and CSW Core Returnable

Annex 5 – CWIC - USGS LANDSAT System connection
5.1 Queryable Parameter Mapping from ISO to USGS LANDSAT interface
5.2 Metadata Response Elements Mapping from USGS LANDSAT System to ISO and CSW Core Returnable

Annex 6 – NOAA CLASS Partner Survey Response
1) Available data
-- Characteristics
NOAA and US Department of Defense (DoD) Polar-orbiting Operational Environmental Satellite (POES) data and derived data products.

-- Volume (data collections / dataset level, and granule level)
Around 51 data collections (products)

-- Spatial / temporal coverage
Global coverage

2) Metadata
-- Metadata information model (what is the current status, any near future upgrade working plan?)
No established metadata information model. See comments below.

-- Languages
English

-- Example files
No. See comments below.

3) Available data discovery interfaces
-- Any API interfaces for machine-to-machine call? If yes, what about the protocol?

NOAA CLASS provides a form-based GUI interface for science users. It does offer spatial, temporal, and several advanced query criteria. The response usually provides the following information for each matched search result (granule): data type, start orbit, end orbit, start time, end time, satellite, dataset name, size, resolution, processing mode. 

Please note that these available search criteria and response information depend on the targeted dataset. Some query criteria apply to one dataset, but might not apply to another.

The prototype Simple NOAA Archive Access Protocol (SNAAP) API developed by Eric Kihn and Rob Prentice at NOAA’s National Geophysical Data Center (NGDC) provides a proprietary API interface to NOAA data. This package is very promising, and is going to have a major release around August 2010. At its current form, the following limitations on the data discovery functionalities have been observed:
a) Only DMSP and AVHRR data are available for testing purposes
b) No way to define the maximum records to be returned, and the startPosition
Therefore, matched records are all returned in one step. In case too many matched records returned, this will definitely cause the “out of memory”.
c) Spatial query could be further enriched
Only a point-based spatial query is available. A bounding box –based spatial query would be very helpful to select data that just covers/partially covers the study area that are usually represented using a bounding box.

4) Available data access interfaces
-- For direct accessible data, what about the protocol?
All NOAA data are orderable through CLASS. No direct access to data is available. 

-- For non-direct accessible data, do you provide URL to the data ordering system? If yes, where users can find the URL? Is it in the metadata information?

No simple URL to the data ordering system is available. All orders have gone through the GUI-based order system or API interfaces.

5) Other related issues
-- Any restrictions on data discovery/access?
No restrictions on data discovery through NOAA CLASS. User account is necessary for data order through NOAA CLASS. User registration is free.
At its current form, SNAAP provides free data discovery and order interfaces. No user account is needed.

Annex 7 – NASA ECHO Partner Survey Response
1) Available data
-- Characteristics
ECHO (EOS ClearingHouse) is a metadata catalog of NASA’s Earth Observing System (EOS) data and a registry for related data services. ECHO’s catalog contains data sets held at 12 EOSDIS (EOS Data Information System) data centers. EOSDIS is a petabyte-scale archive of environmental data that supports global climate change research monitoring daily events and long term changes. ECHO stores metadata from a variety of science disciplines and domains, including Climate Variability and Change, Carbon Cycle and Ecosystems, Earth Surface and Interior, Atmospheric Composition, Weather, and Water and Energy Cycle. This enables a single point of discovery, understanding and some access for users, eliminating their need to have knowledge of location and type of data. 

-- Volume (data collections / dataset level, and granule level)
ECHO’s catalog contains approximately 3000 data collections and 82 million granules and 40 million browse images.

-- Spatial / temporal coverage
As a registry of thousands of types of EOSDIS data from a dozen sources, ECHO has a variety of spatial and temporal coverages – each of the thousands of data sets has its own spatial and temporal coverage.  It is not appropriate to state a single spatial and temporal coverage for this registry.

2) Metadata
-- Metadata information model (what is the current status, any near future upgrade working plan?)
The millions of data objects represented in ECHO conform to ECHO's metadata model, which was derived from the ECS metadata model with some simplifications and extensions.  The ECS data model was developed in parallel to the FGDC model.  Metadata conformant with ECS or generally with FGDC can be mapped to ECHO.  ECHO’s metadata model is also being mapped to the core elements of the ISO 19115 standards for ingesting science metadata into the ECHO system and for representing query results produced by the ECHO system. A draft version of the query mapping is available. The final mappings of both will be complete within CY2010.
The following three metadata constructs are utilized by the ECHO system: 
•	Collection - A grouping of science data that all come from the same source, such as a modeling group or institution. Collections have information that is common across all the granules they contain and a template for describing additional attributes not already part of the metadata model. 
•	Granule - The smallest aggregation of data that can be independently managed (described, inventoried, and retrieved). Granules have their own metadata model and support values associated with the additional attributes defined by the owning collection. 
•	Browse - An image which provides a high-level view of the associated granule or collection metadata item. Browse images are not spatially enabled, but are very useful during data discovery and cross-referencing to other granules or collections. 

-- Languages
English is the base language for metadata and service interfaces within ECHO.
-- Example files

ECHO provides sample metadata files at the following website: 
Sample “Collection” metadata 
http://www.echo.nasa.gov/ingest/schemas/operations/samples/echo_10_collection_insert.xml

Sample “Granule” metadata 
http://www.echo.nasa.gov/ingest/schemas/operations/samples/echo_10_granule_insert.xml

Sample “Browse” metadata 
http://www.echo.nasa.gov/ingest/schemas/operations/samples/echo_10_browse_insert_url.xml

3) Available data discovery interfaces
-- Any API interfaces for machine-to-machine call? If yes, what about the protocol?
ECHO’s capabilities can be accessed through its publicly available APIs defined in WSDL and are accessible through SOAP.
ECHO capabilities/API include:
�	User Registration and Login
�	Metadata ingest, validation, and reconciliation
�	Search for Cartesian, Geodetic and Orbital data using:
�	Data Registry access
�	Publish, discover, and access Extended Services
�	Event notification subscriptions notify users when an internal event occurs:
�	SSL communication
The services and their interfaces are defined here: 
	http://api.echo.nasa.gov/echo/ws/v10/index.html

4) Available data access interfaces
-- For direct accessible data, what about the protocol?
ECHO represents data holdings from a dozen NASA Data Centers.  As such, it reflects the mechanisms that those Data Center offer for users to access their data holdings.  Where direct accessible data is available, ECHO provides FTP or web URLs for those granules and collections.  

-- For non-direct accessible data, do you provide URL to the data ordering system? If yes, where users can find the URL? Is it in the metadata information?
ECHO provides an order brokering service, allowing users a single point of contact to order data from multiple providers.  Ordering is constrained by the ordering capabilities of the Data Center (for example, not all Data Centers support all types of physical media for data distribution). In the majority of cases users don’t need an additional URL to the data center’s ordering system. When the data is not available online, ECHO acts as an order broker between users and the data centers. In cases where the data center does not have a machine-to-machine ordering system, ECHO does provide the necessary URL. In addition, ECHO provides URLs for all online information covering aspects of the data, such as guides, product listings, validation information, etc. Yes, it is in the metadata information.

5) Other related issues
-- Any restrictions on data discovery/access?
Consistent with NASA policy, Data are openly available to all and free of charge except where governed by international agreements.  ECHO has the responsibility to reflect the any restrictions that the Data Centers declare on their resources, within their own governance and policy directives.  ECHO provides tools to those Data Centers to declare the availability and visibility of their holdings, as well as the tools to change those restrictions, as they need.  User visibility and access restrictions within ECHO are consistent with the directives from the Data Centers.  

Annex 8 – USGS LANDSAT Partner Survey Response
1) Available data
-- Characteristics
The New Earth Explorer (EE) is a user search and download client which contain the USGS/EROS Landsat data collection.  This collection consists of Landsat’s 1-5 and 7 containing the MSS, TM, and ETM+ sensors. All Landsat satellites have flown in a Sun-synchronous orbit. This allows the satellite to maintain a constant orientation between the Earth and the Sun. As a result, the mean Sun time at each point in the orbit remains fixed. For example, equatorial crossing times range from 8:30 a.m. (local time) for Landsat 1, to 9 a.m. for Landsat 2, and to approximately 10:00 a.m. for Landsat’s 5 and 7.
Landsat’s 1, 2, and 3 operated in a near-polar orbit at an altitude of 920 km. These satellites circled the Earth every 103 minutes, completing 14 orbits a day. It took 18 days and 251 overlapping orbits to provide nearly complete coverage of the Earth's surface with 185-km image swaths.
The primary sensor aboard Landsat’s 1, 2, and 3 was the multispectral scanner (MSS). The MSS sensor scanned the Earth's surface across the satellite track as the satellite moved in its descending (north-to-south) orbit over the sunlit side of the Earth. The combination of scanning geometry, satellite orbit, and Earth rotation produced the global coverage necessary for studying land surface change. The resolution of the MSS sensor was approximately 80 m, with radiometric coverage in four spectral bands from the visible green to the near-infrared (IR) wavelengths. The MSS sensor on Landsat 3 had a fifth band in the thermal-IR wavelength.
Landsat’s 4 and 5 carried both the MSS and a new, improved Thematic Mapper (TM) sensor. The MSS sensors onboard Landsat’s 4 and 5 were identical to the one that was carried on Landsat 3. The MSS and TM sensors detect reflected or emitted energy from the Earth in the visible and IR wavelengths. TM bands 1-5 and 7 collect reflected energy; band 6 collects emitted energy. The TM sensor has a spatial resolution of 120 m for the thermal-IR band and 30 m for the six reflective bands. The newest satellite in the series, Landsat 7, carries the enhanced Thematic Mapper Plus (ETM+), with 30-m visible and IR bands, a 60-m spatial resolution thermal band, and a 15-m panchromatic band. Failure of onboard electronics halted data collection by Landsat 4 in 1993. The spacecraft was maintained on orbit as a test bed until it was decommissioned in June 2001. Landsat’s 5 and 7, the two remaining operational satellites, orbit at an altitude of 705 km, and each provide a 16-day, 233-orbit cycle. (The two satellite orbits are offset, allowing 8-day repeat coverage.) These satellites were also designed to collect data over a 185-km swath.
-- Volume (data collections / dataset level, and granule level)
The USGS/EROS’s Landsat catalog contains data from all Landsat satellites consisting of 514,402 MSS scenes, 842,888 TM scenes, and 993,873 ETM+ scenes of which all contain browse images.

-- Spatial / temporal coverage
The orbit of Landsat satellites 1-4 were based on the WRS-1 path/row grid system while satellites 5 & 7 utilize the WRS-2 path/row grid. Nadir collects are available globally where on-board data recorders were available. Where data recorders are not available, availability of imagery is dependant on ground receiving station. 

2) Metadata
-- Metadata information model (what is the current status, any near future upgrade working plan?)
We currently provide the capability to export in FGDC format. Future plans include ISO 19115 format. 
-- Languages
English is the base language for metadata and service interfaces within New EE.
-- Example files

Files attached:
Metadata Examples:
	Scene LT40010541992124XXX02 (MSS)
Landsat_MSS_LM10010051973084AAA03_Meta.xls
Landsat_MSS_LM10010051973084AAA03_FGDC.doc
Scene LM10010051973084AAA03 (TM)
Landsat_TM_LT40010541992124XXX02_Meta.xls
Landsat_TM_LT40010541992124XXX02_FGDC.doc
Scene LE70010552000354AGS00 (ETM+)
Landsat_ETM_LE70010552000354AGS00_Meta.xls
Landsat_ETM_LE70010552000354AGS00_FGDC.doc

Field Dictionaries:
Landsat_MSS_Field_Definitions.doc
Landsat_TM_Field_Definitions.doc
Landsat_ETM_Field_Definitions.doc

3) Available data discovery interfaces
-- Any API interfaces for machine-to-machine call? If yes, what about the protocol?
Z39.50, host edcsns17.cr.usgs.gov, port 6675, collections are all registered with the FGDC clearinghouse.

4) Available data access interfaces
-- For direct accessible data, what about the protocol?
Landsat imagery is available for download via HTTP transfer mechanism. All downloads are authenticated via the Earth Explorer user interface. This interface requires that users be registered primarily for the purpose of collecting usage demographics.

-- For non-direct accessible data, do you provide URL to the data ordering system? If yes, where users can find the URL? Is it in the metadata information?
Data that is not available for direct download may be ordered via the Earth Explorer user interface. As with downloads, ordering data also requires that a user be registered and logged in. Once processed, the end user is notified via email that their scene has been processed.

5) Other related issues
-- Any restrictions on data discovery/access?
There are no restrictions towards the actual Landsat data contained within Earth Explorer. There is however the requirement that users be registered and logged in to request or download any imagery. Queries may be executed as a guest user.

Annex 9 – CEOS IDN Partner Survey Response
1) Available data
-- Characteristics

The Global Change Master Directory (GCMD) is an extensive directory of descriptive information about data sets and services relevant to global change research.  For discovery purposes, the directory offers thirteen sets of controlled keywords to assist users in data discovery.  The only required controlled keywords are data center and         which are required for each entry.  The GCMD contains descriptions of data sets covering all Earth Science disciplines that use data to assist in understanding our changing planet. The GCMD includes metadata from the atmospheric science, biology, oceanography, ecology, geology, hydrology, and human dimensions of climate change. This interdisciplinary focus is aimed at researchers exploring the interconnections and interrelations of multidisciplinary variables on global changes.

-- Volume (data collections / dataset level, and granule level)

The GCMD contains: 22,789 DIFs (data set descriptions); 2,214 SERFs (descriptions of services); and 5,847 ancillary descriptions.

-- Spatial / temporal coverage

The GCMD DIF metadata contains both spatial and temporal coverage. Metadata authors can use the docBuilder authoring tool to confirm that the formatting rules are followed, or they can review the guide to confirm the fields are completed correctly.  This is done so that end users can easily search and find the data they are looking for. 

For additional information see the DIF metadata guide: 
http://gcmd.nasa.gov/User/difguide/temporal_coverage.html
http://gcmd.nasa.gov/User/difguide/paleo_temporal_coverage.html
http://gcmd.nasa.gov/User/difguide/spatial_coverage.html

2) Metadata
-- Metadata information model (what is the current status, any near future upgrade working plan?)
 
The GCMD uses the DIF and SERF metadata models.  The DIF is ISO compatible and provides additional controlled fields to help users find metadata.  For a brief history of the DIF, see:
 http://gcmd.nasa.gov/User/difguide/whatisadif.html

The guides to the metadata format can be found at the GCMD website:

DIF Guide:
http://gcmd.nasa.gov/User/difguide/difman.html

and SERF Guide:

Any plans to change the DIF or SERF model are first voted on by the INTEROP participants.  There are currently no pending changes through INTEROP.  However, the IDN will be moving toward the inclusion of all ISO 19115 metadata fields in the future.

-- Languages
English is the primary language for metadata and service interfaces; however, the site has been translated into other languages over time (such as Japanese).

-- Example files

Sample DIF:
http://gcmd.nasa.gov/getdif.htm?GES_DISC_OML1BRVG_V003

Sample SERF:
http://gcmd.nasa.gov/getserf.htm?Glob_Chng_Mast_Direct

3) Available data discovery interfaces
-- Any Application Programming Interface (API) interfaces for machine-to-machine call? If yes, what about the protocol?

The GCMD offers an API for participating partners on a time available basis.  Partners are able to retrieve metadata documents and keywords using the API.   A cooperative agreement is required.

4) Available data access interfaces
-- For direct accessible data, what about the protocol?

-- For non-directly accessible data, do you provide URL to the data ordering system? If yes, where users can find the URL?  Is it in the metadata information?

Yes, it is in the metadata information and is found in the Related_URL field. 

5) Other related issues
-- Any restrictions on data discovery and access?

-  Access restrictions related to the data are defined by the data provider in the Access_Constraints field (
-  DIFs can be restricted by the data provider by setting the Privacy_Status field (

**A password is required to use the authoring tool, docBuilder, to contribute metadata records.

The GCMD metadata model contains the “Use Constraints” and “Access Constraints” fields for the data provider to offer information about the restrictions on using or accessing the data.  For additional information see:
http://gcmd.nasa.gov/User/difguide/access_constraints.html
http://gcmd.nasa.gov/User/difguide/use_constraints.html

The GCMD also provides the authors with the option of displaying an entry in specialized portals for their project or agency.  For information about portals see: 
http://gcmd.nasa.gov/Aboutus/gcmd_faq/about_portals.html

Annex 10 - Phase 2 Development
These are some ideas which arose during the initial discussions of the CWIC requirements but were deferred as lower priority.
I.	Public Interface
1.	Facilitate user registration for access to data holdings which require registration
II.	IDN Interface
1.	Support registration of data sets into the IDN as part of a seamless user interface
III.	Partner Interfaces
1.	Replace native protocols with CSW as implementations permit (via configuration)
Revisit need for smart query routing (based on metadata in IDN?)
I.	EO Client Interface
1.	WGISS Search Criteria
WGISS Application Profile?
Support CSW v2.0.2 EO Products Extension Package (ebRIM) for specific mission-related search
1.	will require extensions in order to support specific mission-related metadata