METHOD AND APPARAUTS FOR MAPPING PROCESS INFORMATION ONTO ASSET DATA

Asset-driven work flow dependency management establishes connections between activities based on the descriptions of the assets used as inputs and/or outputs for each activity. These descriptive “contracts” enable readily matching relevant activities to create a desired output. The graphical model can be used to design and track real world productions. Graphical representations of activities are used to model venders, facilities and other production activities. The activity models produce and/or consume assets that represent the deliverables that are transferred between activities. Using the models of activities, a model of the production pipeline can be built from back to front. Thus, a final result activity model is selected first and based on the assets required by the selected final result activity an appropriate activity that produces that required asset can be selected. This process can be repeated until the beginning of a process pipeline is reached.

TECHNICAL FIELD

This invention relates to modeling workflow and/or production pipelines, and more particularly to a method and apparatus for modeling a production pipeline based on the assets required and produced along the production pipeline.

BACKGROUND

For any movie, television, or record production, there are several assets such, a shots, visual effects, sound, etc that are in several different formats are that transferred between different productions companies which may produce new assets in new formats. These assets are the building blocks used to make a television show, movie, record, or the like. Keeping track of such assets and knowing what the location and state of the assets is a tremendously complicated endeavor.

Project manager programs exist but they are typically designed for a top down static system design where each block representing a stage of the project is associated to the next block by the user to create the system. Blocks do not link together based on assets nor do the programs track such assets.

Thus, a method and system that can model a workflow and/or a production pipeline based on assets used in the production of a movie, television, music album, etc. is needed.

BRIEF SUMMARY

Asset-driven workflow dependency management establishes connections between activities based on the descriptions of the assets used as inputs and/or outputs for each activity. These descriptive “contracts” provide a mechanism to readily match relevant activities necessary to create a desired output. By creating a graphical model of desired workflow a user is provided with a better understanding of what is involved in the workflow as well as where issues and redundancies may occur. The graphical model can be used to design and track real world productions.

Graphical representations of activities are used to model venders, facilities and other production activities. The activity models produce and/or consume assets that represent the deliverables that are transferred between activities. Using the models of activities, a model of the production pipeline can be built from back to front. Thus, a final result activity model is selected first and based on the assets required by the selected final result activity an appropriate activity that produces that required asset can be selected. This process can be repeated until the beginning of a process pipeline is reached. A real world process pipeline can then be formed based on the model and the model can be used to track the status of the real world production pipeline. In order to prevent duplication and redundancy a workflow model can be created based on already existing assets.

One embodiment of the disclosure provides a method for modeling a workflow. The method includes the steps of determining that an asset required for a workflow already exists and providing a graphical representation of an activity that involves the existing asset.

Another embodiment of the disclosure provides an apparatus for modeling a workflow. The apparatus includes storage, memory and a processor. The storage and memory are for storing data. The processor is configured to determine that an asset required for a workflow already exists and provide a graphical representation of an activity that involves the existing asset.

Objects and advantages will be realized and attained by means of the elements and couplings particularly pointed out in the claims. It is important to note that the embodiments disclosed are only examples of the many advantageous uses of the innovative teachings herein. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views.

DETAILED DESCRIPTION

Turning now toFIG. 1, a block diagram of an embodiment of a system100for implementing asset driven workflow modeling is provided. The system includes a server110and one or more electronic devices such as: smart phones120; personal computers (PCs)130, such as desktops or laptops; and tablets140in communication with the server110over the internet150. In certain embodiments, the server110provides the environment, including processing and storage, for the asset driven workflow modeling. Users interface with the asset driven workflow model on the server110using a browser or application on the electronic devices such as smart phones120, PCs130, or tablets140. In other embodiments, part, or all, of the asset driven workflow modeling can be performed on the one or more electronic devices such as: smart phones120; personal computers (PCs)130, such as desktops or laptops; and tablets140.

FIG. 2depicts an exemplary server200, or electronic device, that can be used to implement the methodology and system for asset driven workflow modeling. The server or electronic device includes one or more processors210, memory220, storage230, and a network interface240. Each of these elements will be discussed in more detail below.

