Multi-dimensional metadata in research recordkeeping

A system and method for facilitating data organization, for example in the organization of data in management of intellectual property records, is disclosed herein. Further, the present invention particularly provides a contextualization of information objects so that a full value of research and development (R&D) efforts can be accumulated by an organization. The system as disclosed herein collects information (raw) objects from a plurality of sources. Then, based on inferred context and user input, the system classifies each object in multiple dimensions according to needs of the application; and finally creates a high value, layer rich database embodying a context as well as a result to add value to a research process.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention pertains generally to an improvement in record keeping for scientific research. More specifically, the present invention pertains to systems and methods for memorializing data in research management and collection of intellectual property. The present invention in a preferred embodiment is particularly, but not exclusively, useful as a multidimensional metadata system and method in a laboratory research environment.

2. Description of the Prior Art

Research and development programs are designed to produce information. Gathering and using the information is a critical need to of all organizations that sponsor research and development (R&D).

Further, record keeping systems used to record intellectual property and manage research information are often developed with a specific purpose in mind. For example, timekeeping systems keep track of hours, protocol management systems maintain experimental procedures. Similarly, image databases hold images from microscopes, and laboratory notebooks are used to record a researcher's, contemporaneous thoughts, observations, and conclusions.

Recently, increasing computer computational power and data storage along with efficient searching capability has resulted in less need to selectively record information; indeed it is logical and appropriate in most circumstances to accurately retain all information indefinitely.

Accessing multiple systems and large amounts of information is often a burdensome task which requires intensive human involvement. Not only are the use of different systems and architectures a problem, but even when the information is on the same computer and in the same database, it is not always comparable and very easily accessible.

In a scientific environment, results are only meaningful if an experiment can be replicated. Unless all the relevant information is included in data records and indexed accordingly, results alone can be meaningless. The context of a result is as important as the result itself and without complete contextual information, data is often not reproducible.

Moreover, differing commercial needs from end users and application developers have promoted a situation where information is collected in islands. Vendors of software, equipment, and supplies have often provided databases that merely promote a single business use.

Database driven indexing methods are also partially to blame for poor recordkeeping. The use of non-sequential and non-unique indices, such as groupings by sets and subsets, non-alphabetically, semantically, and according to image characteristics is rare and difficult in research information management.

In light of the above, it is an object of the present invention to provide a framework to organize research and development information in a flexible and manageable way where the context of the information is as important as the information itself. It is still further an object of the present invention to provide a system for contextualizing information through a number of multidimensional metadata dimensions allowing data objects from a variety of sources to be incorporated in a truly enterprise wide research information infrastructure.

BRIEF SUMMARY OF THE INVENTION

The present invention specifically addresses and alleviates the above mentioned deficiencies, more specifically, the present invention is directed to a system for recording and management of data comprising: raw data objects, wherein the raw data objects are received and stored; processed data objects, wherein one or more dimensions are applied to the raw data objects to form the processed data objects, and wherein the dimensions represent information about the raw data object; and one or more metadata organizing models wherein the metadata organizing models together with the dimensions maximize a utility of the data at a later time providing a contextual space to the data object.

The system for recording and management of data is further characterized wherein the dimensions are indices in a relational database. Also, the invention is characterized wherein the one or more dimensions comprise: a continuum; a discrete model; a strict hierarchy; a soft hierarchy; a hashing; and a grouping.

The system for recording and management of data is additionally characterized wherein the one or more dimensions further comprise: a personnel responsible; a consumable media used; a physical location of the experiment; a protocol in effect; an instrument used; a disease or a research focus; a genus and a species of the sample; a reagent consumed; a time of an observation; a time consumed in an experiment; a lab notebook page; and a research program indicating a funding source.

The system for recording and management of data is still further characterized wherein each raw data object and each processed data object comprises XML (Extensible Markup Language), the system further comprising XML tags for each dimension. Additionally, raw data objects are automatically assigned appropriate dimensions based on a proximity in time, or other parameter, to a related other data object. Still further, the raw data objects are placed on appropriate dimensions based on an assistance of a user, a researcher, or a creator of intellectual property; and the raw data objects comprise a complex data object containing a database, according to a preferred embodiment.

