1. BLOOMBERG TRISKEL IBM FIMS REPOSITORY INTERFACE 05/06/2012 V1.0

2. Contributors  Loic Barbou – Triskel  Ashraf Tadros – Triskel  Derrick McKenzie – Bloomberg  Roman Mackiewicz – Bloomberg  Frank Schaffa – IBM  Peter Guglielmino – IBM  Gaurav Bhasin – Triskel  Jeff Seifer – Bloomberg

3. Service Definition The asset repository service is intended to provide a common FIMS interface specification for storing, retrieving and managing media assets within and across heterogeneous content storage systems. The scope of this service is tightly defined as dealing with persistence of a core set of asset types and a minimum set of associated metadata. Future projects will allow for additional asset types and extended metadata schemas. The service should be implemented in such as way as to allow for repositories of varying performance, scale and capability

4. Primary Objectives  Basic CRUD functions on Assets within the repository (create, read, update, delete)  A mechanism to handle versioning of assets  Simple locking capability (check in, out)  Management of simple, self contained media assets  Management of complex, composite media assets  Management of core metadata set with pass-through of implementation specific “dark” metadata.  Query of core metadata set (see search comment under constraints)  Creation of FIMS asset GUID  Support for mapping of house and industry ID’s to FIMS asset GUID’s  It is possible that some implementations will not support all functions of the repository interface. There should be an API that advertises all supported operations so that external systems can automatically determine a repository’s capabilities.  Passing of credentials to support externally managed security mechanisms  Services should be combinable with minimal external integration. In a simple instance, the output of 1 operation should be able to be chained to the input of the next. Payloads may need to move through multiple sequential services in a workflow when a sophisticated messaging layer is not available to target and parse messaging content.  Event model that allows external systems to subscribe to events that occur within the repository  There should be a capability for an external management system to re-synchronize state with a repository.  Mapping mechanism that allows complex objects to be mapped to the underlying asset object model. Should allow for new complex assets to be created without significant effort.

5. Secondary Objectives  Management of additional media file types (e.g. DPX, Photos/Stills, non- media files)  Fast failure in the event of a subsystem's performance is compromised  Specification of EBU Core as a recommended practice, reducing the “dark” part of dark metadata in pass-through scenarios

6. Triskel/Bloomberg Concept Proposal  Keep it simple, as a V1.0 the repository service interface should only include simple basic repository operations. If it can be model within a workflow, the level of abstraction is too high and shouldn’t be part of the interface definition.  Leverage the work done for Transcoding/DataMover/Capture interface: BMContentType, base service operation.  Clear separation of Object and Content operation boundaries.  Flavor synchronous operation when possible  Introduction of a light (lite) BMContent object.  Extend existing objects without redesigning them.  Introduction of a RepositoryProfile object for repository communication encapsulation

7. What is in Scope?

8. Current Asset Structure Definition Asset Identifier & Editorial metadata Video & Audio Formats Essence Location & structure information 1 to many

9. Current BMContent Structure BMContent Type BMContent FormatType BMEssence LocatorType 1 to many BMContent Type = BMO Assumptions

10. Light BMContentType: CoreEntity  Definition  Simple portable object containing all the information needed to uniquely identify a media object  Purpose  Use as an input or output parameter for operations where only object identification is needed.  Small object footprint limits payload sizes  Easier to populate than a fully hydrated BMO

11. RepositoryProfile  Definition  Property bag object containing information about vendor specific repository operation interaction  Purpose  Encapsulate security profile or token for repository operations  Handle session state and user credentials

12. Synchronous vs Asynchronous Operation  Synchronous operation: used for short running transactions where the response contains the result of the executed operation.  i.e. Pause Job operation  Asynchronous operation: used for long running transactions where the response contains an acknowledgement of requested operation. A call back mechanism is leveraged to get the result of the completed operation.  i.e. Transform or Transfer operations

13. Content vs Object  Content represents the video file(s). Content operations process the bits of the asset  Object represents the metadata around the asset:  Editorial metadata  Identifiers  Structural and physical metadata