The processor210controls the operation of the server200or electronic device. The processor210runs the software that operates the server or electronic device as well as provides the functionality of the asset driven workflow modeling application. The processor210is connected to memory220, storage230, and network interface240, and handles the transfer and processing of information between these elements. The processor210can be general processor or a processor dedicated for a specific functionality. In certain embodiments there can be multiple processors.

The memory220is where the instructions and data to be executed by the processor are stored. The memory220can include volatile memory (RAM), non-volatile memory (EEPROM), or other suitable media.

The storage230is where the data used and produced by the processor in executing the cold storage recommendation methodology of the present disclosure is stored. The storage may be magnetic media (hard drive), optical media (CD/DVD-Rom), or flash based storage. Other types of suitable storage will be apparent to one skilled in the art given the benefit of this disclosure.

The network interface240handles the communication of the server200or electronic device with other devices over a network. Examples of suitable networks include Ethernet networks, Wi-Fi enabled networks, cellular networks, and the like. Other types of suitable networks will be apparent to one skilled in the art given the benefit of the present disclosure.

It should be understood that the elements set forth inFIG. 2are illustrative. The server200, or other electronic device, can include any number of elements and certain elements can provide part or all of the functionality of other elements. Other possible implementation will be apparent to on skilled in the art given the benefit of the present disclosure.

FIG. 3depicts a graphical model300of an asset driven workflow. Asset-driven workflow dependency management establishes connections between activities based on the descriptions of the assets used as inputs and/or outputs for each activity. These descriptors provide a mechanism to readily match relevant activities necessary to create a desired output.FIG. 3shows that the Transforming Activity310requires Asset A and Asset B as inputs312,314and will create Asset C as a result provided on output316. The Consuming Activities320,330expect Asset C on the inputs322,332while both Producing activities340,350bring Assets A and B into the modeled system on outputs342,352. In this exemplary Pipeline300, the outputs342,352of Producing Activities340and350are connected to the inputs312,314of Transforming Activity310. The output316of Transforming Activity310is in turn connected to the inputs322,332of Consuming Activities320and330.

SOME WORKING DEFINITIONS

Pipeline: A collection of Activities connected together to create a desired output. The pipeline provides a graphical model of the workflow. For example of video or film production, the pipeline represents all the activities (such as generation of data, specific shots, formats, or audio tracks) necessary to produce the desired product.

Activity: An operation that produces, transforms, or consumes Assets (Including deliverables such as data, specific shots, formats, or audio tracks). Each Activity may have inputs, an output or both. As a simplifying assumption, activities typically only have a single output (although the output could be a complex or compound asset). Activities (except for consuming activities) can be easily characterized by their output. What makes an Activity unique is the specific configuration of inputs that are mapped via the Activity to produce a given output. Different Activities may create an identical output and therefore only one would be required within a given Pipeline. The output of a given activity can provide input into multiple downstream Activities.

Connection: when an Activity output description matches one or more input descriptions then a Connection is implied. Connections represent fulfillment agreements or contracts for the delivery and receipt of Assets.

Asset Descriptor: The label of an input/output of and Activity used for matching and establishing connections between Activities.

Further discussion of these concepts is provided later in this document.

FIG. 4is a flow diagram400of a process for creating a graphical representation of a workflow. At the basis the process involves three steps. Providing a graphical representation of a first activity (step410) having at least one input with an associated asset descriptor, providing a graphical representation of a second activity having at least one output with an associated asset descriptor matching the asset descriptor of the input of the graphical representation of the first activity (step420), and graphically connecting the output of the graphical representation of the second activity with the input of the graphical representation of the first activity based on the matching asset descriptors (step430). A graphical example500of these steps can be seen inFIG. 5.

Modeling the Workflow

Step410, as shown in graphical example500ofFIG. 5, starts with providing a graphical representation of a first activity510. In this embodiment the graphical representation of the first activity has one input512with a descriptor of the desired asset (in this case “H”). In other embodiments the graphical representation of the first activity510may have multiple inputs with different associated asset descriptors. The provided graphical representation of the first activity may be a graphical representation selected from multiple provided graphical representations of activities. The selection of a graphical representation can be made by user using a graphic user interface or by the system itself based on the desired or required activity. In some circumstances, not all of the activities that can match a specific asset descriptor will be used.

In step420of the graphical example500ofFIG. 5, at least one graphical representation of a second activity is provided. In this example, the system searches for activities that have an output with an associated asset descriptor that matches the asset descriptor (“H”) of the input512of the first activity510. There could be more than one activity that will output the desired activity but only one needs be selected. The selection can be performed by a user or by the system. In this example there are two possible activities520,530that have an output with an as associated asset descriptor that matches the asset descriptor (“H”) of the input512of the first activity510. One possible second activity520has an output524with a matching asset descriptor (“H”) as well as an input522with a different associated asset descriptor (“A”). The other possible second activity530having an output536with a matching asset descriptor (“H”) has two inputs532,534with different associated asset descriptors (“D” and “H”).

Selecting the desired second activity, in this case activity520, into the pipeline implies a connection between the activities510,520since the asset descriptor associated with the output of the second activity520matches the asset descriptor of the input512of the first activity510. The implied connection is represented in step430as a graphical connection540.

In this embodiment, the matching and connection is based on asset descriptors not the asset itself. This allows for the creation of a complete pipeline model before actual assets exist. Some benefits of such asset driven modeling include: explicit mapping of activities based on the descriptions of assets they output or consume, provenance of assets can be traced explicitly through the system, and downstream dependencies can be easily calculated.

In the world of media production it is common to encounter activities which produce a number of like elements as part of larger set. For example a “Dailies” activity is responsible for converting video and audio “shots” captured on-set into an easily reviewable format for the director or producer to review and approve.

As an example: the Dailies activity might be responsible to process1000“shots” over a period of a few weeks. Furthermore these “shots” may come from different camera units in a non-sequential fashion. The output of the “Dailies” activity is regularly passed through to the next step on a daily basis.

For the modeling of such a system, the use of sets may be beneficial. Set are collections of one or more assets that are of the same type. Each member of the set is a unique asset but is of the same type or class as the other assets in the set. For example, a set may consist of 500 shots but each member of the set is a shot. Sets can be used to distribute and accumulate work product across multiple activities. Sets can also be divided into sub-sets as well. Hence, an activity might receive different sub-sets from different activities or an activity might only consume a portion of the original produced.

The methodology of modeling a workflow using sets is similar to the methodology for non-set asset driven modeling as set forth inFIG. 4. First and second activities are provided and connected based on the associated asset descriptors. However in this case, the asset descriptors indicate that sets of assets are being used. An example of this can be seen in the workflow model600ofFIG. 6.

In the workflow model600ofFIG. 6a graphical representation of a first activity610is provided. The first activity610is a consuming activity and has an input612with an associated asset descriptor (in this case “D”). In this example, the asset descriptor further indicates there is a set of assets (in this case, shots1-25) that is expected to be received at the input612. A graphical representation of a second activity620is also provided. The second activity620is a transforming activity and has an output622with a matching associated asset descriptor (“D”). However, in this case the asset descriptor indicates that there is a larger set of assets (shots1-100) that is to be provided on the output622. However, since some of the member assets of each set match a connection is implied and indicated graphically670.

In the embodiment ofFIG. 6, graphical representations of a third630and forth640activities are also provided. The third and forth activities are consuming activities with inputs632,642having associate asset descriptors (“D”) which further indicate the inputs632,642are to receive sets of activities. In the case of the third activity630, the set comprises shots26-75. In the case of the forth activity640, the set comprises shots76-100. Since the sets of the third and forth activity630,640are subsets of the set of the second activity620, there are matching members of the respective sets and a connection is implied between the second activity620and the third activity630as well as between the second activity620and the forth activity640which are indicated graphically672,674.

As set forth previously, the second activity620in the model600ofFIG. 6is a transforming activity. As such, the second activity620further includes an input624with and associated asset descriptor (in this case, “S”). In this example, the associated asset descriptor further indicates that there is a set of assets (in this case, shots1-100) expected to be received on the input624. Thus, the second activity620models a process, or operator that receives a set of assets “S” comprising shots1-100on its input624and produces a set of assets “D” comprising shots1-100on its output622.

