SOLICITATION NOTICE
A -- LifeLog
- Notice Date
- 5/7/2003
- Notice Type
- Solicitation Notice
- Contracting Office
- Other Defense Agencies, Defense Advanced Research Projects Agency, Contracts Management Office, 3701 North Fairfax Drive, Arlington, VA, 22203-1714
- ZIP Code
- 22203-1714
- Solicitation Number
- BAA03-30
- Response Due
- 5/7/2004
- Archive Date
- 5/7/2004
- Point of Contact
- Dr. Douglas Gage, Program Manager, DARPA/ITO, Phone none, Fax 703-522-7161,
- E-Mail Address
-
none
- Description
- LifeLog, SOL BAA 03-30, Proposals Due: Initial Closing: Mon., June 23, 2003, Final Closing: Fri., May 7, 2004, POC: Dr. Doug Gage, DARPA/IPTO; FAX: (703) 741-7804. PROGRAM OBJECTIVES AND DESCRIPTION. The Information Processing Technology Office (IPTO) of the Defense Advanced Research Projects Agency (DARPA) is soliciting proposals to develop an ontology-based (sub)system that captures, stores, and makes accessible the flow of one person's experience in and interactions with the world in order to support a broad spectrum of associates/assistants and other system capabilities. The objective of this "LifeLog" concept is to be able to trace the "threads" of an individual's life in terms of events, states, and relationships. Functionally, the LifeLog (sub)system consists of three components: data capture and storage, representation and abstraction, and data access and user interface. LifeLog accepts as input a number of raw physical and transactional data streams. Through inference and reasoning, LifeLog generates multiple layers of representation at increasing levels of abstraction. The input data streams are abstracted into sequences of events and states, which are aggregated into threads and episodes to produce a timeline that constitutes an "episodic memory" for the individual. Patterns of events in the timeline support the identification of routines, relationships, and habits. Preferences, plans, goals, and other markers of intentionality are at the highest level. LifeLog is interested in three major data categories: physical data, transactional data, and context or media data. "Anywhere/anytime" capture of physical data might be provided by hardware worn by the LifeLog user. Visual, aural, and possibly even haptic sensors capture what the user sees, hears, and feels. GPS, digital compass, and inertial sensors capture the user's orientation and movements. Biomedical sensors capture the user's physical state. LifeLog also captures the user's computer-based interactions and transactions throughout the day from email, calendar, instant messaging, web-based transactions, as well as other common computer applications, and stores the data (or, in some cases, pointers to the data) in appropriate formats. Voice transactions can be captured through recording of telephone calls and voice mail, with the called and calling numbers as metadata. FAX and hardcopy written material (such as postal mail) can be scanned. Finally, LifeLog also captures (or at least captures pointers to) the tremendous amounts of context data the user is exposed to every day from diverse media sources, including broadcast television and radio, hardcopy newspapers, magazines, books and other documents, and softcopy electronic books, web sites, and database access. LifeLog can be used as a stand-alone system to serve as a powerful automated multimedia diary and scrapbook. By using a search engine interface, the user can easily retrieve a specific thread of past transactions, or recall an experience from a few seconds ago or from many years earlier in as much detail as is desired, including imagery, audio, or video replay of the event. Additional LifeLog applications are discussed in the PIP. LifeLog technology will support the long-term IPTO vision of a new class of truly "cognitive" systems that can reason in a variety of ways, using substantial amounts of appropriately represented knowledge; can learn from experiences so that their performance improves as they accumulate knowledge and experience; can explain their actions and can accept direction; can be aware of their own behavior and reflect on their own capabilities; and can respond in a robust manner to surprises. TASK AREAS. This solicitation seeks proposals to develop and demonstrate LifeLog system-level capabilities as described in the following tasks: Task 1. Representation and Abstraction via Reasoning and Inference. The research focus of the LifeLog program is the appropriate placement of transactional and physical data within an appropriate framework of representations and abstractions to make accessible both the flow of the user's physical experiences in the world and the stream of his or her interactions with other entities in the world. For transactional data, this process of representation and abstraction might begin with the association of metadata with each data item (e.g., the header information in an email or the information on the envelope of a physical letter). Physical data streams generally have to be parsed into meaningful "chunks," such as "saccadic" scenes of video, motion segments in GPS or inertial data, or segments of one person's speech in audio, and these chunks have to be labeled. The key challenge of LifeLog is to make sense of this ongoing sequence of multi-modal transactions and labeled chunks of physical data, by sorting it into discrete "events" and "states" (whose transitions are marked by events) and "threads" (consisting of sequences of events and states) and "episodes" (with beginnings and ends), and to do this automatically and recursively until an extended episode can be identified and labeled as, for example, "I took the 08:30 a.m. flight from Washington's Reagan National Airport to Boston's Logan Airport." The representational path from the raw physical sensor inputs to this high-level description includes concepts of walking, standing, and riding, being indoors and outdoors, being "at home," taking a taxi, and going through airport security. The task can be made considerably easier because LifeLog can also process a "going to Boston" entry in the calendar program, email from the airline telling that the flight is on time, and a phone call ordering the taxi, and can correlate GPS readings to a COTS street map. Beyond the generation of the user's individual timeline or history, represented as a structure of labeled threads and episodes, LifeLog will be able to find meaningful patterns in the timeline, to infer the user's routines, habits, and relationships with other people, organizations, places, and objects, and to exploit these patterns to ease its task. The proposal should describe in detail exactly how the offeror's LifeLog system will accomplish this process of "tracing the threads" and "telling the story" of the user's experience. State how physical sensory inputs will be parsed and classified (labelled). Define the metadata to be used for each type of input data. Describe how the representation hierarchy is to be constructed, and how classification of events, states, etc., will be performed. Explicitly address the extraction of patterns such as routines, habits, and relationships. Present an approach for assessing the contribution of each data source proposed to LifeLog system-level performance. Provide a comparison of the relative importance of human knowledge engineering and machine learning components both during system development and when deployed. Discuss the tools to be provided to the user to support the visualization and manual generation and editing of the representational hierarchy. Task 2: Data Capture and Storage Subsystem. LifeLog must acquire data to capture both the user's physical experiences in the world and his or her interactions with other entities in the world. The specific types and fidelity of data to be captured should be driven by the needs implied by the offeror's approach to Task 1. Physical data is captured by various physical sensors and is stored as multiple data streams in appropriate formats at appropriate resolutions. Transactional data is extracted principally from a number of computer applications. Detectors, recognizers, analysis tools, and heuristics are used to "distill" the data, associating metadata, flagging keywords, and otherwise preparing the data for further categorization in terms of representations at various levels of abstraction. Data capture capability must be adequate to support the development of LifeLog, but should not involve new development of sensors. The proposal should identify the sources and modalities of physical, transactional, and context/media data to be captured, and also the specific sensors and deployment (e.g., wearable) means to be used for gathering physical data, and the methods to be used to acquire transactional and context/media data. The proposal should identify the data storage components to be employed and provide an estimate of the volume of data of each type to be stored per unit time. Selection rationale for components, including critical specifications and estimated costs, should be presented. LifeLog system integration should be specifically addressed, together with power and endurance issues. Offerors must also address human subject approval, data privacy and security, copyright, and legal considerations that would affect the LifeLog development process. Leverage of existing hardware and software is highly encouraged, and LifeLog should interface to commonly used computer applications. Task 3. Data Access and User Interface Subsystem. The initial LifeLog prototype implementation must provide a functional Application Programming Interface (API), as well as a stand-alone user data access capability which is envisioned to be a search-engine style interface allowing functions (e.g., less than, greater than, Booleans) of the various metadata parameters. Offerors should propose additional features to enhance the user interface (e.g., timeline displays) and to augment the API to support use by additional applications. The developmental interface should also provide a query capability to enable the user to learn why the system behaved as it did. In addition, the interface should provide intervention tools to enable the user to manually create metadata, assign classifications, and edit the abstraction hierarchy. The capabilities of the proposed access scheme should be described in terms of the flexibility of access queries to be supported (of primary concern) and expected performance, such as response time. Leveraging of existing software is encouraged, since the user interface is not a principal subject of research for LifeLog. Task 4: Experimentation and Performance Assessment. The successful development of LifeLog will require extensive experimentation to provide both the system and its developers with enough "experience" to be representative of use in the real world. The first LifeLog users will clearly be the developer team itself, and, once a critical initial threshold of capability has been achieved, the results of this use should be documented as longitudinal studies. Operating conditions should not be controlled, and a broad spectrum of both physical and transactional data should be captured over weeks of continuous real-world use. The proposal should address performance assessment over these longitudinal studies, and address the metrics of completeness of the ontology and correctness of the LifeLog's classification decisions. The LifeLog program also includes a "Challenge Problem" in the form of a system demonstration while taking a trip to Washington D.C. Travel combines physical activity (movement via a variety of conveyances) and a diversity of transactions (email, calendar, financial, itinerary, etc.) over the course of a trip. The Travel Challenge consists of an uncontrolled trip from the user's home to Washington, plus controlled trials involving travel over a government-prescribed course within the D.C. area, each trial lasting less than one day. Each proposer is encouraged to have at least three (3) LifeLog users participate in the Travel Challenge. Proposals should include plans for participation in these experiments, specifically including a plan for measuring the performance of the LifeLog system in terms of correctness and completeness. These metrics are defined in detail in the PIP. The results of the Travel Challenge will be a major determinant of the scope and course of future LifeLog development, including the exercise of proposed options. Offerors should also propose other challenge activities in addition to the Travel Challenge to demonstrate and assess the richness of the LifeLog representation structure and complexity of the domain (task and environment). Additional metrics should also be proposed. Task 5: Options for Advanced LifeLog Development. The base efforts solicited by this BAA address critical issues that must be tackled to demonstrate a basic LifeLog capability. However, many other equally critical and challenging issues must be addressed to realize a fully deployable LifeLog (sub)system. Therefore, the proposal may include one or more options to perform additional work addressing relevant technical questions, including but not limited to the following: (a) How should the LifeLog system enforce security and privacy, given that different data sources may require different restrictions (i.e., classified, proprietary, privacy act) on each data element, and a given item of data may be acquired from more than one source? (b) How should different people's LifeLog systems interact with each other? For example, if each person's LifeLog understands only his/her own speech perfectly, how should multiple LifeLogs share information so that each can acquire and store all parts of a conversation? (c) How should LifeLog be implemented so that it can degrade gracefully in its access modes, storage resources, and capture capabilities? (d) How can the domain of intentionality (plans and goals) above the level of timeline or history be more fully developed so that LifeLog can effectively support the broadest possible spectrum of assistive and training applications? Proposed options should include a clear statement of the functionality and performance benefits envisioned, and should define metrics to support the assessment of these benefits. PROGRAM SCOPE. This solicitation seeks proposals that address the development of system-level LifeLog capabilities and which fully address Tasks 1 through 4. A proposal that instead focuses on one or more specific individual technologies will be considered, but to be successful it must make a clearly convincing case that the effort would provide an extremely high payoff. Proposed efforts should cover a base 18-month period of performance and may include one or more options, whose period of performance should not exceed 24 months. The project schedule must include an initial kick-off meeting, an engineering design review 6 months after award to approve the architecture and implementation plan, a Principal Investigators' Meeting 9 months after award, and a final project review associated with the Travel Challenge, 16 months after award. Up to four awards are anticipated, and teaming is highly encouraged. Proposed research should investigate innovative approaches and techniques that lead to or enable revolutionary advances in the state-of-the-art. Proposals are not limited to the specific strategies listed above, and alternative visions will be considered. However, proposals should be for research that substantially contributes towards the goals stated. Research should result in prototype hardware and/or software demonstrating integrated concepts and approaches. Specifically excluded is research that primarily results in evolutionary improvement to the existing state of practice or focuses on a specific system or solution. Integrated solution sets embodying significant technological advances are strongly encouraged over narrowly defined research endeavors. Proposals may involve other research groups or industrial cooperation and cost sharing. The establishment of LifeLog as an approved DARPA program is dependent upon the quality of the responses to this BAA. GENERAL INFORMATION. This Broad Agency Announcement (BAA) requires completion of a BAA Cover Sheet for each Proposal prior to submission. This cover sheet can be accessed at the following URL: http://www.dyncorp-is.com/BAA/index.asp?BAAid=03-30 After finalizing the BAA Cover Sheet, the proposer must print the BAA Confirmation Sheet that will automatically appear on the web page. Each proposer is responsible for printing the BAA Confirmation Sheet and attaching it to every copy. The Confirmation Sheet should be the first page of the Proposal. If a proposer intends on submitting more than one Proposal, a unique UserId and password should be used in creating each BAA Cover Sheet. Failure to comply with these submission procedures may result in the submission not being evaluated. NEW REQUIREMENTS/PROCEDURES: The Award Document for each proposal selected and funded will contain a mandatory requirement for electronic submission of DARPA/IPTO Quarterly Status Reports and an Annual Project Summary Report via the DARPA/IPTO Technical-Financial Information Management System (T-FIMS), utilizing the government-furnished Uniform Resource Locator (URL) on the World Wide Web (WWW). See Proposer Information Pamphlet (PIP) for further details. PROPOSAL FORMAT. Proposers must submit an original and 3 copies of the full proposal and 2 electronic copies (i.e., 2 separate disks) of the full proposal (in PDF or Microsoft Word 2000 for IBM-compatible format on a 3.5-inch floppy disk, 100 MB Iomega Zip disk or cd). Mac-formatted disks will not be accepted. Each disk must be clearly labeled with BAA 03-30, proposer organization, proposal title (short title recommended) and "Copy <n> of 2". The full proposal (original and designated number of hard and electronic copies) must be submitted in time to reach DARPA by 12:00 PM (ET) Mon., June 23, 2003, in order to be considered during the initial evaluation phase. However, BAA 03-30, LifeLog will remain open until 12:00 NOON (ET) Fri., May 7, 2004. Thus, proposals may be submitted at any time from issuance of this BAA through Fri., May 7, 2004. While the proposals submitted after the Fri., June 23, 2003, deadline will be evaluated by the Government, proposers should keep in mind that the likelihood of funding such proposals is less than for those proposals submitted in connection with the initial evaluation and award schedule. DARPA will acknowledge receipt of submissions and assign control numbers that should be used in all further correspondence regarding proposals. Proposers must obtain the BAA 03-30 Proposer Information Pamphlet (PIP), which provides further information on the areas of interest, submission, evaluation, funding processes, proposal abstracts, and full proposal formats. This pamphlet will be posted directly to FedBizOpps.gov and may also be obtained by fax, electronic mail, mail request to the administrative contact address given below, or at URL address http://www.darpa.mil/ipto/Solicitations/index.html. Abstracts and proposals not meeting the format described in the pamphlet may not be reviewed. This notice, in conjunction with the BAA 03-30 PIP and all references, constitutes the total BAA. No additional information is available, nor will a formal RFP or other solicitation regarding this announcement be issued. Requests for same will be disregarded. The Government reserves the right to select for award all, some, or none of the proposals received. All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA. Historically Black Colleges and Universities (HBCUs) and Minority Institutions (MIs) are encouraged to submit proposals and join others in submitting proposals. However, no portion of this BAA will be set aside for HBCU and MI participation due to the impracticality of reserving discrete or severable areas of this research for exclusive competition among these entities. Evaluation of proposals will be accomplished through a scientific review of each proposal, using the following criteria, which are listed in descending order of relative importance: (1) Overall Scientific and Technical Merit: The overall scientific and technical merit must be clearly identifiable and compelling. The technical concept should be clearly defined, developed and defensibly innovative. Emphasis should be placed on the technical excellence of the development and experimentation approach. (2) Innovative Technical Solution to the Problem: Proposed efforts should apply new or existing technology in an innovative way such as is advantageous to the objectives. The plan on how the offeror intends to get developed technology artifacts and information to the user community should be considered. The offeror shall specify quantitative experimental methods and metrics by which the proposed technical effort's progress shall be measured. (3) Potential Contribution and Relevance to DARPA/IPTO Mission: The offeror must clearly address how the proposed effort will meet the goals of the undertaking and how the proposed effort contributes to significant advances to the DARPA/IPTO mission. (4) Offeror's Capabilities and Related Experience: The qualifications, capabilities, and demonstrated achievements of the proposed principals and other key personnel for the primary and subcontractor organizations must be clearly shown. (5) Plans and Capability to Accomplish Technology Transition: The offeror should provide a clear explanation of how the technologies to be developed will be transitioned to capabilities for military forces. Technology transition should be a major consideration in the design of experiments, particularly considering the potential for involving potential transition organizations in the experimentation process. (6) Cost Realism: The overall estimated cost to accomplish the effort should be clearly shown as well as the substantiation of the costs for the technical complexity described. Evaluation will consider the value to Government of the research and the extent to which the proposed management plan will effectively allocate resources to achieve the capabilities proposed. Cost is considered a substantial evaluation criterion but secondary to technical excellence. All administrative correspondence and questions on this solicitation, including requests for information on how to submit a proposal to this BAA, must be received at one of the administrative addresses below by 12:00 NOON (EST) Fri., April 30, 2004; e-mail or fax is preferred. DARPA intends to use electronic mail and fax for some of the correspondence regarding BAA 03-30. Proposals MUST NOT be submitted by fax or e-mail; any so sent will be disregarded. All proposals, administrative correspondence, and questions submitted in response to this solicitation must be in the English language. Submissions received in other than English shall be rejected. Restrictive notices notwithstanding, proposals may be handled, for administrative purposes only, by a support contractor. This support contractor is prohibited from competition in DARPA technical research and is bound by appropriate non-disclosure requirements. Input on technical aspects of the proposals may be solicited by DARPA from non-Government consultants/experts who are bound by appropriate non-disclosure requirements. Non-Government technical consultants/experts will not have access to proposals that are labeled by their offerors as "Government Only." While non-government personnel may review proposals, contractors will not be used to conduct evaluations or analyses of any aspect of a proposal submitted under this BAA, unless one of the three conditions identified in FAR 37.203(d) applies. The administrative addresses for this BAA are: Fax: (703) 741-7804 Addressed to: DARPA/IPTO, BAA 03-30, Electronic Mail: baa03-30@darpa.mil, Electronic File Retrieval: http://www.darpa.mil/ipto/Solicitations/index.html, Mail to: DARPA/IPTO, ATTN: BAA 03-30, 3701 N. Fairfax Dr., Arlington, VA 22203-1714.
- Record
- SN00319782-W 20030509/030507213734 (fbodaily.com)
- Source
-
FedBizOpps.gov Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |