Sign In to Follow Application
View All Documents & Correspondence

Metadata Versioning

Abstract: Systems and method of creating and maintain metadata versions are described. In one embodiment, the method comprises capturing at least one metadata update from a source system. The at least one metadata update includes at least transformed portion of metadata. Further, the method comprises comparing the at least one metadata update with a recent metadata version in a centralized metadata repository to determine a type of metadata update. The type of metadata update is one of addition of metadata and modification of metadata in the source system. Based on the comparing, a metadata version in the centralized metadata repository is created.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
29 December 2011
Publication Number
27/2013
Publication Type
INA
Invention Field
COMPUTER SCIENCE
Status
Email
Parent Application

Applicants

TATA CONSULTANCY SERVICES LIMITED
NIRMAL BUILDING, 9TH FLOOR, NARIMAN POINT, MUMBAI 400021, MAHARASHTRA, INDIA.

Inventors

1. KHASHILKAR, KAMLESH
5H89, YANTRA PARK, SUBHASH NAGAR, UNIT VI, POKHRAN ROAD NO. 2, THANE(W) 400 601 INDIA

Specification

FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: METADATA VERSIONING
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman Point, SERVICES LIMITED Mumbai, Maharashtra 400021 India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter, in general, relates to metadata management, and in
particular, to systems and methods for creating and maintaining metadata versions.
BACKGROUND
[0002] In today's dynamic and fast changing business environment, enterprises grow
and change. Generally, various operational systems within the enterprises, such as customer relationship management, finance system, and order management system, running day-to-day business undergo changes. Along with the changes in such operational systems, data within the operational systems also changes and grows. These changes in the data may in turn lead to changes in metadata associated with the data.
[0003] In general, metadata is known as data about data. Metadata typically describes
context, content and structure of the data and their management through the lifetime. Further, the metadata describes how data is defined, added, deleted, moved, and updated in the operational systems. Thus, the metadata is generally used to keep track of the data, its sources, and the transformations that have happened to the data stored in the operational systems. The systems in an enterprise typically store the metadata in a metadata repository, which is a part of the same system. Various metadata items stored within the metadata repository typically changes over time, for example, metadata items can be deleted, added, and modified. In case of such modifications, the metadata within such repository gets modified to reflect the updated/latest metadata.
SUMMARY
[0004] This summary is provided to introduce concepts related to creating and
maintaining metadata versions and concepts are further described below in the detailed
description. This summary is not intended to identify essential features of the claimed subject
matter nor is it intended for use in determining or limiting the scope of the claimed subject
matter.
[0005] In one embodiment, the method for metadata versioning comprises capturing at
least one metadata update from a source system. The at least one metadata update includes at

least transformed portion of metadata. Further, the method comprises comparing the at least one metadata update with a recent metadata version in a centralized metadata repository to determine a type of metadata update. The type of metadata update is one of addition of metadata and modification of metadata in the source system. Based on the comparing, a metadata version in the centralized metadata repository is created.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is provided with reference to the accompanying
figures. In the figures, the left-most digit(s) of a reference number identifies the figure in
which the reference number first appears. The same numbers are used throughout the
drawings to reference like features and components.
[0007] Fig. 1 illustrates a network environment implementing metadata management
system, in accordance with an embodiment of the present subject matter.
[0008] Fig. 1(a) illustrates centralized metadata repository tables storing metadata, in
accordance with an embodiment of the present subject matter.
[0009] Fig. l(b)-Fig. 1(d) illustrate metadata traceability reports, in accordance with
an embodiment of the present subject matter.
[0010] Fig. 2 illustrates a method of creating and maintaining metadata versions, in
accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0011] Conventional techniques of metadata management involve creating a metadata
repository containing large blocks of metadata extracted from various operational systems within an enterprise. However, metadata undergoes transformation or changes over time, for example, metadata can be deleted, added, and modified. Based on such modifications, the metadata within the metadata repository is modified to reflect the updated/latest metadata. For example, in case of addition, new metadata is added to the metadata repository. In case of deletion, specified portion of the metadata is deleted from the metadata repository, and in case of modification/editing, specified portion of the metadata is overwritten in the metadata repository. Thus, previous changes in the metadata are lost, and tracking entire history of changes in the metadata is not possible.