Graphical representations of a fifth activity650and sixth activity660are also provided in the model600ofFIG. 6. The fifth activity650and sixth activity660are producing activities with outputs652,662having associate asset descriptors (“S”) which further indicate the inputs652,662are to produce sets of activities. In the case of the Fifth activity650, the set comprises shots1-50. In the case of the sixth activity660, the set comprises shots50-100. Since the sets of the fifth and sixth activity650,660are subsets of the set to be received on the input624of the second activity620, there are matching members of the respective sets and a connection is implied between the fifth activity650and the second activity620as well as between the sixth activity660and the second activity620which are indicated graphically680,682.

Asset Descriptors

As can be seen, asset descriptors are used to model inputs and outputs to create connections between activities and identify potential activity connections. In certain embodiments the asset descriptors can be used to correlate with existing assets in an asset registry.

In certain embodiments asset descriptors can be used for exact or parameterized matching, where parameterized matching provides some wildcard-like capabilities when descriptors are compared. In the present examples, a fully defined asset descriptor is denoted with a capital letter in a circle, for example:

A parameterized asset descriptor can be denoted with a capital letter “primed” in a circle. For example:

Some More Definitions:

Activity Instance. Is an activity where all input and output asset descriptors are fully defined, meaning there are no undefined parameters.Activity Template. Is an activity having one or more parameterized asset descriptor to facilitate reuse. This, however, is not a requirement.

Activities are defined in terms of their inputs and outputs. Inputs and outputs are defined, in-turn, by their asset descriptors. The specific combination of inputs and outputs determines the “signature” of the activity (regardless of what it might be named). In the example ofFIG. 7, Activity1700takes an asset (A) and an asset (B) at the inputs702,704and provides and asset (C) at the output706. Activity2710provides an asset (C) at the output but takes asset (X) at the input712. In this example, each of these activities is unique in that they require different inputs but both produce the same output.

To model a connection between activity instances the output of an upstream activity needs to match the input of a downstream activity. Multiple downstream activities may consume the same asset. In the first model800ofFIG. 8, there is an Activity Instance1(810), Activity Instance2(820), Activity Instance3(830), and Activity Instance4(840). In the second model850the connections are shown with Activity Instance1(810) providing asset (A) to instances2(820) and3(830). Activity Instance3(830) requires two inputs (A) and (B). Asset (B) is provided by Activity Instance4(840).

To model a potential connection between an Activity Instance with an Activity Template the Input of the instance can do a template match with the output of the template (or vice-versa). An example of this can be seen in model900ofFIG. 9. InFIG. 9, the asset descriptor (A) of the input932of Activity Instance4(930) matches the asset descriptor (A′) of the output912of Activity Template1(910) and the asset descriptor (B) on the output942of Activity Instance5(940) matches the asset descriptor (B′) of the input922of Activity Template2(920).

Using single letters up to this point was one approach to illustrate the disclosed concepts at a high level. In practice there are an arbitrarily large number of ways to describe an asset. One embodiment uses a collection of name/value pairs in order to provide a human readable and flexible mechanism for creating Asset Descriptors. An Asset Descriptor can be comprised of one or more name/value pairs taken as a whole to describe the asset General Asset Descriptor format:

Example

A parameterized description simply leaves one or more values blank. In the example below both “Title” and “Version” are parameters.

Example

Asset Identifiers are normalized versions of the Asset Descriptor. First the Asset Descriptor is normalized so case and name/value pair order do not affect the comparison. To normalize the Asset Descriptor, names and values are forced to lower case (optional) then sorted by name and the result concatenated.

Example

Optionally a cryptographic hash can be performed on the above result to create a unique numeric (hex) identifier shown below:147c21 df6e470da7879307dbfb2e2a5d3e9c40719ba2a1a840bf71c732f71b2f
The cryptographic hash variant of the Asset Identifier is especially useful when identifying user interface elements as a class or id parameter in HTML where the textual version has too many issues to be convenient.

An Asset Reference concatenates the values in the order defined in the original Asset Descriptor separated by an underscore “_” character. This provides a human readable shorthand to less formally describe the asset.

The above example becomes:

Asset Descriptors and Asset Identifiers can both be used for full identification. The Asset Reference, however, is for display convenience only and should not be relied on for unambiguous referencing.

