The Internationalization (i18n) Product Retrieval Service (iPReS)

Project Overview

The Internationalization (i18n) Product Retrieval Service is a web service and client providing i18n-type access to products and product metadata contained within NASA JPL's Physical Oceanography Distributed Active Archive Center, otherwise known as PO.DAAC.

The software implements a RESTful web-service and client to obtain data from the PO.DAAC Web-Services API. It then translates the product metadata into a target language provided along with the intial call to the service.

Project News

• iPReS @ 2015 IEEE 16th International Conference on Information Reuse and Integration: The iPReS Project was included within conference proceedings in the paper titled Enabling Linguistic Analysis of Scientific Metadata through Internationalizing NASA JPL's PODAAC. The event was held 13-15 August 2015 in San Francisco, California, USA. Please see the Full-text as PDF, Full-text in HTML and the Conference Poster.
• iPReS @ ApacheCon NA 2015, Austin, TX: The iPReS Project is being represented at ApacheCon NA 2015 which is taking place in the Hyatt, Austin, TX 13th-16th, 2015. The presentation on Exploring Apache Tika's Translate API to Enable Linguistic Analysis of Scientific Metadata through Internationalizing NASA JPL’s Physical Oceanographic Data Active Archive Centre will cover the project demonstration and represent a HUGE platform and achivement for the iPReS project as it progresses towards completion within the Capstone project.

Supported Product Translations

• ar: Arabic
• bg: Bulgarian
• ca: Catalan
• zh-CHS: Chinese Simplified
• zh-CHT: Chinese Traditional
• cs: Czech
• da: Danish
• nl: Dutch
• en: English
• et: Estonian
• fi: Finnish
• fr: French
• de: German
• el: Greek
• ht: Haitian Creole
• he: Hebrew
• hi: Hindi
• mww: Hmong Daw
• hu: Hungarian
• id: Indonesian
• it: Italian
• ja: Japanese
• tlh: Klingon
• tlh-Qaak: Klingon (pIqaD)
• ko: Korean
• lv: Latvian
• lt: Lithuanian
• ms: Malay
• mt: Maltese
• no: Norwegian
• fa: Persian
• pl: Polish
• pt: Portuguese
• ro: Romanian
• ru: Russian
• sk: Slovak
• sl: Slovenian
• es: Spanish
• sv: Swedish
• th: Thai
• tr: Turkish
• uk: Ukrainian
• ur: Urdu
• vi: Vietnamese
• cy: Welsh

Project Members

• Client Team


• Kathryn O’Brien
• Chris Mattmann
• Lewis John McGibbney
• Engineering Team


• Phillip Carter
• Bhavik Patel
• Daniel Song

Requirements To Be Finished

( (): Indicates corresponding requirement in the Project Requirements Document. )

1. The system shall be able to break down each piece of a request, and understand which portions of PO.DAAC data sets are being requested. (6)
2. The system shall be able to filter and merge PO.DAAC data sets based on request information from Requirement 6. (7)
3. The system shall contain extensive tests to verify Requirement 6. (29)
4. The system shall contain extensive tests to verify Requirement 7. (8)
5. The system shall make use of Apache Tika to translate PO.DAAC data and metadata into a target language. (10)
6. The system shall contain a Distributed Cache on the PO.DAAC-facing layer which caches data and metadata which hasalready been translated. This will be based on popularity, if requested data is a subset of other data sets, etc. (14)
7. The system shall recognize which data sets are to be cached, or which information is already cached (this information is still pending due to the need to communicate with the scientific community about their desires). (15)
8. The system shall make use of Ring, a mature HTTP abstraction library for writing web servers. (21)
9. The system shall use Leiningen (preferred) or Maven for build automation. (22)

1. The system shall contain extensive Unit tests to verify Requirement 10.(12)
2. The system shall contain extensive Unit Tests for Requirements 14 and 15.(16)
3. The system shall be capable of merging translated data sets from the cache and PO.DAAC/Tika services based on client requests. (17)
4. The system shall contain extensive Unit Tests for Requirement 17. (18)
5. The system shall contain an Integration Test which verifies the pieces of the system specified by Requirements 6, 7, 9, 10, 13, 14, and 15 communicate correctly. (19)
6. The system shall make use of Compojure for handling API routing.(20)
7. The system shall be capable of handling multiple clients. At the minimum, data requested shall be serviced to the correct client under concurrent request scenarios. (3)
8. The client-facing layer shall be capable of exposing requested data sets in Scientific Data Formats Oceanographers are used to using (HDF4, HDF5, etc). The specific data formats will be determined in the future based on the demand for the system. (23)
9. The system shall adhere to REST methodology, and aim for being easily-integrated into future mobile applications focused on data analysis. (27)

1. The system shall ideally support all of the languages mentioned in the supported translations list (1)
2. The system shall be able to handle at least 25 concurrent requests without experiencing some kind of error. (4)
3. The system shall contain extensive tests to verify Requirements 3 and 4. (5)
4. The system shall make use of Apache Tika to translate PO.DAAC data and metadata into a target language. (10)
5. The system shall aim to tie in with other software tools available within the PO.DAAC development components and sandbox. The aim is to further increase the usefulness of the iPReS service. (26)
6. The system shall contain a System Load Test which attempts to crash the service when all pieces are connected. (28)

Google Forum