[0012] In certain cases, user may need to review older items for auditing purposes,
such as anti-fraud investigations, identify timeline of a given item as the item is added, changed, and deleted, which is often used for time-series analytics. Further, when quality problems emerge, user may wish to roll back to earlier changes. Since the conventional systems does not maintain all the versions of metadata, tracking older items, identifying timelines of the items, roll back to previous changes cannot be accomplished using such conventional techniques.
[0013] In accordance to the present subject matter, systems and method for creating
and maintaining metadata versions are described, which facilitates tracking of the metadata versions. In one implementation, a centralized metadata repository is created. Further, metadata from various source systems within an enterprise are obtained and loaded into the centralized metadata repository. Such loaded metadata may be referred to as recent metadata or recent metadata version in the centralized metadata repository till any further updated metadata is received into the centralized metadata repository. The source systems referred herein includes, but not limited to, Customer Relationship Management (CRM) system, order management system, finance system, and data warehouse.
J0014] As described previously, metadata keeps on changing dynamically in one or
more of the source systems. Such changes occurring to the metadata are obtained as metadata
updates. These metadata updates can be compared with recent metadata in the centralized
metadata repository. Such recent metadata is hereinafter referred to as recent version of the
metadata. Based on the comparison, kind of changes/transformations occurring in the
metadata are identified and a metadata version is created containing the updated metadata.
Likewise, multiple versions of the metadata are created within the centralized metadata
repository, whenever metadata in the source systems undergoes changes.
[0015] Based on the metadata versions in the centralized metadata repository,
metadata traceability reports can be generated depicting different metadata versions present in
the centralized metadata repository along with their status, creation date, expiry date etc. In
addition, end-to-end changes occurring in the metadata from a first version of the metadata till
recent version of the metadata can also be indicated in the metadata traceability report.
[0016] Thus, the systems and method in accordance with the present subject matter
enables tracking of the metadata versions, thus, enabling users to review older items, identify

timeline of given items as the items are added, changed, and deleted, and implementing roll back to previous changes.
[0017] The manner in which the metadata versions are created, maintained and
tracked shall be explained in detail with respect to the Figs. 1-2. While aspects of systems and methods can be implemented in any number of different computing systems environments, and/or configurations, the embodiments are described in the context of the following exemplary system architecture(s). Furthermore, the present description has been provided with implementations that are specific to certain business functions or certain businesses. It would be appreciated that other implementations are also covered without deviating from the scope of the present subject matter.
[0018] Fig. 1 illustrates a network environment 100 implementing a metadata
management system 102, in accordance with an embodiment of the present subject matter. In one implementation, the network environment 100 can be a public network environment, including thousands of personal computers, laptops, various servers, such as blade servers, and other computing devices. In another implementation, the network environment 100 can be a private network environment with a limited number of personal computers, servers, laptops and other computing devices.
[0019] The metadata management system 102 (hereinafter referred to as system 102)
is communicatively connected to a plurality of source systems 103-1, 103-2...103-N, collectively referred to as the source systems 103 and individually referred to as a source system 103, through a network 106. The source systems 103 may include various enterprise management systems, such as customer relation management (CRM) system, order management system, finance system, data warehouse, and a reporting system. It is well appreciated that such source systems 103 may have certain specific roles to perform within an enterprise, and data keeps on travelling across these source systems 103 within the enterprise. In the context of the present subject matter, such source systems 103 are indicated as different sources of data transformations and changes.
[0020] Further, the system 102 is communicatively connected to a plurality of user
devices 104-1, 104-2...104-N, collectively referred to as the user devices 104 and individually referred to as a user device 104, through the network 106. In one implementation, a plurality

