|Publication number||US8019737 B2|
|Application number||US 12/047,704|
|Publication date||Sep 13, 2011|
|Priority date||Mar 13, 2008|
|Also published as||CA2717566A1, CA2717566C, EP2266061A1, US20090234850, WO2009114312A1|
|Publication number||047704, 12047704, US 8019737 B2, US 8019737B2, US-B2-8019737, US8019737 B2, US8019737B2|
|Inventors||Charles F. Kocsis, Pamela V. Bergstrom, Brian Van Pelt, Srinivas Turlapati|
|Original Assignee||Harris Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (15), Non-Patent Citations (2), Referenced by (11), Classifications (6), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates generally to management of data and, more specifically, to the synchronization of metadata.
Various types of businesses or enterprises operate in a computing environment that includes mechanisms for tracking and managing various types of assets throughout the enterprise. As one example, in the broadcast industry, automation or asset management applications can be installed at one or more facility, each of which solutions may store metadata that describes various assets including audio, video or a combination of audio and video content. The assets can include the content or the material physical media on which the content is stored. Each of the asset management applications may utilize a unique subset of metadata or a combination of metadata that may vary from application to application.
Many applications in the broadcast environment are not integrated, or they are loosely integrated in a point-to-point manner. Consequently, users or administrators are often required to enter the same data into multiple applications. In addition to these efforts being duplicative, this also presents the possibility of data entry error. Additionally, there tend to be manually established policies that control circumstances surrounding when multiple applications represent the same information. Such policies are not easily enforced since conflicts for values of data representing content must be resolved manually. Data transfers, if supported, are usually batch-oriented, which often means that many applications do not have the most current information at all times. This can result in erroneous business decisions being made.
Additionally, metadata for a given application can vary according to application requirements and information needed to describe or characterize the content. Continuing with the broadcast example, in certain applications metadata may identify a title or information sufficient to populate an electronic programming guide. In other instances, metadata can provide a complete index of different scenes such as for a movie as well as providing business rules detailing how content package may be displayed, copied or sold. Separate uses of the metadata further may depend on the type of facility or customer that is utilizing the metadata as well as the source of the content and metadata. For example, separate uses for metadata have originated from studios, distribution networks (e.g., cable or satellite) as well as down to consumer premises equipment (e.g., set top boxes, programmable video recorders and the like).
The invention relates generally to a system and method for synchronization of metadata. The synchronization approach enables data that is entered into one application to be published to other applications that represent substantially the same information.
One aspect of the invention provides a system to synchronize metadata for a plurality of applications. The system includes content administration rules programmed to define policies for updating metadata in the master database and policies for propagating updates in the metadata to the plurality of applications. The metadata describes at least one asset represented as data residing in at least one of the plurality of applications. A rules engine is programmed to apply at least a first set of the content administration rules to a metadata record received from a first application of the plurality of applications to control updating corresponding metadata stored in a master database, changes in the corresponding metadata made to the master database being propagated to at least one second application of the plurality of applications according to a second set of the content administration rules predefined for each of the at least one second application and the corresponding metadata.
Another aspect of the invention provides a system for field-level synchronization of metadata for a plurality of applications running in a broadcast or content delivery platform. The system includes a matching engine programmed to detect an occurrence of a match between a metadata record received from a first application of the plurality of applications and corresponding master metadata stored in a master database based on a first set of content administration rules. A rules engine is programmed to control updating the corresponding metadata stored in the master database based on application of a second set of content administration rules to at least a substantial portion of the metadata record received from the first application. The matching engine provides the rules engine with at least a substantial portion of the metadata record received from the first application in response to detecting the occurrence of a match. An update component is programmed to publish updates in metadata records to at least some of the plurality of applications according to updates made to the corresponding master metadata in the master database.
Yet another aspect of the invention provides a method for synchronizing metadata that describes associated data residing in at least two applications and in a master database. The method includes receiving at the synchronization system from a first application a message that includes at least one metadata record. In response to matching the at least one metadata record with a corresponding master record from the master database, a set of content administration rules is applied to control updating metadata in the corresponding master record. Changes in the corresponding master record are published to at least one other application according to applicability rules defined for the at least one other application.
The invention relates generally synchronization of metadata across an enterprise or platform running multiple applications. Associated with each of the applications is metadata. As used herein, “metadata” can refer to any information that describes data representing one or more assets. The type of information will vary according to the context in which the system is utilized. By way of example, and not by way of limitation, many examples are described herein the context of metadata that describes assets in a broadcast environment. In the broadcast context, for instance, an asset can correspond to data that represents content or an asset can correspond to data representing the material or physical medium on which the content can be stored. It will be understood and appreciated that the approach shown and described herein is equally applicable to other contexts (e.g., medical or manufacturing environments).
The approach describe herein employs a set of content administration rules. The content administration rules are established for determining whether synchronization is necessary in response to an identified change in metadata in a given one of the plurality of applications. The change in metadata can be indicated by a message provided from the given application to a synchronization control system. The synchronization system applies the content administration rules to determine whether metadata in the system should be changed based upon the message received. The rules can also be established to define what information is updated and which updates are propagated or published from the synchronization control system to respective applications in the system.
As described herein, the content administration rules can include key field rules, ownership rules, precedence rules and applicability rules that cooperate to control the synchronization process. As a result of applying the content administration rules, the synchronization process is able to align values of the metadata, at the field level, across any number of a plurality of applications according to the enforcement of the established rules.
As will be appreciated by those skilled in the art, portions of the invention may be embodied as a method, data processing system, or computer program product. Accordingly, these portions of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, portions of the invention may be a computer program product on a computer-usable storage medium having computer readable program code on the medium. Any suitable computer-readable medium may be utilized including, but not limited to, static and dynamic storage devices, hard disks, optical storage devices, and magnetic storage devices.
Certain embodiments of the invention are described herein with reference to flowchart illustrations of methods, systems, and computer program products. It will be understood that blocks of the illustrations, and combinations of blocks in the illustrations, can be implemented by computer-executable instructions. These computer-executable instructions may be provided to one or more processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus (or a combination of devices and circuits) to produce a machine, such that the instructions, which execute via the processor, implement the functions specified in the block or blocks.
These computer-executable instructions may also be stored in computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.
Turning to the figures,
Each of the applications 14 and 16 includes respective asset data 18 and 20 that corresponds to one or more (e.g., typically a plurality of) assets. In the context of a broadcast environment, the asset data 18 and 20 can represent a piece of content such as audio, video or a combination of audio and video. Alternatively or additionally, the asset data 18 and 20 may represent a piece of material that physically embodies content (e.g., a tape, a file or other physical media).
Metadata 22 and 24 is associated with each respective asset data 18 and 20 to describe features of the particular asset. The type of information and the format for how it is presented can depend upon the particular application and context in which it is being utilized. As one example, for audio information content, video information content or a combination of audio and visual information content, the metadata employed by a given application 14,16 can vary in depth according to application requirements. For instance, metadata 22 and 24 may identify the content package title or information that is sufficient to populate an electronic program guide (EPG). More complex metadata may include a complete index of different scenes in a movie and/or providing a set of business rules detailing how the content package may be displayed, copied or sold. The metadata 22 and 24 thus can be represented as a set of one or more fields, each field containing a specific unit of information about a given asset represented by the asset data 18 and 20, respectively. The set of fields associated with a given asset data collectively defines the metadata 22 and 24 for the asset represented. The metadata 22 and 24 for a given asset may be fixed. Alternatively, the metadata 22 and 24 for a given asset or type of asset can be extensible, such as may be established according to evolving industry standards or proprietary data requirements.
One example of an industry standard that is ongoing and developing is the broadcast exchange format (BXF) that has been developed by the Society of Motion Picture and Television Engineers (SMPTE) according to the work of the S22-10 Committee. The standards being developed by this committee are incorporated herein by reference. It is to be appreciated that a richer set of metadata associated with a given asset (e.g., piece of content or material) affords the opportunity for additional services to be provided to customers and other users of such information.
As a further example, for a content asset in a broadcast environment, the metadata 22 and 24 describes the content by a set of fields that can vary according to the type of content data asset 18 and 20 and the application 14 and 16 by which such assets are utilized. Similarly, for a given material asset, the metadata 22 and 24 can include a set of metadata fields that describe characteristics or properties of the physical material represented by the asset data 18 and 20. The fields of metadata may also be able to establish groups between one or more content assets and the material associated to such content. For instance, a series of a given program, a particular topic, a rights contract for users and similar broad topics can be implemented as metadata fields that can be assigned values to identify a predetermined group or subset of content or material assets. Additional content metadata fields may includes various other fields that can be utilized to express content metadata and material metadata.
Examples of some fields that can be utilized as metadata to describe general information for broadcast content assets are provided in
Examples of same fields that can be provided as metadata to describe general information for material assets in a broadcast context are provided in
Each of the applications 14 and 16 can communicate with the synchronization control system 12 through the associated network depicted at 26. The network 26 may include a local area network, a wide area network or a combination of network types. The network 26 may include physical connections, wireless connections, or a combination thereof. Communication between the applications 14, 16 and the synchronization control system 12 is facilitated by the platform processes running in the system 10. For example, each of the applications 14 and 16 may subscribe to a particular form of content delivery process that is also employed by the synchronization control system 12.
In the example of
As a further example, the messaging agent 28 can receive a message from the network 26, process the message and extract appropriate data from such message to enable the metadata synchronization to be performed according to an aspect of the invention. Those skilled in the art will understand and appreciate various types of content delivery mechanisms and messaging protocols that may be utilized as an underlying communication system to enable messages relating to the metadata to be transmitted between applications 14 and 16 and the control system 12. One example of such a content delivery mechanism is the content delivery system implemented in the H-Class Enterprise Management system that is available from Harris Corporation of Melbourne, Fla.
Each of these applications 14 and 16 also includes an interface (IF) 34 and 36. Such interfaces 34 and 36 can be utilized by a user of an application to add, delete, or update one or more fields in the metadata 22 and 24 that is associated with a given asset 18 and 20. The messaging component 30, 32 sends a corresponding message to the synchronization control system 12 in response to the metadata being added, updated or deleted. The communication implemented by the messaging component 30, 32 can be considered real time messaging or it can be implemented and occur at predetermined intervals depending upon application requirements. As described herein, the messaging between the applications 14 and 16 and the control system 12 can be implemented as an underlying or background process by the messaging components 30 and 32.
By way of further example, each of the applications 14 through 16 may perform different functions in the overall system 10. For example, one application may be an ingest application in which a user enters information about a given asset. The information may be entered manually through the interface 34 in response to a user input. Alternatively or additionally, information can be generated by a service to which the owner of the system 10 may subscribe and automatically be entered into the application 14 via the interface 34. For example, data services exist that routinely provide information in a defined format to facilitate entry of detailed information about a given piece of content or material.
Another of the applications 16 may include traffic and scheduling applications or other business applications associated with the assets and their delivery and use within the system 10. Still another type of application for the media industry may include an automated system that executes or plays out the scheduling as defined by other application(s) that performs and controls the scheduling. Those skilled in the art will appreciate various other types of applications that may be utilized and implemented in the system 10, which further may vary depending on the type and purpose of the system.
It will be appreciated that each of the applications 14, 16 or at least some of them may have different rules or requirements about what types of metadata must be provided in order to process the asset and metadata for the given application requirements. Because of the different application requirements, metadata in one of the applications may become out of sync with respect to metadata for the same asset in a different application. Thus, the synchronization control system 12 is programmed to follow a set of policies or rules that are automatically enforced to ensure the values of metadata fields are appropriately synchronized on an application-by-application basis. As a result, potential conflicts where two or more applications represent same information different can be easily resolved on a real time or near real time basis. Consequently, each of the applications 14 through 16 that are connected in the system 10 can have the most accurate and up-to-date metadata information for content assets and material assets within the system 10.
The synchronization control system 12 includes content administration rules 40 that define a set of policies to control synchronization of metadata and distribution of metadata in the system 10. The content administration rules 40 can be programmed to provide for field-level synchronization of the metadata in the system 10. The synchronization control system 12 also manages master metadata 42 for the system 10 according to the established content administration rules 40. The master metadata 42 is a data structure (or structures) that comprises a complete set of metadata records that represents a most accurate and complete set of metadata for all assets defined within the system 10. While the master metadata record 42 is depicted as residing within the synchronization control system 12, it will be understood and appreciated that such data may be stored in one or more memory structures in the system 10 that may be accessible, locally or remotely, by the synchronization control system 12.
The content administration rules 40 can include a set of ownership rules that determine if a detected change in metadata made by a given application should be propagated to one or more other applications 14-16 in the system 10. For instance, if an application is not an owner of a field of the metadata and a change is made to such a field by the application, the change is not propagated to other applications nor is such change saved in a master metadata structure 42 residing in the system 10. Additionally, the synchronization control system 12 (or an associated process) can keep track of occurrences for out of sync conditions when a non-owning system makes a change. For instance, the change can be utilized to trigger a manual oversight or to keep empirical or statistical data about the synchronization for the various applications running in the system 10.
The content administration rules 40 may also include precedence rules that are used to determine a priority among the applications 14-16 for establishing the master metadata record 42. Thus, the precedence rule can be programmed to establish a ranking or precedence among the applications 14-16 corresponding to a relative importance of the metadata for each of respective applications. The synchronization control system 12 can employ the precedence rules to determine which changes in a metadata record by a given application are written to the master metadata 42.
Another set of content administration rules 40 may include applicability rules. The applicability rules establish a relevance of each of the metadata fields to each of the plurality of applications 14-16. Applicability rules can be used to determine which metadata fields each respective application is to receive updates, additions or deletions of information. For instance, the applicability rule can establish policy for each given application 14-16 concerning what metadata updates the application “cares” about. A value of an applicability rule for a given metadata field thus may take on three discrete meanings for each application: (1) that an application must receive an update to this metadata field; (2) that an application can receive an update to a given metadata field and (3) that a given application must not receive an update to a given metadata field. Different sets of applicability rules (e.g., rule profiles) further may be established for each application 14, 16 depending on whether fields are being updated, added or deleted from a metadata record. It will be understood and appreciated that certain of the applicability rules may be distributed to the applications for enforcement, applicability rules may be maintained at the synchronization control system 12 or the applicability rules may be distributed across the applications and the synchronization control system.
Another set of the content administration rules 40 may relate to matching rules, which includes a set of key fields. The key fields can be utilized to identify one or more key fields of metadata that are compared relative to corresponding metadata fields in the master metadata 42 to determine if a record (or records) in a received message matches an existing piece of content or material in the master metadata 42. A matching engine 44 thus can utilize the key fields for a given content as part of a matching algorithm to determine whether a match exists. If a match does not exist, the content or material can be identified as a new piece of content or material, which can be added to the master metadata record 42. Alternatively, or additionally, if no match is found in response to receiving such a message, an alert or other information can be provided to a user to implement manual controls associated with processing of the new information.
The matching engine 44 is programmed to return a master content record from the master metadata 42 based on the matching criteria contained in the content administration rules 40. As one example, based on the set of predefined matching key fields, the matching engine 44 can formulate an Xpath query to search for key fields in a raw message from one of the applications 14, 16 and extract corresponding values of such fields. Assuming that a key field match is found with the master record, the values of the fields in the received message are compared with the values of such fields in the master metadata record 42. The results can be stored in a fast retrieval data structure to facilitate subsequent processing. Those skilled in the art will understand and appreciate various string matching algorithms that can be utilized, such as including the Boyer-Moore algorithm. If each of the key fields is a match with the master data record or a match is otherwise detected, the matching engine 44 sends the received record to a field synchronization engine 46.
It will be understood and appreciated that the content administration rules, in particular the key field rule set, may include weights associated with respective fields, such that a partial match may be sufficient to enable the synchronization engine 46 to process a received message. The key field or matching rule set of the content administration rules 40 can be programmed to establish one or more thresholds for use by the matching engine 44. The matching engine 44 may employ one or more threshold values to identify a partial match if the formulated weighted value exceeds the predefined threshold. Thus, if the matching engine 44 determines a match, including a full complete match or a partial match (based on the defined thresholds), the synchronization engine 46 performs an automated synchronization process for the record in the received message and corresponding matching record in the master metadata 42.
The synchronization module 46 is programmed to perform field-level synchronization of metadata based on the results from the matching engine 44. The field synchronization process is performed according to at least a portion of the content administration rules 40. In particular, the synchronization is performed according to preprogrammed ownership rules and precedence rules. For example, the synchronization engine 46 applies a set of precedence rules to ascertain a field-level precedence for matched fields relative to the respective metadata fields in the master metadata record 42. In this way, an application having a lesser or lower precedence for a given field will not overwrite an existing field in the master metadata record 42 that has been set by an application having a higher or greater precedence.
The synchronization engine 46 also applies a set of ownership rules to determine whether an application that provided the message is defined as an owner of the field or fields for being added or for which an update has been requested. An application who is not an owner cannot modify or change a content field in the master metadata record 42, even if such changes are made locally at the respective application. Additionally, since the changes are not made to the master data record, such changes (by a non-owner application) will not be propagated to other applications in the system 10. It will be understood and appreciated that the synchronization engine 46 may apply the ownership rules and precedence rules in any established order.
Assuming that the field being operated on by the synchronization engine 46 is from an owner application and assuming that the application has precedence over the field(s), the synchronization engine can perform a process to update the metadata fields in the master metadata record 42. When either new fields are added to a master metadata record or if an update to one or more fields has been performed, the synchronization control system 12 employs the messaging component 28 to propagate these changes to the applications 14-16.
The synchronization engine may employ a set of applicability rules, however, to control whether to publish each update to each respective application 14-16. For instance, the applicability rules profile of the content administration rules 40 can be preprogrammed to define a relative importance of each of the metadata fields such as to establish a set of fields the respective application must have updated, a set of fields each application can receive updates, or a set of fields for which each application must not receive in the way of updates. The synchronization engine 46 (or an update process in the synchronization control system 12—not shown) can provide the messaging agent 28 metadata field updates that are to be propagated to each of the applications 14-16 to complete the synchronization process. The messaging agent 28 can publish a unique set of updates to each of the applications 14 through 16 according to the predefined applicability rule profile in the content administration rules 40.
The synchronization control system 12 further can include a synchronization manager 48 that is programmed to provide a user interface to enable an administrator or other user to program the content administration rules 40. The synchronization manager 48 further can be utilized to program the matching algorithm employed by the matching engine 44 to determine the occurrence of metadata field matches. The synchronization manager 48 thus can be utilized to configure various parameters of the synchronization control system 12.
As an example, the synchronization manager 48 may employ a set of graphical user interfaces associated with each content administration profile that can uniquely establish rules, thresholds and weights sufficient to perform the metadata synchronization process. To facilitate programming rules to define the synchronization process associated with each of the applications 14-16 in the system 10, the synchronization manager 48 can group certain subsets of the rules or otherwise enable rules to be set in a batch-type process. Additionally, the synchronization manager 48 may be utilized when the synchronization system 12 is first installed and utilized in a respective enterprise to perform a mass or global synchronization of metadata in the system 10. Default rules may be also be established a priori and applied to facilitate the administrative task of setting the rules. After an initial configuration and setup, the synchronization control system 12 can run automatically in a real-time or near real-time manner as described herein.
The synchronization control system 12 can also be programmed to detect if metadata within the system 10 becomes out of synchronization. In response to detecting an out of synchronization condition for one or more application, the synchronization control system can send an appropriate set of updates to return to a synchronized condition. As described herein, rules can be established to determine and control the extent and frequency of such updates.
The management system 100 includes a synchronization manager 104 that is accessible by an authorized user, such as an administrator or other individual. The synchronization manager 104 includes a content administration tool 106 through which the user can configure and maintain the content administration rules profile 102. For example, the content administration tool 106 can include a graphical user interface that provides access to each of a plurality of rule profiles that are utilized in connection with the synchronization process.
In the example of
The rules in the content administration rules profile 102 are applied to establish metadata records for each of a plurality of P assets 116, 118 and 120 stored in a master database 122, where P is a positive integer denoting the number of assets. For instance, each asset 116, 118, 120 includes a master metadata record 124, 126 and 128 that includes a plurality of metadata fields having values established by application of the rules in each of the rule profiles 108, 110, 112, and 114 in the content administration rules profile 102. Examples of some fields that can be established for the assets 116, 118 and 120 are shown and described with respect to
There may be a common set of the rule profiles 108, 110, 112 and 114 that are applicable to all assets or to a subset of the plurality of assets 116, 118 and 120. Alternatively, different sets of rule profiles can be established for different assets, which rules may be applied based upon selected metadata fields for a given asset. A different rules profile can exist for different types of assets, such as may be identified by one or more metadata fields. For example, a given type of content asset may be identified by the value in one or more fields (e.g., a CONTENT ID field, a CONTENT TYPE field), which fields can be utilized to select a particular set of rules to apply during the synchronization process. Those skilled in the art thus will appreciate combinations of fields and rules that might be applicable in variety of circumstances to provide for customized synchronization process based on the teachings herein.
A synchronization engine 130 can employ a selected one of the rules profile 102 by selectively loading the appropriate rules profile based on metadata in the master metadata record for a given asset, based on the metadata fields in the message transmitted to the synchronization system or based on a combination of metadata distributed throughout the synchronization system. In this way, the synchronization engine 130 can employ appropriate content administration rules for the synchronization of metadata. The cooperation between the synchronization manager 104, which sets and defines the content administration rules, and the synchronization engine 130, which applies the rules, further can accommodate varying types of assets and metadata that may change over time.
In the example of
By selecting a given one of the tabs 202, 204, 206 or 208 a corresponding set of fields and applications are displayed with which an authorized user (e.g., an administrator) can program the respective rules for each of the Q fields and each of the R applications. Each of the rules can be programmed individually via the tool 200 such as by selecting an appropriate row and column for a given application. The value of a rule for a given application and field can be a binary value or a string value that may be a variable length. For instance,
As described herein, an owner application is authorized to modify a given field of a master metadata record in response to changes detected in the field at the respective application. Thus, to program the ownership rules profile 220 each application can assigned a value for each field F1 through FQ, which value can simply indicate whether the application is or is not an owner for a given field. Each of the values for a given application or for a given field can be set individually or features may be available to facilitate setting more than one value at a time.
Before the information can be merged together during a synchronization process, the system must provide a way to determine whose information to use for each field to create the master metadata record. The precedence rules thus are programmed to establish what application takes precedence for every field when creating a master metadata record for the synchronization system.
The ranking feature 234 is employed to establish a precedence value for each of the Q fields according to which of the applications has a higher ranking (e.g., designating a priority or importance) associated with each of the respective fields. The ranking can require that each application be assigned a different precedence level or value to ensure proper resolution of precedence. The ranking feature 234 can allow a mass edit so that precedence on more than one field can be set at a time. Additionally, the precedence values for one field can be copied to another field. It will further be appreciated that more than one set of precedence rules can be saved using a precedence profile (e.g., the precedence that needs to be applied during synchronization is different for the different content types as well as material). The precedence GUI 232 can also enable a user to program a plurality of precedence rule profiles 230, such as can vary depending on one or more of the metadata fields in a given record (e.g., depending on the type of content or material that is being synchronized). For example, a precedence profile can be created for each individual content type and each material type of asset within the system.
Those skilled in the art will understand and appreciate that additional applicability rules profiles can be established for other circumstances or conditions that may exist to control when and circumstances associated with propagating metadata to a set of applications. It is to be understood that the applications APP. 1 through APP. R in the example of
The values in the applicability rules profile 240 for each application and each of the respective Q fields thus can include a value (e.g., VxFy, where x and y denote the application and field, respectively) that defines whether a given instance of the application will receive a message that contains a given metadata field, such as to add, modify or delete the field at the application. For instance, the values can represent one of the following: (1) do not receive updates—to indicate that the application is not to receive any changes made to a given metadata field; (2) receive update—to indicate that the application is to receive changes made to this field; and (3) must receive update—to identify that the instance of the application must have information in the field any time it receives an update to an asset and if the data does not exist in the method it is to be retrieved from the master database before the message is forwarded on.
Additionally, separate sets of applicability rules can be established, for example, which can vary depending upon a selected set of one or more metadata fields. For instance, a different set of applicability rules (e.g., a different applicability rule profile) can be applied for a different program content asset versus a commercial content asset. Applicability rule profiles can be created for a variety of other circumstances and be applied based on corresponding combinations of metadata fields. Thus, the content administration tool 200 can include features and functions to assign different applicability profiles to different types of content, such as can be defined by one or more metadata fields. Additionally or alternatively, the applicability GUI further may provide a mechanism to assign unique and separate applicability profiles to each material type so that additions, deletions or updates to metadata fields associated with a given type of material will apply the corresponding set of applicability rules associated with publishing such information to the applications.
The key field GUI 262 can include graphical and/or textual user interface elements programmed to facilitate programming the key fields and other associated matching parameters. For example, the key field GUI 262 can include a content user interface element 266 that can be utilized to establish key field profile for content metadata. As an example, the content element 266 can be utilized to program and establish the content key field profile rules 262 with different sets of one or more key fields for content assets, which rules can vary depending upon the type of content. Similarly, the key field GUI 262 includes the material feature element 268 that enables the user to assign a key field profile to each individual material type that can be identified by one or more material type fields of metadata. The type of content and material, for example, can be defined by a set of one or more content-related metadata fields or material-related metadata fields, respectively. In this way, different key fields can be utilized for matching and synchronization of metadata depending on the type of content or material is indicated in a given record. That is, the key field GUI 262 provides a user the ability to save one or more set of key field rules for an asset using the key field/matching rules profile 260. Those skilled in the art will understand and appreciate various ways to identify and define types of content and types of materials based upon a combination of one or more appropriate fields, and further that the fields may be extensible to identify additional types or categories as may be needed for given application requirements.
To facilitate programming the key field/matching rules profiles 260, the key field GUI 264 further may provide a set of default key fields for various types of content and material assets. Additionally, the key field GUI 264 of the content administration tool 200 further may provide the ability to copy an existing key field profile that can be utilized to populate fields of a new key field profile that can be saved in the system. The key field GUI 264 further permits the user to modify any key fields for a given profile including one that has been created by copying an existing profile.
In addition to identifying key fields for a given profile for each of the respective applications, a weight value can be assigned to the fields in order to specify the relative importance of the respective fields. The weights can be utilized by the synchronization process to ascertain the occurrence of a match. In the example of
The key fields GUI 264 also includes a threshold feature 270 that is utilized for establishing one or more threshold that is employed during a matching process as part of synchronization. The threshold feature 270, for example, can be utilized to establish a value that indicates a likelihood of a match during a synchronization process. As one example, the system can be programmed to recognize that a certain predetermined threshold must be exceeded (e.g., 100) for key fields to be considered to be a match. Where key fields for a given type of content includes multiple fields, the aggregate sum of the weight values for each matching key field can be utilized and compared relative to a corresponding threshold to ascertain whether a match exists or not. Thus, for instance, even if a key field having a highest weight value does not result in a match, if the sum of the weight values for the remaining fields exceeds a predefined threshold for the remaining matching fields, the occurrence of a match still may be detected by the matching engine.
An example of a message 400 that can be provided by an application (e.g., the application 304 of
The synchronization module 302 loads synchronization settings from an associated data store, which settings include content administration rules. As shown in the example of
The synchronization module 302 includes a matching engine 318 that retrieves the content record (or at least a key fields from the content record) stored in the temporary database 312. The matching engine 318 can include a key field extractor 320 that extracts key fields from the content record. The key field extractor 320 can perform the extraction based on key field criteria established in the key field rules 314. The matching engine 318 can also retrieve matching records from a master database 322. The key field extractor 320, for example, can formulate a search query (e.g., an Xpath query) to search for the key fields defined in the key field rules 314. If no match is found, the matching engine 318 can end the matching process and a corresponding record may be returned to the application 304 or other action can be taken. For example, the absence of a match might indicate that the record is a new content record that should be added to the master database 322.
The matching engine 318 also includes a matching algorithm 324 that is programmed to compare the values of the key fields defined by the key field rules relative to corresponding fields in a master record from the master database 322. If the matching algorithm 324 determines that the key fields (defined by the key field rules 314) match the corresponding fields in the master record, the matching engine 318 sends the matching record (or at least a substantial portion of such record) to a precedence/ownership rules engine 326. It is to be appreciated that a match can indicate a partial or complete match for a set of key fields depending upon the weighting values and thresholds defined by the key field rules 314. In this way, the matching algorithm 324 can evaluate whether the sum of the weighted values exceeds a predefined threshold value. If the computed weighted value exceeds the threshold, a match can be identified. However, in a circumstance in which the sum of the weighted value does not exceed the threshold, the record can be discarded or otherwise reported back to the application 304 or it can be provided to manual controls 338 for manual action.
The precedence/ownership rules engine 326 corresponds to a means for performing field synchronization. Such means operates by applying appropriate precedence and ownership rules 316 relative to the fields of the metadata record as provided from the matching engine 318. The processing and comparison can employ a temporary worksheet 328 residing in appropriate memory of the system implementing the synchronization module 302. The temporary worksheet 328 can be populated with fields from the master record, indicated as FIELD1, FIELD2, FIELD3, FIELD 4 through FIELDX, where X denotes the number of fields in the master content record being evaluated.
The rules engine 326 applies the set of precedence rules to determine if the corresponding field values and the temporary worksheet from the master record should be updated based on the value of the field from the content record provided by the application 304. The precedence rule can be applied according to the precedence of the field in the record according to the precedence of the application associated with each of these fields in the master record currently in the temporary worksheet 328. An example of a set of conditions or policies is provided below in the following table, which can control the application of the precedence rules 316 applied by the rules engine 326.
If the app has the highest precedence and its field value is
empty, and if the field value in worksheet is empty, replace
the worksheet value with this value
If the app has the highest precedence and its field value is
empty, and if the field value in worksheet is not empty,
If the app has the highest precedence, and its field value is not
empty, replace the field value in the worksheet with this value
If the app does not have the highest precedence and its field
value is not empty, and if the field value in worksheet is not
empty: If the field value in worksheet is from a lesser
precedence app, replace the worksheet value with this value
If the app does not have the highest precedence and its field
value is not empty, and if the field value in worksheet is not
empty: If the field value in worksheet is from a higher
precedence app, do nothing
If the app does not have the highest precedence and its field
value is not empty, and if the field value in worksheet is empty,
replace the worksheet value with this value
If the app does not have a precedence and its field value is
empty, do nothing
If the app does not have a precedence and its field value is not
empty, and if the field value in the worksheet is not empty, do
The precedence/ownership rules engine 326 can also apply a set of ownership rules to determine whether the application 304 that provided the content record is defined as the owner, thereby having authority to modify a field. The precedence/ownership rules engine 326 can update field values in the temporary worksheet 328 based upon the rules and whether the application is an owner. In one embodiment, a flag associated with a given metadata field can be set to mandate that a certain field cannot be changed even by an owner application. If such a flag is set, then the modified values will not be changed in the temporary worksheet to reflect the content record. The contents of the temporary worksheet 328 corresponding to the resulting record as modified by the precedence/ownership rules engine 326 can be transferred to a temporary master database 330.
An update module 332 can in turn transfer the temporary master database 330 to the master database 322. The temporary master database 330 thus includes a most current copy of the master database, including all fields that have been modified by application of the precedence and ownership rules 316. Thus after completing the field-level synchronization for one or more content record, the temporary database 330 can be rewritten back in its entirety to the master database 322. Alternatively, the database 322 can be designed to enable updating of selected portions of the master database according to the record that is being updated based on the application of the content administration rules. Those skilled in the art will understand and appreciate various types of databases (relational, object, hierarchical and the like), knowledge bases and other structures that can facilitate various types of updating of the master database 322.
The update control 332 can also be utilized to trigger that the update to the record is published to other subscribing applications (not shown) in the system. The publishing of the updated record can be limited on a field basis according to the applicability rules 317 defined for each of the respective applications. For instance, a publish component 334 can generate and send a unique update message 336 to each of the subscribing applications, such as through a messaging controller (not shown) running on the platform. In the event that a new record has been added, the publish component 334 may provide a corresponding message for propagating the new data to each of the respective subscribing applications.
In the event that a partial match or incomplete match is determined by the matching engine 318, the matching engine can provide the record to a manual control process 338. The manual control process 338 can provide an alert to a user so that appropriate manual action can be taken. The partial matching record can also be provided to appropriate storage to facilitate action to be taken. The manual control process 338 may be utilized to force an update to certain metadata fields or, alternatively, other types of intervention can be implemented. For example, an administrator or another authorized user can implement various types of intervention according to system requirements via the manual control process 338. Additionally, such manual intervention may be utilized to pause or temporarily disrupt the synchronization process so that additional maintenance can be performed such as including updating the content administration rules.
As a further example, the manual control process 338 may involve intervention such as may include manual selection and matching. For instance, the manual control process 338 can provide a best guess based on the results from the matching engine 318. If such a match is approved, for example, the corresponding record and fields may be returned to the rules engine 326 for completing the field synchronization process in an automated manner. It is to be appreciated that, the partial matches or other information that may require user intervention can be stored in a queue or other data structure that can be accessed by the administrator or other user on an as needed basis. Additional alerts may be provided to the user to indicate that data has been sent to this temporary data structure.
In view of the structural and functional features described above, certain methods will be better appreciated with reference to
The method 450 begins at 452 in which it has been determined that a change in metadata for an asset has been made at one of a plurality of applications. The change can be adding new metadata, changing existing metadata or deleting metadata, such that the metadata at the application can be considered out of synchronization with a master metadata record that is maintained in the system. In response to the change, the application sends a message to a synchronization control system.
At 454, the message from the application is received at the synchronization control system. The message includes at least one metadata record that describes a given asset, such as a material asset or a logical content asset. The message can be processed and converted to a format required by the synchronization control. At 456, a determination is made as to whether the metadata record matches one or more corresponding master record from a master database. As described herein, the match may be a partial or a complete match. In response to detecting a match between the received metadata record and a master record (YES), the method proceeds to 458.
At 458, content administration rules are applied (e.g., by a rules engine) to control updating the corresponding master record. The content administration rules can include a set of precedence rules and a set of ownership rules that are predefined for each of the subscribing applications in the system. Thus, a rules engine applies the rules to ascertain whether the detected change in the metadata (reflected in the received message) should be entered into a corresponding master record, such as described herein. The set of content administration rules further be selected depending on metadata in the received message. For example, a set of precedence rules can be loaded and utilized by a synchronization engine depending on the type of the asset represented by the metadata (e.g., is the asset logical content or material?). Additional rule sets can also be defined for and applied for different types of content and different types of materials so that the synchronization process can be further customize for a given enterprise.
The application of content administration rules at 458 thus confirms whether the application that initiated the method 450 both has precedence over the current master record and that the application is defined as an owner of the record (or records) that are to be updated. That is, if the application is not an owner or if the application does not have precedence over a corresponding master record, the master record will not be updated. At 460, a corresponding record (or records) of the master metadata database are updated depending on the results of the application of content administration rules at 458.
At 462, changes in metadata in the corresponding master record are encoded in a message that is published to one or more other applications in the system. The publication of the message can be controlled according to content administration rules, namely, applicability rules for each of the other subscribing applications, such as described herein. In this way each other subscribing application may receive an update message that includes an applicable set of changes that the application desires. Thus, based on the applicability rules, each update message that is sent out to the applications can be unique.
If the determination at 456 does not result in the occurrence of a match (NO), the method can proceed from 456 to 466 to take other appropriate action. Such other action can include sending the results of the matching process to a data store for performing a manual intervention. If the manual intervention determines that a match does exist, the manual intervention can return the manual results to continue the automated synchronization process, as indicated by dotted line at 468. In the situation that a match is not detected but the record is actually a new record, such new record may also be added to the master metadata database as indicated by dotted line at 470. It will be appreciated that new records may also be updated to the master database by automatic means, such as described herein. Additionally, the other action at 464 may also or alternatively include sending a message to the initiating application to indicate the absence of a match.
At 464, the synchronization process for the received message can end. The method 450 thus can repeat for each message that is sent to the synchronization control process.
In view of the foregoing, it has been shown that systems and methods implemented according to an aspect of the invention enables synchronization of metadata among applications running on a platform or otherwise subscribing to some messaging protocol. Thus, in one aspect precedence rules can be configured and enforced automatically, which provides a mechanism for resolving conflicts where two or more applications represent the same information (e.g., metadata fields) differently. By automatically enforcing a set of administration rules, the possibility of people accidentally changing information that is against policy can be greatly reduced or eliminated. Additionally, it is shown that transfer of current information can be provided on a near real-time basis, which ensures that all software applications connected to the solution have accurate and up-to-date information within the established rules.
What have been described above are examples and embodiments of the invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the invention, but one of ordinary skill in the art will recognize that many further combinations and permutations of the present invention are possible. Accordingly, the invention is intended to embrace all such alterations, modifications and variations that fall within the scope of the appended claims. In the claims, unless otherwise indicated, the article “a” is to refer to “one or more than one.”
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6170005||Jun 12, 1998||Jan 2, 2001||Motorola, Inc.||Synchronization and information exchange between communication components using a network management operations and control paradigm|
|US6601076||Jan 25, 2001||Jul 29, 2003||Palm Source, Inc.||Method and apparatus for coordinated N-way synchronization between multiple database copies|
|US20040117377||Sep 12, 2003||Jun 17, 2004||Gerd Moser||Master data access|
|US20050080796 *||Jul 29, 2004||Apr 14, 2005||International Business Machines Corporation||Data synchronization between distributed computers|
|US20060020611 *||Aug 2, 2005||Jan 26, 2006||Gilbert Eric S||De-identification and linkage of data records|
|US20060174266||Nov 1, 2005||Aug 3, 2006||Cyberscan Technology, Inc.||Methods and systems for interactive television|
|US20060200533||Mar 3, 2006||Sep 7, 2006||Holenstein Bruce D||High availability designated winner data replication|
|EP1286537A2||Dec 13, 2001||Feb 26, 2003||Canal+ Technologies Société Anonyme||Routing and processing data|
|GB2420882A||Title not available|
|WO2003028293A1||Sep 19, 2002||Apr 3, 2003||Nokia Corporation||Streaming of multimedia files comprising meta-data and media-data|
|WO2005116868A1||May 26, 2004||Dec 8, 2005||Nokia Corporation||Method, system, computer programs and devices for management of media items|
|WO2006089756A1||Feb 23, 2006||Aug 31, 2006||Smsc Europe Gmbh||Distributed network system with hierarchical management of resources|
|WO2006108750A1||Mar 16, 2006||Oct 19, 2006||Siemens Aktiengesellschaft||Method for synchronising content-dependent data segments of files|
|WO2006119100A2||Apr 28, 2006||Nov 9, 2006||Network Appliance, Inc.||System and method for generating consistent images of a set of data objects|
|WO2008000894A1||Feb 13, 2007||Jan 3, 2008||Valtion Teknillinen Tutkimuskeskus||Method and apparatus for controlling access to and usage of a digital media object|
|1||PCT International Search Report—3 pgs., Jun. 5, 2009, Harris Corporation.|
|2||PCT Written Opinion of the Int'l Search Report 4 pgs., Jun. 5, 2009, Harris Corporation.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8245223 *||Dec 23, 2008||Aug 14, 2012||Microsoft Corporation||Networked deployment of multi-application customizations|
|US8612405 *||Sep 30, 2011||Dec 17, 2013||Emc Corporation||System and method of dynamic data object upgrades|
|US9135674||Nov 27, 2013||Sep 15, 2015||Google Inc.||Endpoint based video fingerprinting|
|US9158805 *||Mar 12, 2013||Oct 13, 2015||Amazon Technologies, Inc.||Statistical data quality determination for storage systems|
|US9164751||Sep 30, 2011||Oct 20, 2015||Emc Corporation||System and method of rolling upgrades of data traits|
|US9336367||Sep 13, 2012||May 10, 2016||Google Inc.||Site directed management of audio components of uploaded video files|
|US20100162232 *||Dec 23, 2008||Jun 24, 2010||Microsoft Corporation||Networked deployment of multi-application customizations|
|US20110213720 *||Sep 1, 2011||Google Inc.||Content Rights Management|
|US20120096057 *||Oct 13, 2010||Apr 19, 2012||Business Objects Software Ltd.||Default object fragments|
|US20130254163 *||Jan 10, 2013||Sep 26, 2013||Bret SAVAGE||Cloud-based distributed data system|
|US20150120651 *||Feb 25, 2014||Apr 30, 2015||Microsoft Corporation||Master data management|
|U.S. Classification||707/694, 707/616|
|International Classification||G06F17/00, G06F7/00|
|Mar 13, 2008||AS||Assignment|
Owner name: HARRIS CORPORATION, FLORIDA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KOCSIS, CHARLES F;BERGSTROM, PAMELA V.;VAN PELT, BRIAN;AND OTHERS;REEL/FRAME:020647/0635
Effective date: 20080312
|Feb 5, 2013||AS||Assignment|
Owner name: HBC SOLUTIONS, INC., COLORADO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HARRIS CORPORATION;EAGLE TECHNOLOGY INC.;REEL/FRAME:029759/0416
Effective date: 20130204
|Apr 5, 2013||AS||Assignment|
Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, MINNESOTA
Free format text: SECURITY AGREEMENT;ASSIGNOR:HBC SOLUTIONS, INC.;REEL/FRAME:030156/0636
Effective date: 20130204
Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, MINNESOTA
Free format text: SECURITY AGREEMENT;ASSIGNOR:HB CANADA COMMUNICATIONS LTD;REEL/FRAME:030156/0751
Effective date: 20130329
|Apr 10, 2013||AS||Assignment|
Owner name: PNC BANK, NATIONAL ASSOCIATION, AS AGENT, NEW JERS
Free format text: SECURITY AGREEMENT;ASSIGNOR:HBC SOLUTIONS, INC.;REEL/FRAME:030192/0355
Effective date: 20130204
|May 2, 2013||AS||Assignment|
Owner name: HBC SOLUTIONS, INC., COLORADO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HARRIS CORPORATION;EAGLE TECHNOLOGY, LLC;REEL/FRAME:030333/0671
Effective date: 20130204
|Mar 13, 2015||FPAY||Fee payment|
Year of fee payment: 4