NASA Taxonomy Development Stitching Together Vocabularies for a Unified Information Architecture

1. NASA Taxonomy Development Stitching Together Vocabularies for a Unified Information Architecture Jayne Dutra, Jet Propulsion Laboratory California Institute of Technology Joint Workshop on Multiple TaxonomiesApril 28, 2004

2. Classify Life Cycle of Electronic Content in the Real Time Enterprise Discover Create • Site Maps • Search Engines • NASA Portals • Content Integration Networks • Logical & Intuitive Filters • Taxonomy • Content • Assets Finding the right information at the right time to solve the problem at hand

3. Taxonomy Basics What is the NASA Taxonomy? • A classification scheme meant to encompass all of NASA web content (NASA web space) including internal as well as external material. • It is a means for tagging content so it can be used and reused in different contexts.

4. Project Goals: Enable Knowledge Discovery and Reuse • Make it easy for various audiences to find relevant information from NASA programs quickly • Provide easy access for NASA resources found on the Web for reuse – text, data, tools • Provide search results targeted to user interests • Enable the ability to move content through the enterprise to where it is needed most • Improve NASA’s ability to compete and perform through better efficiencies of work processes • Comply with E-Government Act of 2002 • Be ready to participate in federal XML projects

5. NASA Taxonomy Best Practices The Long and Winding Road • Design process that: • Incorporates existing federal and industry terminology standards like NASA AFS, NASA CMS, FEA BRM, NAICS, and IEEE LOM. • Provides for NASA XML namespace registry (DISA) – it becomes a NASA standard • Complies with metadata standards like Z39.19, ISO 2709, and Dublin Core. • Methodology increases interoperability and extensibility • It also makes visible the gaps in our IA

6. IA from the Top Down Using the NASA Taxonomy • This is a generic taxonomy from which specializations can be derived for specific purposes • General by design • Not all facets need to be used in each instance • A facet is repeatable • The taxonomy is modular and dynamic • Provides a means to map elements from different schema • Provides good discrimination of terms with some big buckets

7. Early Task Objectives • Understand current strategies and practices for creating, collecting, and organizing information across NASA. • Observe how information is used and organized, the audiences for this information, and the information needs of these audiences. • Elicit goals, hopes, and concerns for an information architecture solution. • Start building a community of interest.

8. Better understand the program in total, and obtain scheduling information, project status and best practices. Access procurement rules and examples, and procurement action synopses. Engineering specifications. Scholarly research, competitive intelligence, and general aerospace research. Catalogue science data products after missions Develop educational products, support current products, learn, etc. Topic research and fact finding, topic background research, and downloading curriculum support materials. In the classroom as stand alone items, hands-on learning opportunities, class projects, to expand on a student’s learning potential. Find NASA contact information on services, information about student opportunities, information about career opportunities, and latest educational news. Audience Uses Vary Widely Admin Sci Tech Public

9. Extend Taxonomy Value Space as Needed NASA Taxonomy Facets (Top Level) • Access Requirements • Audiences • Business Purpose • Competencies • Content Types • Industries • Instruments • Locations • Missions and Projects • Organizations • Subject Categories • Dates • Collections • http://nasataxonomy.jpl.nasa.gov

10. NASA Challenges • Extremely distributed information environment • Different legacy systems at each Center • No formal approval process at the management level – and many changes in staffing • Many different communities • Perhaps need to define large communities and develop ontologies specific to broader knowledge domains • Funding is sparse and also distributed

11. Macrocosms and Microcosms Taxonomy Challenges at JPL • Highly decentralized IT work force • Sponsor funded programs and projects drive laboratory • For example, standards for NASA missions may drive technical decisions • Competitive funding model encourages silos • JPL CIO lacks governance over sponsor funded activities • Wide “gap” between IT for “Business” and IT for “Missions” • Missions tend to “roll their own” infrastructure • IT staff tends to be local to the project

12. Results of 2003 JPLInformation Repositories Study • Fragmented and non-interoperable repositories • Inefficient and broken processes and applications • Parallel and redundant efforts both in building information systems and managing data • Limited tools and services that cut across program and line organizations