The system for recording and management of data is still further characterized in that the processed data objects each comprise: hashing providing abbreviated indexing for providing an ease of lookup and comparison; encryption providing security and integrity of the processed data objects; a time stamp; and an electronic signature wherein the time stamp and electronic signature together provide for a validation and a proper evidentiary support in a legal process. Moreover, the system further comprises a system of software applications connected on a network of computers and data storage devices. Yet further, the system is characterized wherein a user is able to define and replace the dimensions according to needs of a particular application.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Management of intellectual property, such as that which may be required in an enterprise performing research and development (R&D), or where an investigation is conducted in a forensic or legal setting, involves a collection and creation of units of information.

In a general sense, the present invention revolves around adding metadata to collected data objects10. Data objects10herein refer to collected and received packets of information. They are typically objects selected from a variety of complex data types. For example, complex data types may be images, audio recordings, textual information, arrays of numeric data, output of instruments, or the product of algorithmic processing. The term metadata herein refers to “data about data” or the information that describes the data objects10which are collected.

Now turning toFIG. 1, a schematical representation of a raw data object10as prepared and processed111by system100(FIG. 3) is illustrated. Any data object10of any size can be accommodated. Typically an XML (Extensible Markup Language) format is used to provide maximum interoperability and associate each data item with its appropriate type. The data object10is a received piece of information generated by another software program, for example. It10can be any data type and is typically an image, audio recording, numeric value, array of numeric values, matrix or other data type. The subject invention is designed to handle any type, but does not necessarily need to interpret the contents of the data object10.

Optionally, either originating before or during the processing111of the data object10, it is possible to add encryption, hashing, security and validation data, time stamps, and electronic signatures11. If this information11is provided or created by the subject invention, it is to be added as a external wrapper for the original data object10.

Following receipt of the original data object10, the process of assigning metadata101,102,103,104information begins. The metadata101,102,103,104defined for the data object10depends on the type of application. For example as discussed herein, an application may be that in laboratory management for the life sciences. On an abstract level, the application will define a plurality of metadata indices101,102,103,104to be assigned to all data objects10.

In many cases, the assignment of metadata indices101,102,103,104will be able to be determined by software applications. Since the data is contextual, the application can be made aware of the context, and update context as conditions change. For example, some metadata indices101,102,103,104will be determined by processing conditions, time of day, personnel logged in, or previous data objects111themselves.

A type of metadata will determine the underlying organizational principle for each metadata index. As the indices are defined101,102,103,104they are either appended to the data object10through XML techniques, and/or entered as index fields101′,102′,103′ in a relational database128. Such databases can contain both the processed data object111, with all its auxiliary fields11, and the metadata indices themselves.

With reference toFIG. 2, and using three dimensions in this example, we see the data object111aoriented visually in space. At this point there has been an assignment of metadata dimension101, as well other the other two dimensions102,103. Later a second data object111bis similarly oriented. Since the Metadata Indices are not the same as relational database indices (although they sometimes can be), there is no requirement to avoid overlap of data objects111a,bin space, or to select a unique data object at each location.

The completed data object111contains within it the original source10information from the original application. For instance, if a microscope image or audio recording was the source of the data object10, a file in native format (perhaps .jpg and .mp3 respectively) would be incorporated in the data object10. Optionally, validation information11such as a hashing function (e.g. SHA-1), signature, and security information should be included. The metadata indices themselves are also included so that the exported data object retains its context and can be re-imported to the same location in ‘N’ dimensional space104.

With reference toFIG. 3, a preferred embodiment uses three phases to move a data object111from its source10to its location and storage in the ‘N’ dimensional space101-104. The phases are 1st, accept the processed data object111and derive its context127, for each dimension101,102,103,104; 2ndusing the appropriate metadata organizing model120encode the dimension as a linear location along that axis101-103. This is to be aided by a plurality of metadata organizing models120shown as examples121-126. And 3rd, storage of the final data object111in ‘N’ dimensional space101-104using a relational128or object oriented database.

At an initial set up time, when a system embodying the invention is configured, the dimensions101,102,103,104for the application will be established. An example application is provided herein. Many metadata organizing models120are possible. Set up involves defining the dimensions101,102,103,104, the metadata organizing model120for each dimension, and defining rules for the derivation of contextual information127.