of users, such as business users, IT users, and database administrator (DBA) may use the user
devices 104 to communicate with the system 102 for tracking versions of the metadata.
[0021] The system 102 and the user devices 104 may be implemented as any of a
variety of conventional computing devices, including, servers, a desktop personal computer, a
notebook or portable computer, a workstation, a mainframe computer, and a laptop. Further,
in one implementation, the system 102 may itself be a distributed or centralized network
system in which different computing devices may host one or more of the hardware or
software components of the system 102. In another implementation, the various components
of the system 102 may be implemented as a part of the same computing device.
[0022] The system 102 may connected to the user devices 104 over the network 106
through one or more communication links. The communication links between the system 102 and the user devices 104 are enabled through a desired form of communication, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[0023] The network 106 may be a wireless network, a wired network, or a
combination thereof. The network 106 can also be an individual network or a collection of many such individual networks, interconnected with each other and functioning as a single large network, e.g., the Internet or an intranet. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), etc., to communicate with each other. Further, the network 106 may include network devices, such as network switches, hubs, routers, for providing a link between the system 102 and the user devices 104. The network devices within the network 106 may interact with the system 102 and the user devices 104 through the communication links.
[0024] In one implementation, the system 102 obtains metadata from various source
systems 103, and loads the metadata into the centralized metadata repository 108. Such loaded metadata in the centralized metadata repository 108 may be referred to as one version of the metadata. Accordingly, the system 102 may assign a start date, an end date, and a status flag

to such metadata version. The start date may be an effective date of creation of the metadata
version, the end date may be date of expiry of the metadata version, and the status flag may
indicate current status of the metadata version, for example, old or latest.
[0025] The centralized metadata repository 108 described herein can be either be
implemented as an external repository (as shown in the figure) associated with the system 102, or an internal repository implemented within the system 102. In one implementation, the metadata stored in the centralized metadata repository 108 is in form of relational database tables.
[0026] As indicated previously, the metadata within the source systems 103 undergo
transformations or changes. Such transformations that can happen to the metadata may include attribute changes and relation changes. The attribute changes may include changes in different types of metadata attributes, such as changes in length, data type, value list, different descriptions, and primary key indicator. While the relation changes may include changes in different types of metadata relations, such as changes in metadata lineage, related terms, related documents, and attributes of relations.
[0027] It is well appreciated that within an enterprise, the metadata may be defined at
different levels of abstraction. The different levels of abstraction may include an element level, an entity level, and an area level. Out of these different levels of abstraction, the area/functional level of abstraction is the highest level of abstraction and the element level of abstraction is the lowest level of abstraction. While, the entity level of abstraction is considered as an intermediate level of abstraction. The area level of abstraction may include different areas within the enterprise system, such as modules of operational systems, Extraction, Transformation, and Loading (ETL) category, data warehouse (DW) schema, report category, and various other business areas. The elements level of abstraction includes various elements like source column, transformation, data warehouse column, in/out parameter, and business terms.
[0028] In one implementation, the metadata obtained from the source systems 103
includes technical metadata. The technical metadata may be understood as the metadata relating to objects in IT systems, such as tables, reports, and data interfaces, technical elements, such as columns and fields.

[0029] Once the metadata is loaded into the centralized metadata repository 108,
changes may occur in the metadata stored in the source systems 103. In order to track the changes in the metadata, the system 102 receives updated metadata in form of metadata updates. Upon receiving the metadata updates, the system 102 processes the metadata updates to create and maintain various metadata versions, in order to facilitate easy tracking of the metadata. For this purpose, the system 102 includes one or more processor(s) 114, a memory 118 coupled to the processor(s) 114, and interface(s) 116. The processor(s) 114 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 114 are configured to fetch and execute computer-readable instructions and data stored in the memory 118.
[0030] The interface(s) 116 may include a variety of software and hardware
interfaces, for example, interface for peripheral device(s) such as a keyboard, a mouse, an external memory, a printer, etc. Further, the interface(s) 116 may enable the system 102 to communicate over the network 106, and may include one or more ports for connecting the system 102 with other computing devices, such as web servers and external databases. The interface(s) 116 may facilitate multiple communications within a wide variety of protocols and networks, such as a network, including wired networks, e.g., LAN, cable, etc., and wireless networks, e.g., WLAN, cellular, satellite, etc.
[0031] The memory 118 may include any computer-readable medium known in the art
including, for example, volatile memory, such as static random access memory (SRAM) and
dynamic random access memory (DRAM), and/or non-volatile memory, such as read only
memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and
magnetic tapes. The memory 118 also includes modules 120 and data 128.
[0032] The modules 120 include routines, programs, objects, components, data
structures, etc., which perform particular tasks or implement particular abstract data types. The module 120 further includes a versioning module 122, a traceability module 124, and other module(s) 126. The other module(s) 126 may include programs or coded instructions that supplement applications and functions on the system 102, for example, programs in the operating system.