Exact matching of fully-defined Asset Descriptors can be performed directly using the Asset Identifiers.

When matching a fully-defined Asset Descriptor with a parameterized descriptor the following rules are used:Name/Value pairs are forced to lower case prior to comparison.The parameterized Asset Descriptor must have exactly the same name entries as the fully defined Asset Descriptor. The order of the names is not significant.If a parameterized Asset Descriptor entry has a blank for a value then it will match regardless of the corresponding value in the fully-defined Asset Descriptor. If the parameterized Asset Descriptor has a non-blank entry for a value then it must match exactly (after normalization).

Examples are shown the exemplary table1000ofFIG. 10.

When building a pipeline of activities it should be sufficient to select the desired output (consuming activity), fill in the desired parameter values and then allow the desired values to propagate as activities are identified to complete the pipeline. The example ofFIG. 11details a pipeline1100being built from finish-to-start as indicated by arrow1102.

Pipelines may also be built from start-to-finish or middle-out.

Step1.0(1110) ofFIG. 11Bbegins at the end activity. In this example the provided activity is a selected Activity Template1112for which the parameters for the asset descriptor “A′” for the input are specified making the Activity Template an Activity Instance. The specified parameters for the asset descriptor “A” can then be passed to a second provided Activity Template1122through connection1114.

In step3.0(1130) ofFIG. 11A, specified parameters from the second Activity Instance are passed through connection1124to a provided third Activity Template1132. The passed specified parameters are used to specify parameters for the asset descriptor “C′” associated with the output of the provided third Activity Template1132making the Activity Template an Activity Instance.

In step4.0(1140) specified parameters from the second Activity Instance are passed through connection1126to a provided forth Activity Template1142. The passed specified parameters are used to specify parameters for the asset descriptor “B′” associated with the output of the provided forth Activity Template1142making the Activity Template an Activity Instance.

In modeling actual content creation and distribution pipelines the following heuristics can prove useful:All Activity Descriptors should contain a “Title” and “Version”. These differentiate the assets for an entire pipeline instance.All Activity Descriptors should contain a “Type”. The Type field represents the type of content being produced by an activity (Video, Audio, Digital Cinema Package, etc).Other useful Asset Descriptor entries are: “Language”, “AspectRatio”, “DubSubOV”, and “Format”. These may or may not be relevant based on the “Type” value. Others entries may evolve into use over time.

Asset Registry

As the activities and assets of the graphical models discussed herein can often represent real activities or assets it can be beneficial to provide and maintain an Asset Registry. The Asset Registry maps Asset Descriptors (or Asset Identifiers) to the location of actual assets. By registering existing assets against fully defined Asset Descriptors it is possible to eliminate unnecessary activities from the pipeline upon definition.

As a modification to the previously defined pipeline building strategy a step to check the registry can proceed any attempt to match Activity Templates. It is possible to have multiple copies of an asset at different locations mapped to a given Asset Descriptor/Identifier.

Fulfillment Modeling

In the modeling methodology described herein, activities and their connections are modeled based on asset dependencies (see Asset Descriptors section for details). Each connection between activities represents a logical dependency of the output of one activity to the input of the subsequent activity. In order to trace progress from activity to activity, connections can have a fulfillment status. An exemplary methodology for modeling fulfillment status in a workflow model can be seen in the flowchart1200ofFIG. 12.

At its simplest, the method involves two steps. The first step (1210) is providing a model of a workflow having at least a graphical representation of a first activity and a graphical representation of a second activity wherein the activities are connected based on matching asset descriptors. The second step (1220) is determining the status of at least one asset indicated by the matching asset descriptors that are the basis of at least the connection between the graphical representations of the first and second activities. The steps are described in more detail below in reference toFIG. 13.

In the diagram1300ofFIG. 13, a model of workflow is provided as set forth in Step1210of the methodology ofFIG. 12. In this example, the model includes graphical representations of a first activity1310(here a source activity) and a second activity1320(here a destination activity). The first1310and second1320activities are connected1330based on matching asset descriptors. A fulfillment status1340is then determined for at least one asset indicated by the matching asset descriptors that are the basis of the connection1330.