Since metadata organizing models120are not limited to traditional indices101′,102′,103′ in a relational database128, they may be more complex, and possibly ambiguous from a database administration perspective. The models120provided herein are the basis of the applications that have been applied to this invention, but are not the only possibilities.

In a continuum model121, it is assumed that the dimension may be defined as a continuous variable and represented as a floating point number. This would be the case when the dimension represents an infinitely variable amount. The best example is the continuous flow of time. Since time is a universally applicable dimension for recorded information we would expect it to be used in most if not all embodiments of this invention.

The Discrete Model124uses a finite number of discrete bins to locate a data object along one of its dimensions. This is similar to a unique integer index, but again is not required to select a single unique data object. Barcodes using numeric identification, as is commonly applied to inventory and warehouse management, are a typical example. The resulting index on the barcode dimension, using a discrete model would allow a plurality of data objects111to be associated with a single barcode, which is the desired outcome.

Hierarchical Models122,125provide a powerful means of organizing many kinds of information in a parent-child (e.g.122a-122b) type of relationship. These can be used to manage organizational charts for example. They also have good effect in creating data structures to represent version and revision control schemes in document management, managing recipes, protocols, and formulations in research applications, or a genus and species groupings in the life sciences. The implementation of these types of data is performed with external data structure outside of a simple linear table based relational database128. A first lookup finds the location in a node table, and a primary data object111database is linked to that location.

A preferred embodiment defines strict122and loose125hierarchy separately, as their implementation is somewhat different. Strict hierarchy122requires all nodes to be connected to a single parent node (e.g.122a), and prohibits loose nodes (e.g.125b) that are not connected anywhere. Dimensions defined this way, for example, can represent locations and each location can be broken down into sublocations, any number of times.

Further, loose hierarchy125allows unconnected nodes125band nodes with perhaps multiple connections125a. This model125is useful in less rigorous designs, or where physical reality will not allow for a strict hierarchy122. An example would be the use of bottled reagents in a laboratory setting. An aliquot from one reagent bottle might need to be combined with a second, and then diluted with a third, which would yield a node with three parents. Protocol management is also a loose hierarchy125, where the document defining steps in an experiment might be subject to revision (creating a new child node) or combined with another (creating multiple parents). Where research information is unknown, orphan nodes125b(no parents) are required and the loose hierarchy model125can be used in this case.

Two additional models123,126are discussed which may be less common. Other models can be accommodated in this invention, and are likely to be encountered in new applications. In Hashing123, some information in the data object111is used to create an abbreviated representation of the object. This is useful in generating metadata indices101,102,103,104from large, or complex data sets. An example might be a software signature derived from an image or recording. If the hashing function123is designed correctly, similar data objects111will create similar hash outputs, with the results that searching and indexing is how possible. Long passages of text can be processed in a similar manner. Hashing11is also used herein to provide a desired level of security for data object10, ensuring that it has not been modified from receipt, however the hashing metadata index model is a different use of the same idea.

Still further, groupings126allow data objects111to be thought of as sets and subsets, as in a Venn diagram. Example applications encountered in life sciences applications include a definition of research targets (diseases) by types and categories. Another example is the grouping126of research outputs by type, as in microscope images, chromatograph measurements, audio annotations, mass spectrometry output, lab notebook pages, drawings and diagrams, and the like.

Deriving context127involves the use of information that is available to the system, or otherwise information that is contained in the current and related data objects111, and occasionally input from a user. Further, it may be occasionally worthwhile to allow the system to require that the user provide missing contextual information before a data object111can be stored.

Additionally, data objects111not only need to be oriented according to multiple dimensions101-104they also can provide the orientation. Where, for example, protocols135only change occasionally, a new protocol record as a data object135will supply the protocol dimension135for subsequent objects. Similarly for personnel, and physical location, simple rules can be established that allow the contextualization of all received data objects111. Where this is not possible, the system can make inquiries of the user, and provide powerful tools to assign metadata in each of the required dimensions101-104.

InFIG. 4, we provide an example400of the use of the invention in a a particular application. In the preferred embodiment400, the system is being used to manage intellectual property created by R&D in a biological laboratory of a pharmaceutical company. In this environment, numerous systems already exist which create data objects111. They may include physical systems such as paper based laboratory notebooks142, as well as software applications. Recently, more and more instruments136are being integrated into a computing network, but information has not been optimally organized.