[0033] The data 128, amongst other things, serves as a repository for storing data
processed, received, and generated by one or more of the modules 120. The data 128 includes metadata update(s) 130, metadata traceability report 131, traceability rules 132, and other data 133. The other data 133 may include data generated as a result of the execution of one or more modules in the other module(s) 126.
[0034] In operation, the versioning module 122 within the system 102 captures the
metadata updates 130 from the source systems 103. In one implementation, the versioning
module 122 receives the metadata updates 130 from the source system 103. For example, the
source systems 103 may be equipped with one or more modules capable of providing the
metadata updates 130 to the system 102 upon detecting the changes in the metadata stored
within the source systems 103. In another implementation, the versioning module 122 may be
configured to extract the metadata updates 130 from the source systems 103.
[0035] In both the implementations, the versioning module 122 may either captures
the metadata updates 130 in real-time, i.e., as soon as transformations in the metadata contained within the source systems 103 occurs, or at predefined time intervals, for example, at the end of the day. Further, the captured metadata updates 130 may either include entire metadata within the source systems 103 containing the updated metadata data, or only transformed or changed portion of the metadata.
[0036] Subsequent to receiving the metadata updates 130, the versioning module 122
compares the metadata updates 130 with recent metadata version 110 within the centralized metadata repository 108 to determine type of transformation occurred in metadata, which is hereinafter referred to as type of metadata update. Further, the versioning module 122 may also determines the transformed portion of the metadata, when entire updated metadata is obtained from the source systems 103, containing both transformed portion and non-transformed portion of the metadata.
[0037] The different types metadata updates referred herein may include addition of
new metadata, modification/editing of the pre-existing metadata, and deletion of the preexisting metadata. Depending upon the type of metadata update, the versioning module 122 may create another metadata version 110, or modify pre-existing metadata version 110 in the centralized metadata repository 108.

[0038] In one implementation, when the type of metadata update is addition of the
metadata, the versioning module 122 creates a new version of the metadata containing metadata stored in the previous metadata version 110 and the added metadata. Such newly created metadata version may be henceforth referred to as recent version of the metadata until another metadata version is created. Subsequent to creating the metadata version 110, the versioning module 122 assigns a start date, an end date, and a status flag to the newly created metadata version 110.
[0039] The start date of the metadata version may include an effective date of creation
of the metadata version 110. The end date of the metadata version 110 may include a date of expiry of the metadata version 110. For example, a recent metadata version 110 expires as soon as a new metadata version 110 is created in the centralized metadata repository 108. In case of the recent version of the metadata, the versioning module 122 may assign a predefined value to the end date. Such predefined value may be an expected date of expiry of the recent metadata version. The status flag may include current status of the metadata version 110, for example, old or latest. For example, the versioning module 122 may assign a status 'latest' to the recent metadata version 110 in the centralized metadata repository 108. When a new metadata version 110 is created, the versioning module 122 may update the status flag of the previous metadata version 110 to 'old' and assigns the status 'latest' to the newly created metadata version 110.
[0040] In one implementation, when the type of metadata update is deletion of the
pre-existing metadata version 110, i.e., when metadata is deleted from the source system 103,
the versioning module 122 overrules the delete action by an update action. In other words, the
versioning module 122 updates the end date of the pre-existing metadata version 110, and sets
the status flag of the pre-existing metadata version 110 to 'deleted1, rather than actually
deleting such metadata version 110 from the centralized metadata repository 108.
[0041] In one implementation, when the type of metadata update is modifications in
the pre-existing metadata version 110, the versioning module 122 creates a new version of the metadata containing metadata stored in the previous metadata version 110 and the transformed or modified metadata. In said implementation, the modifications may include modifications in the metadata attributes and/or metadata relations. Subsequent to creating the

metadata version 110, the versioning module 122 assigns a start date, an end date, and a status flag to the newly created metadata version 110.
[0042] As described previously, the versioning module 122 can be configured to
capture the metadata updates 130 from the source systems 103 in real-time. Alternatively, the
versioning module 122 can be configured to capture the metadata updates 130 periodically
after a predefined time interval. Accordingly, the versioning module 122 creates new versions
of the metadata or modifies pre-existing versions of the metadata in the real time or at the
predefined time intervals. Thus, the centralized metadata repository 108 contains the metadata
versions 110, which are generated as the results of metadata changes occurring in the source
systems 103 from time to time, enables maintenance and tracking of changes in the metadata.
[0043] Fig. 1(a) illustrates the manner in which metadata is stored in the centralized
metadata repository 108, according to an embodiment of the present subject matter. In said embodiment, the metadata versions 110 in the centralized metadata repository is stored in form of relational database tables including metadata attributes table 134 and metadata relation table 136.
[0044] The metadata attributes table 134 stores objects and accompanied by their
corresponding description and attributes. While, the metadata relation table 136 stores objects and information about relationship between the objects. As shown in the Fig. 1(a), the metadata attributes table 134 includes metadata attributes, such as an object level 134-1, object name 134-2, an attribute 134-3, a start date 134-4, an attribute value 134-5, an end date 134-6, and a status flag 134-7. The object level 134-1 is indicative of the level of abstraction at which object is defined, such as entity level and element level as described previously. The object name 134-2 indicates name of the object stored metadata attributes table 134. The attribute 134-3 includes the attribute of the object. The start date 134-4 indicates time and date of creation of the metadata. The end date 134-6 is time and date of deletion of the metadata. For the recent version of the metadata within the centralized metadata repository, the versioning module 122 may assign a predefined value to the end date, for example, a future date on which the metadata version is expected to expire. The attribute value 134-5 indicates value assigned to the attribute of the object. The status flag 134-7 indicates the current status of metadata version. For example, the status flag 134-7 may indicate whether the metadata version is an old version or a recent/latest version.

[0045] Further, as shown in the Fig. 1(a), metadata relation table 136 may include
objectl level 136-1, objectl name 136-2, object2 level 136-3, object2 name 136-4, relation
type 136-5, start date 134-4, relation description 136-6, remark 136-7, end date 134-6, and
status flag 134-7. As indicated previously, the objectl name 136-2 and the object2 name 136-
4 are the name of two different objects. The objectl level 136-1 and object2 level 136-3
indicates the level of abstraction of respective objects. The relation type 136-5 and relation
description 136-6 provides the type of relation between such objects and description about the
relationship. For example, the type of relation may indicate whether the relation is one-to-one,
one-to-many etc. The remark 136-7 may include additional comments about the relationship
among the objects of metadata. In one implementation, a metadata traceability report 131 can
be generated containing status and details of various metadata versions, and changes occurred
to the metadata. For example, users of the user devices 104 who wish to track or determine
the different versions of the metadata or transformations/changes occurred to the metadata
travelling from one source system 103 to another source system 103 may access a graphical
user interface, say, the interface 116, of the system 102 and specify a search criterion for
generating a customized metadata traceability report 131. Such search criterion may include,
but not limited to, search terms to track only specific metadata versions, selection criterion for
selecting the level of abstraction, transformations, etc., to be displayed in the report,
[0046] In one implementation, the metadata traceability report 131 may be a status
report or search report depicting status information about metadata versions 110 including levels of abstraction at which changes in the metadata occurred, current status of the metadata versions 110, start date, and end date of the metadata versions 110. In another implementation, the metadata traceability report 131 may be a metadata end-to-end lineage report depicting end-to-end lineage of the metadata versions across the source systems 103. In yet another implementation, the metadata traceability report 131 may be a detailed report depicting details of metadata, types of changes or transformation occurred in the metadata, etc.
[0047] Upon receiving the user specified search criterion, the traceability module 124
within the system 102 generates the metadata traceability report 131, based on the user specified/defined criterion and the metadata versions 110 in the centralized metadata repository 108.

[0048] Fig. 1(b), Fig. 1(c), and Fig. 1(d) illustrates metadata traceabiiity reports 131,
in accordance with an embodiment of the present subject.
[0049] As shown in the Fig. 1(b), the metadata traceabiiity report 131 is metadata
status report 131-1 depicting information about metadata versions 110 including levels of abstraction at which changes in the metadata occurred, current status of the metadata versions 110, start date, and end date of the metadata versions 110. In the Fig. 1(b), first row depicts changes in the entity 'crm. customer', having status of the version as 'old', creation date along with the time stamp as 'Ol-Jan-2005' at 11:00AM, and the expiry date as '12-Sep-2010' at 9:59 AM. Further, second row depicts the latest version of said metadata having status as 'Latest', creation date as '12-Sep-20W at 10:00AMand end date as a predefined value '31-Dec-2100' at 11:59PM. The traceabiiity module 124 generates the metadata status report 131-1, based on the predefined traceabiiity rules 132.
[0050] As shown in the Fig. 1(c), the metadata traceabiiity report 131 is a metadata
end-to-end lineage report 131-2 depicting end-to-end lineage of the metadata versions. The metadata end-to-end lineage report 131 -2(a) depicts transformation in the metadata moving from one source system to another source system at an entity level along with metadata versions creation date and the end date. The metadata end-to-end lineage report 13 l-2(a) can be further drilled down to another report, say, the metadata end-to-end lineage report 131-2(b) as shown in the Fig. 1(d), depicting transformation in the metadata moving from one source system to another source system at an element level along with metadata versions creation date and the end date. The traceabiiity module 124 generates the metadata end-to-end lineage report 131-2 based on predefined traceabiiity rules 132.
[0051] In one implementation, the traceabiiity rules 132 include vertical traceabiiity
rules and horizontal traceabiiity rules. The vertical traceabiiity rules track changes in components of metadata within itself at different levels of abstraction. The horizontal traceabiiity rules track changes in components of metadata across the source systems at same level of abstraction. The components of metadata referred herein may include column, tables and attributes.
[0052] Fig. 2 illustrates a method 200 of creating and maintaining metadata versions,
in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer

executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[0053] The order in which the method is described is not intended to be construed as a
limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.
[0054] At block 202, at least one metadata update is captured from a source system in
a centralized metadata repository. In one implementation, the versioning module 122 receives
the metadata update 130 from the source system 103. In another implementation, the
versioning module 122 extracts the metadata update 130 form the source system 103. As
described previously, such metadata update 130 can either be received in real-time or at
predefined time intervals. Further, the metadata update 130 may include either the entire
updated metadata or only the transformed/changed portion of the metadata.
[0055] At block 204, the metadata update is compared with recent metadata in a
centralized metadata repository. In one implementation, the versioning module 122 compares
the metadata update 130 with recent metadata in the centralized metadata repository 108. As
indicated previously, metadata from various source systems 103 can be extracted and loaded
into the centralized metadata repository 108. Since the metadata in the source systems 103
may undergo some change, such changes may be received as metadata updates 130 by the
versioning module 122, and these metadata updates 130 can be compared with recent
metadata in the centralized metadata repository 108 to determines type of metadata.
[0056] At block 206, a metadata version is created based on the comparing. In one
implementation, the versioning module 122 creates the metadata version 110 based on the result of the comparison, i.e., determining the type of metadata update, for example, addition

of new metadata and modifications in pre-existing metadata. Further, the versioning module 122 may assign a start date, an end date, and a status flag to the newly created metadata version 110.
[0057] At block 208, a metadata traceability report is generated. In one
implementation, the traceability module 124 generates the metadata traceability report 131 based on the traceability rules 134. The metadata traceability report 131 may be metadata status report 131-1 depicting information about metadata versions 110 including levels of abstraction at which changes in the metadata occurred, current status of the metadata versions 110, start date, and end date of the metadata versions 110. Further, the metadata traceability report 131 may also be a metadata end-to-end lineage report 131 depicting end-to-end lineage of the metadata versions. The metadata end-to-end lineage report 131 also indicates the transformation occurred in the metadata when moving from one source system 103 to another source system 103 along with metadata versions creation date and the end date. Further, the metadata end-to-end lineage report 131 may also depicts transformations in the metadata at different levels of abstraction, for example, entity level and element level, when moving from one source system 103 to another source system 103.
[0058] The systems and methods of the present subject matter enable creating and
maintaining all the versions of metadata within an enterprise. Thus, metadata changes can be easily tracked. Further, end-to-end transformations occurring in the metadata from one source system 103 to other source systems 103 or the changes occurring to the metadata within the same source system 103 can be tracked and customized reports can be generated. Also, roll back to previous versions of the metadata can be easily performed with the maintained metadata versions.
[0059] Although embodiments for systems and methods for creating and maintaining
metadata versions have been described in language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations for creating and maintaining metadata versions.

I/We claim:
1. A method for creating and maintaining metadata versions, the method comprising:
capturing at least one metadata update from a source system, wherein the at least one metadata update includes at least transformed portion of metadata;
comparing the at least one metadata update with a recent metadata version in a centralized metadata repository to determine a type of metadata update, wherein the type of metadata update is one of addition of metadata and modification of metadata in the source system; and
creating a metadata version in the centralized metadata repository based on the comparing.
2. The method as claimed in claim 1 further comprising creating the centralized metadata repository based on loading metadata, obtained from a plurality of source systems, into the centralized metadata repository.
3. The method as claimed in claim 1, wherein the at least one metadata update is captured from the source system in real-time.
4. The method as claimed in claim 1, wherein the at least one metadata update is captured from the source system after a predefined time interval.
5. The method as claimed in claim 1 further comprising generating metadata traceability report based on metadata versions within the centralized metadata repository, wherein the metadata traceability report is indicative of at least current status, start date and end date of the metadata versions.
6. A metadata management system (102) comprising:
a processor (114); and
a memory (118) coupled to the processor (114), the memory (118) comprising: a versioning module (122) configured to:
compare at least one metadata update (130) obtained from a source system (103) with a recent metadata version (110) in a centralized metadata repository (108), wherein the at least one metadata update include at least transformed portion of metadata; and create a metadata version (110) based on the comparison.
7. The metadata management system (102) as claimed in claim 6 further comprising a
traceability module (124) configured to generate metadata traceability report (131),
wherein the metadata traceability report (131) is one of a metadata status report (131-
1) and a metadata end-to-end lineage report (131-2).
8. The metadata management system (102) as claimed in claim 6, wherein the versioning
module (122) is further configured to:
assign at least a start date, an end date, and a status flag to the created metadata version (110); and
modify at least an end date and status flag of the recent metadata version (110).

9. The metadata management system (102) as claimed in claim 6, wherein the versioning
module (122) is further configured to modify at least an end date of a pre-existing metadata version (110), when the at least one metadata update (130) include deletion of the pre-existing metadata version (110) in the centralized metadata repository (108).
10. A computer-readable medium having embodied thereon a computer program for
executing a method comprising:
capturing at least one metadata update from a source system, wherein the at least one metadata update includes at least transformed portion of metadata;
comparing the at least one metadata update with a recent metadata version in a centralized metadata repository to determine a type of metadata update, wherein the type of metadata update is one of addition of metadata and modification of metadata in the source system; and
creating a metadata version in the centralized metadata repository based on the comparing.

Documents

Orders

Section Controller Decision Date

Application Documents