The fulfillment status reflects the state of a physical/electronic asset moving from one activity to the next. When an activity has produced the expected output (asset) it is physically/electronically sent to dependent downstream activities so the process can continue. The fulfillment mechanism tracks the state of the asset movement (e.g. pending, sending, received, error). In certain embodiments the fulfillment status can graphically displayed or otherwise indicated as part of the graphical representation of the activities or other elements of the model.

In certain other embodiments, the status of an activity can be determined based on the fulfillment status of the assets being produced and/or consumed by activity. In certain further embodiments the status of the activity can be graphically displayed or otherwise indicated as part of the graphical representation of the activity or other elements of the model.

In certain embodiments, a single physical/electronic delivery can be leveraged by multiple downstream activities and multiple fulfillment records would be redundant. To solve this, a change can be made from an activity-to-activity dependency relationship to an activity-to-facility relationship. An example of this can be seen inFIG. 14.

In the exemplary diagram1400ofFIG. 14, Activity B1420and Activity C1430are in the same shared facility1450(facility Y). Thus a connection1402is shown between the source, Activity A1410and the shared facility1450(facility Y). Destination Activity D is1440in a different facility (facility Z) so a separate connection1404is provided between Activity A1410and Activity D1440.

The term “facility” has been chosen to differentiate from other “location” references used in the system. In addition the specific asset dependency relationship must still be maintained such that the fulfillment is dependent on not only the facility but also the specific asset that is to be delivered. In such embodiments, a fulfillment status now represents the delivery of a specific asset from a source activity to a facility which, in-turn, may be shared by multiple destination activities. A diagram1500of the interaction of these elements can be seen inFIG. 15.

In the diagram1500ofFIG. 15, a model of workflow is provided. In this example, the model includes graphical representations of a first activity1510(here a source activity) and a second activity1520(here a destination activity). The relationship1530between the first1510and second1520activities are based on matching asset descriptors. A fulfillment status1540is then determined for at least one asset indicated by the matching asset descriptors that are the basis of the relationship1530. As a practical constraint to this method a facility1560is associated with a vendor1550which is referenced by the second activity1520. This way, changing vendor information will result in the appropriate facility assignment. A given facility may be referenced by multiple vendors.

A fulfillment status can be referenced for each pair of activities that share an asset description. When generating the fulfillment status the destination activity's vendor.facility descriptor can be used to determine if a fulfillment has already been created—if so, then the existing fulfillment record can be referenced, otherwise a new fulfillment can be created. In certain embodiments, reverse domain name syntax can be use for the facility descriptor so it's human readable (e.g. technicolor.perivale, technicolor.perivale.transcodingDept). Unique facilities warrant separate fulfillments but there can be multiple “facilities” at the same physical location. This will result in separate records to track fulfillment status independently.

Mapping Process Information onto Asset Data

The workflow modeling, up to this point, has been focused on driving asset creation processes (activities) consistent with the modeled pipeline. That is to say that the system dictated, based on the defined model, what activities depend on what and enforced registration of assets according to the Asset Descriptor scheme. An alternate approach is now provided for delivering a similar level of pipeline information but in a passive manner without direct influence of the underlying activities. The general idea is to overlay a pipeline model (process data) over asset data in order to derive status of the overall process.

When assets are created it is assumed that they are registered in an asset registry system. This methodology would require additional structured data consistent with the concept of Asset Descriptors and Asset Registry described above. The name/values of the asset descriptors would need to be consistent (e.g. titles, language, aspect ratio, etc).

A process model, comprised of activities which in-turn reference Asset Descriptors, would be obtained (perhaps from a process registry) and used to view the data in the asset registry to derive pipeline status information. An example methodology can be seen in the flowchart1600ofFIG. 16.

At its simplest, the method involves two steps. The first step (1610) is determining that an asset required for a model of a workflow exists. The second step (1620) is providing a graphical representation of an activity that involves the existing asset. The steps are described in more detail below in reference toFIG. 17.

The diagram1700ofFIG. 17has three parts: The asset registry1710, process model1720, and inferred status1730.

It is in the asset registry1710that the first step (1610) of is performed. To determine if an asset exists the asset registry is queried. The asset registry is a collection, such as a database, of the assets that have been generated or previously exist. In this example it is assumed the asset registry contains only assets for a given workflow. However, it should be apparent to one skilled in the art that the asset registry could contain any number of registered assets including assets that are not part of the current workflow model. In the example ofFIG. 17, it is determined that three assets (A, B, C) already exist.

In the Process Model1720ofFIG. 17graphical representations of activities that involve the asset(s) are provided. Such an activity can include the activity that produced or consumes the asset. In certain embodiments, graphical representations of both a producing and a consuming activity, which can be further connected, can be provided. In other embodiments, where there are multiple pre-existing assets, graphical representations of whole pipelines, where all the activities are connected, can be provided. In certain embodiments a process or model registry could be provided. The process registry, like the asset registry, is a collection, such as a database, of pipeline models that have already been created or previously used. In some such embodiments, the registered pipeline models could be matched with or otherwise linked to registered assets in the asset registry.

With Inferred Status1730, for each activity in the pipeline model the corresponding asset descriptor is queried from the asset registry. If an asset matching the descriptor is found then that activity is assumed to be complete. It is then possible to infer what activities should be in progress by seeing if the inputs to those activities are complete but the output of the current activity is not complete. An example of a status table can be seen at1740.

Using this basic mechanism, data sets can be approached in a number of ways:

Pre-defined pipeline: In this scenario the specifics of a pipeline are known in advance (i.e. title, version, aspect ratio, etc are defined). This allows for direct mapping to assets in the asset registry. The benefit of this approach is that you can view the status of a pipeline that doesn't have any corresponding activities registered yet.

Infer from existing assets: The system can assume a known pipeline but only for assets that already exist in the registry. As an example, if a translation is received and registered for a specific title, version, language then the system would create an instance for the Acquire Translation activity with the given values then infer the remaining pipeline by matching the output to other activity inputs and in-turn matching the outputs of those activities to the inputs of subsequent activities. The process could happen in an upstream direction as well by matching any inputs of a found activity and following the path of inputs to outputs.

A feature of this method of overlaying process model over existing data is that you can try multiple pipelines as “viewing lenses” to see which pipeline variation matches best.

While the previous discussions have focused on creating a model of a workflow and monitoring the status, in certain embodiments it may be advantageous to provide an overview of the pipeline. As such, a user interface may be provided to not only provide a graphical model of the workflow but also provide a high-level perspective of the workflow process. Examples of such a user interface can be seen inFIGS. 18-25. These examples are screen shots that a user can be provided when interacting with the system, such as through a web browser or application on an electronic device.

In accordance with certain embodiments, when the system of the present disclosure is launched, the user will be prompted for credentials and then presented with the producer's workspace as depicted in screen shot1800ofFIG. 18. This workspace1800provides the means for creating entries, viewing status and dependencies along with activity details. A user can also drive the operational process from the activity details panel. The producer's workspace1800is comprised of three panels: The Deliverables Dashboard1810, the Filtered Pipeline View1820, and the Details View1830. Other workspace views are available for selection1802by the user and are discussed in more detail below.

FIG. 19is an example of the Deliverables Dashboard1810ofFIG. 18. Each line of the dashboard relates to deliverable1900and indicates the activities1910associated with the deliverables. The deliverables dashboard1810further lets a user add a title/version/format1920to the system, select from existing titles/versions/formats1930, request specific deliveries or add new deliverable1940, and add a new language/aspect ratio/DubSub line1950. Entering information here causes the underlying system to build the appropriate pipeline to fulfill the requirement. The system is “smart” enough to know if a particular activity is shared between deliverables.

FIG. 20is an example of the Filtered Pipeline View1820. The filtered pipeline view1820displays a graphic representation of the activities and their interdependencies. The filter pipeline view provides both a list view2010and a traditional pipeline model view. The activities shown in this view are related to the row selected in the Deliverables Dashboard. Each activity2030is graphically represented as a box with inputs (circles on the left side) and/or outputs (circles on right side). In this embodiment the fulfillment status of assets is indicated by filling-in or otherwise highlighting the inputs and/or outputs indicating an asset has been received or produced. In certain further embodiments the status of an activity can also be graphically indicated. In the present example a box is provided in the bottom left corner which can be filled to indicate status. An empty box means the activity has not started, a partially filled box means the activity is in progress, and a filled box means the activity has been performed.