At an initial set-up, the dimensions131-142to be used were defined. It is desirable that new dimensions104can be added in the future. Along with the dimension, for which there can be an unlimited number, the set-up also defined the metadata model120to be used for each dimension131-142, and a set of rules for deriving the context127of a data object in relation to each dimension.

In this environment, data objects111are continually received. In application, one or more software agents are used to collect these objects. Sometimes they appear as files in computer directories, sometime as serial information on the network or computer I/O ports, and sometime as database entries created by a dedicated software program.

New data objects111are processed by the system, converted to a unified XML format, oriented in the multiple contextual dimensions131-142, and stored in a database (or group of databases in a remote mass storage device). A primary function of this invention is the orientation of the data object111in multidimensional space131-142according to the needs of the application.

Dimensions131-142in a biological research laboratory include, but are not limited to the following:

1. Research Program131: the title of the research program, probably related to the funding authority in an accounting sense. Research programs131can be organized in the loose hierarchy model125so that subtasks and subprograms can be easily represented. Queries directed to a research program131can return all the subtasks accordingly.

2. Consumable Media132: often used in large laboratories, particular media can be tracked. The media may be slides, plates, tubes, or various glassware. The purpose of tracking media is not necessarily related to the usage of the media itself, but is to identify a particular sample in an experiment. Barcodes are often available to uniquely identify media.

3. Personnel Responsible133: the researcher can be identified, or numerous assistants to the researcher can be queried independently or as members of a team.

4. Physical Location134: modeled as a strict hierarchy122, the physical location can be assigned as geography-facility-lab-bench-drawer, in order of decreasing size. Location134can be defined as tightly as necessary, or as provided by ah inventory management system. Location134can further be associated with fixed laboratory equipment, or be independent for some instruments.

5. Protocol in Effect135: the protocol for an experiment is extremely important in collecting enough information to make the experiment repeatable. Protocols are sometimes managed by separate software applications, as in work instructions, or Standard Operating Procedures (SOPs) in a validated environment. Where they135are so managed, a new or changed protocol can appear to the system as a data object111.

6. Instrumentation Used136: each instrument in the lab, whether a source of data objects111or not, has an identification and other parameters associated with it136. In many cases calibration records are produced, and the state of the instrument is itself a source of a data object111. Repeatable experiments may be related to the calibration and setup of the instrument136, and these data objects may be recorded in this architecture.

7. Disease Focus137: or research focus, this might be used to make information obtained in researching a particular disease comparable across experiments of across the enterprise. For example, an image from a slide might be classified as “blood diseases—hemophilia” using the grouping126capabilities, while the experiment itself might be related to cell counts.

8. Genus & Species138: where a data object111is related to a sample obtained from a specific organism, this dimension allows it to be organized. A future query regarding the use of that species across many experiments can then be performed. For example: Report all Media Type: Slides where Disease Focus is “Blood Diseases” and Species is: Mouse; which would return images of blood diseases in mice across the entire enterprise.

9. Reagents139: occasionally, supplies used in experiments need to be tracked, as in a recall, or to search for artifacts of a particular supplier. Software programs commonly exist which track such reagents and supplies, and perhaps automatically reorder when supplies are low. They also maintain inventories of supply closets, storage locations, and freezers. Data objects111may further comprise these transactions which can orient related and timely to other data objects111in this dimension139.

10. Timestamp140: a continuous dimension based on the time of origin of the data object111.

11. Time Consumed141: information based on the duration of processing in an instrument136, or the time consumed in a time and attendance system for accounting purposes. Both allow the query of interesting information, for example: reporting all experiments involving a certain cell culture with less than a 200 hour incubation time; or how much time have we charged to experiments in a particular research program this month.

12. Laboratory Notebook Page142: whether managed in a paper or electronic lab notebook, references to the researcher's notes and annotations are important. For a given researcher working under a specified protocol135, the notebook page (scanned as an image) is a data object111that can orient many other data objects111. The traditional Lab Notebook with pasted instrument outputs can be replaced with data objects where related data objects can be assigned, either automatically or manually to the notebook page.