April 28, 2004

NASA Taxonomy Development Stitching Together Vocabularies for a Unified Information Architecture

Jayne Dutra, Jet Propulsion LaboratoryCalifornia Institute of Technology

Joint Workshop on Multiple TaxonomiesApril 28, 2004

2 April 28, 2004

Life Cycle of Electronic Content in the Real Time Enterprise

• Site Maps• Search Engines• NASA Portals• Content Integration Networks

Finding the right information at the right time to solve the problem at hand

Create

• Content• Assets

Discover

• Logical & Intuitive Filters

• Taxonomy

ClassifyHORSE -DRAWN

CARRIAGE CAR PLANE SPACE SHUTTLE

WHEELS

ENGINE

WINGS

HORSE -DRAWN CARRIAGE CAR PLANE SPACE SHUTTLE

WHEELS

ENGINE

WINGS

3 April 28, 2004

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 April 28, 2004

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 April 28, 2004

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 April 28, 2004

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 April 28, 2004

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 April 28, 2004

Audience Uses Vary Widely

• 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.

Admin

Sci Tech

Public

9 April 28, 2004

Extend Taxonomy Value Space as Needed

• Access Requirements• Audiences• Business Purpose• Competencies • Content Types • Industries• Instruments • Locations• Missions and Projects• Organizations• Subject Categories • Dates• Collections

• http://nasataxonomy.jpl.nasa.gov

NASA Taxonomy Facets (Top Level)

10 April 28, 2004

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 April 28, 2004

• 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

Taxonomy Challenges at JPL

Macrocosms and Microcosms

12 April 28, 2004

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

Data Repositories Identified

Engineering 86

Science 8

Business/Admin. 28

Infrastructure 28

Outreach 1

Total 157

13 April 28, 2004

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 April 28, 2004

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 April 28, 2004

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 April 28, 2004

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 April 28, 2004

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

Content Integration Networks

18 April 28, 2004

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 April 28, 2004

Wrap Up and Discussion

Thank you for your time!• White Paper on Content Integration Networks for NASADutra, 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 April 28, 2004

NASA taxonomy

Back Up Slides

21 April 28, 2004

Selected and Built Test Collection

Collection Source URLNo of Docs

Lessons Learned Database http://llis.nasa.gov 1,370NTRS (NASA Technical Report Server) http://ntrs.nasa.gov 213,900SIRTF (Space Infrared Telescope Facility) Project Library

http://sirtifweb.jpl.nasa.gov 4,054

James Webb Space Telescope (JWST) Project Documents

http://ngst.gsfc.nasa.gov/doclist/bytitle.html 634

22 April 28, 2004

NASA Taxonomy in Action

Taxonomy Demo

http://tb1.siderean.com:7880/test/test2query3.jsp

Logon: NASAPassword: facets

– Hosted by Siderean www.siderean.com with Seamark software

23 April 28, 2004

Goals of Enterprise Data Management

1. Develop/acquire reusable data management infrastructure, tools and technologies to support information management

2. Capture system data definitions and models3. Capture system data object formats4. Support definition of local system architecture and

relationship to lab-wide information architecture5. Define lab-wide data standards for information

capture and dissemination6. Develop mappings between common and local

data models7. Update JPL software lifecycle to reference

standards adoption8. Define/develop standard interfaces to data

systems

24 April 28, 2004

e.g. DATA

Builder

SCOPE(CONTEXTUAL)

MODEL(CONCEPTUAL)ENTERPRISE

Designer

SYSTEMMODEL(LOGICAL)

TECHNOLOGYMODEL(PHYSICAL)

DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)Sub-Contractor

FUNCTIONINGENTERPRISE

DATA FUNCTION NETWORK

e.g. Data Definition

Ent = FieldReln = Address

e.g. Physical Data Model

Ent = Segment/Table/etc.Reln = Pointer/Key/etc.

e.g. Logical Data Model

Ent = Data EntityReln = Data Relationship

e.g. Semantic Model

Ent = Business EntityReln = Business Relationship

List of Things Importantto the Business

ENTITY = Class ofBusiness Thing

List of Processes theBusiness Performs

Function = Class ofBusiness Process

e.g. Application Architecture

I/O = User ViewsProc .= Application Function

e.g. System Design

I/O = Data Elements/SetsProc.= Computer Function

e.g. Program

I/O = Control BlockProc.= Language Stmt

e.g. FUNCTION

e.g. Business Process Model

Proc. = Business ProcessI/O = Business Resources

List of Locations in which the Business Operates

Node = Major BusinessLocatione.g. Business Logistics System

Node = Business LocationLink = Business Linkagee.g. Distributed SystemArchitecture

Node = I/S Function(Processor, Storage, etc)Link = Line Characteristicse.g. Technology Architecture

Node = Hardware/SystemSoftware

Link = Line Specificationse.g. Network Architecture

Node = AddressesLink = Protocols

e.g. NETWORK

Planner

Owner

Builder

ENTERPRISEMODEL

(CONCEPTUAL)

Designer

SYSTEMMODEL

(LOGICAL)

TECHNOLOGYMODEL

(PHYSICAL)

DETAILEDREPRESEN-

TATIONS (OUT-OF

CONTEXT)

Sub-Contractor

FUNCTIONING

MOTIVATIONTIMEPEOPLE

e.g. Rule Specification

End = Sub-conditionMeans = Step

e.g. Rule Design

End = ConditionMeans = Action

e.g., Business Rule Model

End = Structural AssertionMeans =Action Assertion

End = Business ObjectiveMeans = Business Strategy

List of Business Goals/Strat

Ends/Means=Major Bus. Goal/Critical Success Factor

List of Events Significant

Time = Major Business Event

e.g. Processing Structure

Cycle = Processing CycleTime = System Event

e.g. Control Structure

Cycle = Component CycleTime = Execute

e.g. Timing Definition

Cycle = Machine CycleTime = Interrupt

e.g. SCHEDULE

e.g. Master Schedule

Time = Business EventCycle = Business Cycle

List of Organizations

People=Major Organizations

e.g. Work Flow Model

People = Organization UnitWork = Work Producte.g. Human InterfaceArchitecture

People = RoleWork = Deliverablee.g. Presentation Architecture

People = UserWork = Screen Formate.g. Security Architecture

People = IdentityWork = Job

e.g. ORGANIZATION

Planner

Owner

to the BusinessImportant to the Business

What How Where Who When Why

SCOPE(CONTEXTUAL)

e.g. STRATEGY ENTERPRISE

e.g. Business Plan

The Enterprise Framework (John Zachman)

25 April 28, 2004

The Enterprise Framework (John Zachman)

e.g. DATA

Builder

SCOPE(CONTEXTUAL)

MODEL(CONCEPTUAL)ENTERPRISE

Designer

SYSTEMMODEL(LOGICAL)

TECHNOLOGYMODEL(PHYSICAL)

DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)Sub-Contractor

FUNCTIONINGENTERPRISE

DATA FUNCTION NETWORK

e.g. Data Definition

Ent = FieldReln = Address

e.g. Physical Data Model

Ent = Segment/Table/etc.Reln = Pointer/Key/etc.

e.g. Logical Data Model

Ent = Data EntityReln = Data Relationship

e.g. Semantic Model

Ent = Business EntityReln = Business Relationship

List of Things Importantto the Business

ENTITY = Class ofBusiness Thing

List of Processes theBusiness Performs

Function = Class ofBusiness Process

e.g. Application Architecture

I/O = User ViewsProc .= Application Function

e.g. System Design

I/O = Data Elements/SetsProc.= Computer Function

e.g. Program

I/O = Control BlockProc.= Language Stmt

e.g. FUNCTION

e.g. Business Process Model

Proc. = Business ProcessI/O = Business Resources

List of Locations in which the Business Operates

Node = Major BusinessLocatione.g. Business Logistics System

Node = Business LocationLink = Business Linkagee.g. Distributed SystemArchitecture

Node = I/S Function(Processor, Storage, etc)Link = Line Characteristicse.g. Technology Architecture

Node = Hardware/SystemSoftware

Link = Line Specificationse.g. Network Architecture

Node = AddressesLink = Protocols

e.g. NETWORK

Planner

Owner

Builder

ENTERPRISEMODEL

(CONCEPTUAL)

Designer

SYSTEMMODEL

(LOGICAL)

TECHNOLOGYMODEL

(PHYSICAL)

DETAILEDREPRESEN-

TATIONS (OUT-OF

CONTEXT)

Sub-Contractor

FUNCTIONING

MOTIVATIONTIMEPEOPLE

e.g. Rule Specification

End = Sub-conditionMeans = Step

e.g. Rule Design

End = ConditionMeans = Action

e.g., Business Rule Model

End = Structural AssertionMeans =Action Assertion

End = Business ObjectiveMeans = Business Strategy

List of Business Goals/Strat

Ends/Means=Major Bus. Goal/Critical Success Factor

List of Events Significant

Time = Major Business Event

e.g. Processing Structure

Cycle = Processing CycleTime = System Event

e.g. Control Structure

Cycle = Component CycleTime = Execute

e.g. Timing Definition

Cycle = Machine CycleTime = Interrupt

e.g. SCHEDULE

e.g. Master Schedule

Time = Business EventCycle = Business Cycle

List of Organizations

People=Major Organizations

e.g. Work Flow Model

People = Organization UnitWork = Work Producte.g. Human InterfaceArchitecture

People = RoleWork = Deliverablee.g. Presentation Architecture

People = UserWork = Screen Formate.g. Security Architecture

People = IdentityWork = Job

e.g. ORGANIZATION

Planner

Owner

to the BusinessImportant to the Business

What How Where Who When Why

SCOPE(CONTEXTUAL)

e.g. STRATEGY ENTERPRISE

e.g. Business Plan

Taxonomies and metadatamake up the semantic model that informs data models and

other IT infrastructure components.