This panel is also available in the Executive workspace. In that case selecting an activity from the executive panel will display the pipeline relative to activity selected.

FIG. 21is an example of the Details View1830. The detail view panel1830provides the ability to update the state of the activity based on three simple actions for which buttons can be provided:Set to Ready (2120) is used to indicate that activity has been completed.Send (not shown) to let the system know when the asset has been sent to the next activity or activitiesReceive (not shown) to let the system know when an asset has been received from an upstream activity.

In certain embodiments, a Revise action can be provided once an activity has been set to ready. Revising allows a user to see the impact of a change and then commit the change to be redone.

The information provided by these actions can be used to determine the fulfillment status of assets as well as the status of the activities themselves.

In the current display of the details view panel1830, the actions, indicated by the highlighted “ACTIONS” tab are being displayed. If the “DETAILS” tab is selected, information about due dates and vendor information is displayed. If a date is set and the date is missed (e.g. not done by the due date) the system will flag that as an issue.

Another possible workspace is the Manager Workspace as depicted in screen shot2200ofFIG. 22. The manager workspace2200is comprised of the manager panel2210and the activity detail panel1830.

The manager panel2210presents all work going through a specific activity. The manager panel2210allows a user to select a specific activity using field2220. The work or tasks associated with the selected activity is then displayed in the panel2210. Filters2230can be used adjust what is being displayed. The default filter only shows things that need working on, but filters can be set to show what's coming and what's already been completed.

Once the work is done “Set to Ready”2240can be selected and the tasks drop off the board (unless the filters are set otherwise). The activity detail panel1830of the manger workspace2200operates as described in reference toFIG. 21.

Another possible workspace is the Data I/O Workspace as depicted in screen shot2300ofFIG. 23. The data I/O workspace2300is comprised of the Data I/O Panel2310and the Activity Detail Panel1830.

The data I/O panel2310is designed to show all the actions related to a specific facility. It is primarily designed to show send and receive actions to accommodate the idea that people moving assets in and out of a facility may be different from those performing the work creating or modifying assets. The data I/O panel2310allows a user to select a specific activity using field2320. The work or tasks associated with the selected activity, as well as their status2340, is then displayed in the panel2310. Filters2330can be used adjust what is being displayed. The default filter only shows things that need working on, but filters can be set to show what's coming and what's already been completed. Action such as “Set to Ready”, “Send”, and “Receive”2350can be selected and the status2340is updated accordingly. The activity detail panel1830of the data I/O workspace2300operates as described in reference toFIG. 21.

Another possible workspace is the Executive Workspace as depicted in screen shot2400ofFIG. 24. The executive workspace2400is comprised of the Executive Panel2410, the Filtered Pipeline Panel1820, and the Activity Detail Panel1830.

The executive panel2410provides overview data such a graphs and task lists. Filters2420can be used adjust what is being displayed. In this example, the top box determines what to filter on and the lower box sets the value to use. Results can be grouped using selector2430. Selecting grouping headers2440allows for the groups to be expanded or collapsed. Selecting an item in the panel2450caused the related activities and tasks to be displayed in the filtered pipeline panel1820and the activity detail panel1830.

The filtered pipeline panel1820of the executive workspace2200operates ad describe in reference toFIG. 20. The activity detail panel1830of the executive workspace2200operates as described in reference toFIG. 21.

The final exemplary workspace is the Pipeline Builder as depicted in the screenshot2500ofFIG. 25. The pipeline builder2500is comprised of the Template List2510and the Workspace2520.

The template list2510provides a field2512for selecting a project or workflow. The relevant activity templates for the selected project or workflow are then provided in the template list. These results can further be filtered using the filter functionality2514. If necessary a new template can be created using a creation tool2516.

The workspace2520provided the functionality for building a pipeline model as discussed throughout this disclosure. In this embodiment, selecting an input or output of a graphical representation of an activity2530causes the result in the template list2510to be filtered based on the asset descriptors associated with the input or output.