13. Information Architecture Gaps • No common data model or service architecture to support cross repository search – many distributed systems • Difficulty in getting visibility and senior management champions • Difficulty in getting resources to address the issues • Difficulty in getting IT funding centralized and strategically planned – CIO Office

14. Partnership with EA and CIO • Governance (or Enterprise Architecture Management) • Enterprise Architecture Working Group • Principles, Guidelines and Portfolio Management • Common Methodologies to System Development • Enterprise Information Architecture • Management of information across JPL information systems • Support development of an interoperable information infrastructure • Project Architects • Funded by CIO, assigned project roles • Architecture alignment: principles and common infrastructure (data, technology, services and process)

15. Semantic Frameworks and Data Architecture JPL Data architects have more visibility and support than the Library So Why Are They Interested in Taxonomies? • Data dictionaries are too narrow to interoperate • Data architects are seeking “data harmonization” • Semantic frameworks allow for mappings of data elements to larger vocabularies • Thesauri capability needed • Zachman is helpful in defining roles

16. Current Status of “JPL Core” • Metadata Core spec for project documents now proposed – test, validation, etc. • Effort originally related to Records Retention requirements • Still too technology specific (Docushare) • Open Issues: • Identifying document types that work for users • JPL specific processes call for JPL specific vocabularies: need a JPL taxonomy • Retention not based solely on document type • Atomic vocabulary components that are combined to determine retention schedules • Balance between enough tags to describe an object usefully and the amount of tags someone will actually fill out

17. Content Integration Networks Most Recent Work: Integrating Engineering Repositories • Reuse work from taxonomy and information architecture tasks • Identification of engineering repositories and technologies • Engineering content tagged with topic, repository, product or discipline semantic markers • Integration of content based on semantic properties • Utilizes Web Services infrastructure and RDF to make content portable (Seamark tool) • Goal: Embed content into mission development processes

18. Status of NASA Taxonomy • CIO Board approval • Define review and approval process • Facilitate review and approval process • Deliver metadata specification • Formalize taxonomy as XML schema • Delegate taxonomy stewardship • Within NASA CIO Office • Plan follow-on work • Various implementations in NASA Web apps

19. Wrap Up and Discussion Thank you for your time! • White Paper on Content Integration Networks for NASA • Dutra, Xiao, 2/4/2004 • https://pub-lib.jpl.nasa.gov/pub-lib/dscgi/ds.py/Get/File-118/Content_Integration_Networks_WP_02_11_04.doc

20. NASA taxonomy Back Up Slides

21. Selected and Built Test Collection

22. NASA Taxonomy in Action Taxonomy Demo http://tb1.siderean.com:7880/test/test2query3.jsp Logon: NASA Password: facets • Hosted by Siderean www.siderean.com with Seamark software

23. Goals of Enterprise Data Management • Develop/acquire reusable data management infrastructure, tools and technologies to support information management • Capture system data definitions and models • Capture system data object formats • Support definition of local system architecture and relationship to lab-wide information architecture • Define lab-wide data standards for information capture and dissemination • Develop mappings between common and local data models • Update JPL software lifecycle to reference standards adoption • Define/develop standard interfaces to data systems