14. Service Operations  Summary List  AddObject  IngestContent  DeleteContent  DeleteObject  RetrieveSegment  Retrieve  RetrieveObject  UpdateObject  Lock  Query  FireEvent  CreateUID  MapIDs  GetServiceCapabilities

15. Operation: AddObject  Description  Create an object (BMContentType) representing the media asset data entry containing asset IDs, physical and editorial metadata  Operation Type  Synchronous  Input Parameters  BMO  RepositoryProfile  Output Parameters  BMO (Contains IDs, version, timestamp fields populated)

16. Operation: IngestContent  Description  Ingest a media file in repository  Operation Type  Asynchronous  Input Parameters  CoreEntity (Object to link to the file to)  EssenceLocator (Represent the pointer to the file to Ingest)  RepositoryProfile  Output Parameters  Ack  CallBack  BMO

17. Operation: DeleteContent  Description  Delete a media file in repository  Operation Type  Asynchronous  Input Parameters  EssenceLocatorID (ID of the essence locator to be deleted)  RepositoryProfile  Output Parameters  Ack  CallBack  BMO

18. Operation: Delete  Description  Delete all representation of a media asset (object and content) within repository  Operation Type  Asynchronous  Input Parameters  CoreEntity  RepositoryProfile  Output Parameters  Ack  CallBack  ResultOperationStatus

19. Operation: RetrieveSegment  Description  Retrieve segment of a media asset as an array of byte  Operation Type  Synchronous  Input Parameters  FormatProfileID (ID of the asset format to be retrieved)  ContentSegments  RepositoryProfile  Output Parameters  Raw bytes

20. Operation: Retrieve  Description  Copy media asset file to a given destination path  Operation Type  Asynchronous  Input Parameters  FormatProfileID  DestinationPath  RepositoryProfile  Output Parameters  Ack  CallBack  ResultOperationStatus

21. Operation: GetObject  Description  Hydrate a fully populated BMO by providing its ID  Operation Type  Synchronous  Input Parameters  CoreEntity  RepositoryProfile  Output Parameters  BMO

22. Operation: UpdateObject  Description  Update an object with new information passed in a BMO structure  Operation Type  Synchronous  Input Parameters  BMO  RepositoryProfile  Output Parameters  BMO (Updated BMO)

23. Operation: UpdateStatus  Description  Update the Status of a media asset. The possible status values are: Active Inactive Locked-CheckedOut Processing ??????  Operation Type  Synchronous  Input Parameters  CoreEntity  RepositoryProfile  Output Parameters  CoreEntity(CoreEntity with updated status)

24. Operation: Query  Description  Provide basic search capabilities by providing a search query against the BMO structure(see next slide)  Operation Type  Synchronous  Input Parameters  SearchQuery  RepositoryProfile  Output Parameters  List of BMOs

25. SearchQuery  SearchParameter  Name  Value  ValueType  MatchingCondition (equal, contains, greater,…)  SearchQuery  ParameterGroup1 ParameterRelationship: SearchParameter1, Search parameter2, Condition (or, and,…)  ParameterGroup2 ParameterRelationship: SearchParameter3, Search parameter2, Condition (or, and,…)  ParameterGroupRelationShip: group1, group2, Condition (or, and,…)

26. Operation: FireEvent  Description  Event fired by repository trigger by internal processing of the repository service. The event handler end point is configured within the repository settings  Operation Type  Synchronous Event  Input Parameters  EventEnvelop  EventPayload(TBD)  Output Parameters  Ack

27. Operation: CreateUID  Description  Generate unique identifier across all media objects  Operation Type  Synchronous  Input Parameters  ObjectType  Output Parameters  GUID

28. Operation: MapID  Description  Register an alternate ID as a unique ID for a media asset  Operation Type  Synchronous  Input Parameters  CoreEntity  AlternateID  AlternateIDType  Output Parameters  BMO

29. Operation: GetServiceCapabilities  Description  Get a properties list of implemented operations and configuration parameters of a repository service  Operation Type  Synchronous  Input Parameters  N/A ??  Output Parameters  PropertyList

30. Next Steps  WSDL  ?  XSD  ?