# Name Date
1 3692-MUM-2011-OTHERS [20-04-2018(online)].pdf 2018-04-20
1 3692-MUM-2011-Written submissions and relevant documents [26-08-2020(online)].pdf 2020-08-26
2 3692-MUM-2011-Correspondence to notify the Controller [27-07-2020(online)].pdf 2020-07-27
2 3692-MUM-2011-FER_SER_REPLY [20-04-2018(online)].pdf 2018-04-20
3 3692-MUM-2011-US(14)-HearingNotice-(HearingDate-11-08-2020).pdf 2020-07-19
3 3692-MUM-2011-COMPLETE SPECIFICATION [20-04-2018(online)].pdf 2018-04-20
4 3692-MUM-2011-CLAIMS [20-04-2018(online)].pdf 2018-04-20
4 3692-MUM-2011-ABSTRACT.pdf 2018-08-10
5 ABSTRACT1.jpg 2018-08-10
5 3692-MUM-2011-CLAIMS.pdf 2018-08-10
6 3692-MUM-2011-POWER OF ATTORNEY(23-2-2012).pdf 2018-08-10
6 3692-MUM-2011-CORRESPONDENCE(10-1-2012).pdf 2018-08-10
7 3692-MUM-2011-FORM 3.pdf 2018-08-10
7 3692-MUM-2011-CORRESPONDENCE(23-2-2012).pdf 2018-08-10
8 3692-MUM-2011-FORM 2.pdf 2018-08-10
8 3692-MUM-2011-CORRESPONDENCE(27-6-2012).pdf 2018-08-10
9 3692-MUM-2011-CORRESPONDENCE.pdf 2018-08-10
9 3692-MUM-2011-FORM 2(TITLE PAGE).pdf 2018-08-10
10 3692-MUM-2011-DESCRIPTION(COMPLETE).pdf 2018-08-10
10 3692-MUM-2011-FORM 18(10-1-2012).pdf 2018-08-10
11 3692-MUM-2011-DRAWING.pdf 2018-08-10
11 3692-MUM-2011-FORM 1.pdf 2018-08-10
12 3692-MUM-2011-FER.pdf 2018-08-10
12 3692-MUM-2011-FORM 1(27-6-2012).pdf 2018-08-10
13 3692-MUM-2011-FER.pdf 2018-08-10
13 3692-MUM-2011-FORM 1(27-6-2012).pdf 2018-08-10
14 3692-MUM-2011-DRAWING.pdf 2018-08-10
14 3692-MUM-2011-FORM 1.pdf 2018-08-10
15 3692-MUM-2011-DESCRIPTION(COMPLETE).pdf 2018-08-10
15 3692-MUM-2011-FORM 18(10-1-2012).pdf 2018-08-10
16 3692-MUM-2011-CORRESPONDENCE.pdf 2018-08-10
16 3692-MUM-2011-FORM 2(TITLE PAGE).pdf 2018-08-10
17 3692-MUM-2011-FORM 2.pdf 2018-08-10
17 3692-MUM-2011-CORRESPONDENCE(27-6-2012).pdf 2018-08-10
18 3692-MUM-2011-FORM 3.pdf 2018-08-10
18 3692-MUM-2011-CORRESPONDENCE(23-2-2012).pdf 2018-08-10
19 3692-MUM-2011-POWER OF ATTORNEY(23-2-2012).pdf 2018-08-10
19 3692-MUM-2011-CORRESPONDENCE(10-1-2012).pdf 2018-08-10
20 ABSTRACT1.jpg 2018-08-10
20 3692-MUM-2011-CLAIMS.pdf 2018-08-10
21 3692-MUM-2011-CLAIMS [20-04-2018(online)].pdf 2018-04-20
21 3692-MUM-2011-ABSTRACT.pdf 2018-08-10
22 3692-MUM-2011-US(14)-HearingNotice-(HearingDate-11-08-2020).pdf 2020-07-19
22 3692-MUM-2011-COMPLETE SPECIFICATION [20-04-2018(online)].pdf 2018-04-20
23 3692-MUM-2011-FER_SER_REPLY [20-04-2018(online)].pdf 2018-04-20
23 3692-MUM-2011-Correspondence to notify the Controller [27-07-2020(online)].pdf 2020-07-27
24 3692-MUM-2011-Written submissions and relevant documents [26-08-2020(online)].pdf 2020-08-26
24 3692-MUM-2011-OTHERS [20-04-2018(online)].pdf 2018-04-20

Search Strategy

1 Search_25-07-2017.pdf