Copy of Dudas de insumos de contenidos

Se listan las dudas detectadas en la revisión de los documentos técnicos y XML de ADI y REVEL para trabajo con los equipos.

ID

Tema

Duda

Definición

Estatus

ID

Tema

Duda

Definición

Estatus

1

Archivos técnicos

El archivo NET_NOW_Content_Acquisition 30-08_2019.pdf es una actualización al documento Remote_Content_ADI.docx o éste último aplica para otro tipo de contenido?

O Doc NET NOW content Acquisition é o documento disponível atualmente nos provedores, o Doc Remote Contente_ADI é uma versão para deeplink e acesso a remoto a CDN de terceiros.

RESUELTO

2

Archivo XML

El archivo XML Exemplo_ADI_CDN ¿A que tipo de evento pertenece?

exemplo de ADI.XML para acesso remoto a CDN de terceiros ou APP

RESUELTO

3

Archivo: NET_NOW_Content_Acquisition 30-08_2019.pdf

Sección 2.1.1

Application meta-data

En la definición del Assets_ID se menciona:

En los ejemplos proporcionados vemos lo siguiente:

¿De dónde se obtienen esos 4 caracteres y los 16 números?

O campo Asset ID vem do provedor é um ID para cada classe onde foi definido esse padrão de 4 letras e 16 números. esse ID não pode se repetir entre os conteúdos.

El campo Asset ID proviene del proveedor y es un ID para cada clase donde se ha definido este estándar de 4 letras y 16 números. este ID no se puede repetir entre contenidos.

 

RESUELTO

4

Archivo: NET_NOW_Content_Acquisition 30-08_2019.pdf

Sección 2.1.1

Application meta-data

En la definición del Assets_ID se menciona lo siguiente:

Se entiende que el primer dígito de los 16 números debe ser:

1 para Movie

2 para Package

3 para Title

4 para Poster

5 para Preview

Sin embargo en los ejemplos proporcionados no se ve la relación. Adjunto imágenes:

Para el caso de Filme y Serie el valor es cero y ese valor no se encuentra dentro de la definición.

Esse campo é padronizado em 4 letras e 16 números, porem é livre para o provedor criar seu próprio ID. ex:

não precisa seguir uma ordem, apenas nao repetir entre as classes e entres os arquivos.

Este campo tiene por defecto 4 letras y 16 números definidos por el proveedor. No se necesita seguir un orden, simplemente no se debe repetir entre clases y entre archivos.

La imagen del documento hace referencia a que el Assets_ID tiene que ser diferente entre contenido del mismo tipo, es decir el caracter 5 debe ser único. El caracter 5 no indica el tipo de contenido.

Para identificar si pertenece a Movie, Package, Title, Poster o Preview se utiliza el atributo Assets_Class.

RESUELTO

5

Title meta-data

Para el atributo Actor se indica en el documento técnico NET_NOW_Content_Acquisition 30-08_2019.pdf que es un atributo requerido.

En los ejemplos se muestra lo siguiente:

¿Se debe considerar como requerido para todos los tipos de contenidos?

Sim, considerar o DOC como orientação.

Este dato debe ser requerido.

En el caso de que no venga en el XML del proveedor se debe buscar el dato en la base de AMCO, de no encontrarse en AMCO se debe buscar en Gracenote y al no encontrarse en esta base, se debe realizar una actualización manual.

 

 

POR VALIDAR

6

Title meta-data

Encontramos diferencias para el atributo Actor, en algunos casos solo se indica un valor y para otros casos se coloca en forma de lista, adjunto imágenes:

Películas

Serie

¿Existe alguna regla para hacer esa diferencia?

En la primera imagen que corresponde a un contenido de película vemos por el contenido del atributo Actors_Display que si existen otros valores. En este caso, ¿Se toma el actor principal?

¿Existe un límite para la cantidad de Actores a mostrar?

El valor para el atributo Actor viene del proveedor, para este dato se considerar lo siguiente:

  1. Se deben almacenar todos los valores enviados por el proveedor.

  2. La nomenclatura para este campo debe mantenerse: Last Name + First Name.

POR VALIDAR

7

Title meta-data

El atributo Actor_Display se indica que es un atributo requerido.