24. The Enterprise Framework (John Zachman) TIME MOTIVATION PEOPLE DATA What FUNCTION How NETWORK Where Who When Why List of Things Important List of Processes the List of Locations in which List of Organizations List of Events Significant List of Business Goals/Strat SCOPE SCOPE to the Business Business Performs the Business Operates to the Business Important to the Business (CONTEXTUAL) (CONTEXTUAL) ENTITY = Class of Planner Function = Class of Ends/Means=Major Bus. Goal/ Node = Major Business Planner Time = Major Business Event Business Thing People=Major Organizations Business Process Critical Success Factor Location e.g. Master Schedule e.g. Business Plan e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics e.g. Work Flow Model ENTERPRISE ENTERPRISE System MODEL MODEL (CONCEPTUAL) (CONCEPTUAL) Owner Owner Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System Architecture e.g. Human Interface Architecture e.g. Processing Structure e.g., Business Rule Model SYSTEM SYSTEM MODEL MODEL (LOGICAL) (LOGICAL) Node = I/S Function Ent = Data Entity People = Role Proc .= Application Function Time = System Event End = Structural Assertion (Processor, Storage, etc) Designer Designer Cycle = Processing Cycle Reln = Data Relationship Work = Deliverable I/O = User Views Link = Line Characteristics Means =Action Assertion e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Control Structure e.g. Rule Design e.g. Presentation Architecture TECHNOLOGY TECHNOLOGY MODEL MODEL (PHYSICAL) (PHYSICAL) Node = Hardware/System Builder Ent = Segment/Table/etc. Proc.= Computer Function End = Condition Builder People = User Time = Execute Software Reln = Pointer/Key/etc. I/O = Data Elements/Sets Work = Screen Format Cycle = Component Cycle Means = Action Link = Line Specifications DETAILED e.g. Security Architecture e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Timing Definition e.g. Rule Specification DETAILED REPRESEN- REPRESEN- TATIONS TATIONS (OUT-OF (OUT-OF- CONTEXT) CONTEXT) Sub- Sub- Contractor Proc.= Language Stmt Ent = Field Node = Addresses People = Identity Time = Interrupt End = Sub-condition Contractor Reln = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step FUNCTIONING FUNCTIONING e.g. ORGANIZATION e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. SCHEDULE e.g. STRATEGY ENTERPRISE ENTERPRISE

25. TIME MOTIVATION PEOPLE DATA What FUNCTION How NETWORK Where Who When Why List of Things Important List of Processes the List of Locations in which List of Organizations List of Events Significant List of Business Goals/Strat SCOPE SCOPE to the Business Business Performs the Business Operates to the Business Important to the Business (CONTEXTUAL) (CONTEXTUAL) ENTITY = Class of Planner Function = Class of Ends/Means=Major Bus. Goal/ Node = Major Business Planner Time = Major Business Event Business Thing People=Major Organizations Business Process Critical Success Factor Location e.g. Master Schedule e.g. Business Plan e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics e.g. Work Flow Model ENTERPRISE ENTERPRISE System MODEL MODEL (CONCEPTUAL) (CONCEPTUAL) Owner Owner Ent = Business Entity Proc. = Business Process Node = Business Location People = Organization Unit Time = Business Event End = Business Objective Reln = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System Architecture e.g. Human Interface Architecture e.g. Processing Structure e.g., Business Rule Model SYSTEM SYSTEM MODEL MODEL (LOGICAL) (LOGICAL) Taxonomies and metadata make up the semantic model that informs data models and other IT infrastructure components. Node = I/S Function Ent = Data Entity People = Role Proc .= Application Function Time = System Event End = Structural Assertion (Processor, Storage, etc) Designer Designer Cycle = Processing Cycle Reln = Data Relationship Work = Deliverable I/O = User Views Link = Line Characteristics Means =Action Assertion e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Control Structure e.g. Rule Design e.g. Presentation Architecture TECHNOLOGY TECHNOLOGY MODEL MODEL (PHYSICAL) (PHYSICAL) Node = Hardware/System Builder Ent = Segment/Table/etc. Proc.= Computer Function End = Condition Builder People = User Time = Execute Software Reln = Pointer/Key/etc. I/O = Data Elements/Sets Work = Screen Format Cycle = Component Cycle Means = Action Link = Line Specifications DETAILED e.g. Security Architecture e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Timing Definition e.g. Rule Specification DETAILED REPRESEN- REPRESEN- TATIONS TATIONS (OUT-OF (OUT-OF- CONTEXT) CONTEXT) Sub- Sub- Contractor Proc.= Language Stmt Ent = Field Node = Addresses People = Identity Time = Interrupt End = Sub-condition Contractor Reln = Address I/O = Control Block Link = Protocols Work = Job Cycle = Machine Cycle Means = Step FUNCTIONING FUNCTIONING e.g. ORGANIZATION e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. SCHEDULE e.g. STRATEGY ENTERPRISE ENTERPRISE The Enterprise Framework (John Zachman)