En los ejemplos se muestra lo siguiente:

¿Se debe considerar como requerido para todos los tipos de contenidos?

Para el atributo Actor_Display se deben concatenar los valores de los atributos Actors, considerando lo siguiente:

  1. Se debe mantener la estructura actual: First Name + Last Name ya que este dato es el que se toma para presentarlo al usuario final en las búsquedas.

POR VALIDAR

8

Title meta-data

Para el atributo Actors_Display se visualiza que el orden de concatenación corresponde al orden de aparición en la lista.

Película

Serie

Para este escenario, en que solo se visualiza un actor, pero existen otro valores. ¿Cuál es el ordenamiento definido?

Para este escenario, dónde no existe un valor para el atributo Actors, ¿De dónde se obtiene el valor para el atributo Actors_Display?

Esto se solventa con el punto anterior.

Para el último escenario indicado en este punto, en el caso de que el XML no contenga un atributo ACTORS se debe buscar en la base de AMCO, de no encontrarse en AMCO se debe buscar en Gracenote y al no encontrarse en esta base, se debe realizar una actualización manual.

POR VALIDAR

9

Title meta-data

El atributo Director se indica que es un atributo requerido.

En los ejemplos se muestra lo siguiente:

¿Se debe considerar como requerido para todos los tipos de contenidos?

¿En caso de que exista más de un director se debe mostrar en forma de lista a como se presenta el atributo actores?

Para este proyecto debe configurarse como requerido.

Puede haber más de un Director por contenido, por lo que se debe agregar tantos atributos Director como Directores existan.

POR VALIDAR

10

Title meta-data

En los ejemplos se visualiza que para el atributo Director_Display siempre es un valor.

¿Esto es regla? o en caso de que exista más de un director, ¿Se debe concatenar de la misma forma que el atributo de actores?

Se debe concatenar de la misma forma que Actors_Display.

  1. Separados por comas

  2. Last Name + First Name

POR VALIDAR

11

Title meta-data

Para el atributo Categoría vemos diferencias en la estructura.

¿Esto es una concatenación de valores o es un valor que ya se encuentra definido? En el documento técnico se menciona un cambio de ADI++

Este atributo hace referencia a la dirección dónde se localizan los assets físicos dentro del catálogo de VOD de Claro.

Se debe almacenar este dato como viene en el XML y así se enviará a SeaChange.

POR VALIDAR

12

Title meta-data

El atributo Contract_Name se indica que es un atributo requerido.

En los ejemplos se visualiza lo siguiente:

Si en este campo es donde se guarda el nombre original del contenido. ¿Debería considerarse como requerido para todos los tipos de contenido?

Es el título del contenido en Portugués y es el más utilizado.

Se solicitara a los proveedores proporcionen este dato.

POR VALIDAR

13

Title meta-data

Siguiendo los ejemplos proporcionados. ¿El atributo ExtraData_1 solo es requerido para los contenidos Serie?

De los ejemplos, ¿Los valores para este atributo a que hacen referencia?

Este atributo es un campo customizado para Claro, cada número representa a un proveedor.

Se enviará catálogo.

POR VALIDAR

14

Movie meta-data

Los atributos Subtitle_Languages y Dubbed_Languages se indican que son requeridos.

En los ejemplos se visualiza lo siguiente:

¿Se deben considerar como requeridos para todos los tipos de contenidos?

Cuando es un contenido nacional estos 2 valores pueden venir vacío.

Cuando no es un contenido nacional debe venir al menos uno de los 2 valores.

POR VALIDAR

15

Movie meta-data

Siguiendo los ejemplos proporcionados. ¿Los atributos Content_FileSize y Content_CheckSum solo son requeridos para los contenidos Película y Serie?

Content_FileSize solo es requerido para contenidos ingestados dentro de la infraestructura de Claro, dónde hay un deeplink no es requerido.

 

POR VALIDAR

16

Poster meta-data

Preview meta-data

Los grupos de meta-data Poster y Preview no se incluyen en el documento normativo, sin embargo se muestran sus atributos en algunos ejemplos.

¿Para que tipo de contenido aplicarían estos grupos?

El equipo de Brasil proporcionará información de estas secciones que no se encuentra en el documento normativo.

PENDIENTE