MP-Anything 3.x JSON Specification

Introduction

Third version of MP-Anything JSON specification includes several important enhancements to the 2.x model:

 

  • Photo preselections and rubrics evolved in Hubert. Version 3.x embraces the new types of preselections and rubrics.
  • To simplify handling and querying – the production node disappears – new rubric/preselection information is able to replace it.
  • Preselection nodes now are able to deliver full infomation about the selected photo.
  • Photo information has been refined.

The top-level structure of JSON MP-Anything looks like follows:

 

 {
    "id": "<unique id>",
    "record": { 
       "version": "3.0",
       "lastModified": "<last modified timestamp>",
       "lastModifiedEpoch": <last modified epoch>,
       "<root schema>": { <root schema content> },
       "<extension schema 1>": { <extension schema 1 content },
       "<extension schema 2>": { <extension schema 2 content },
       …
    }
 }

Which relates to the extension chain defined for the root schema. There is one attribute on the global level here:

 

  • id – unique id of the exported record (root schema name plus root schema record unique id). This id is handy when record is inserted to one of the NoSQL databases. They usually need it as the primary key. In case of file-based exports this id is also the file name.

Root record node has the following attributes:

 

  • version – current version of the export format
  • lastModified – timestamp of the export file creation
  • lastModifiedEpoch – epoch of the export file creation

 

Schema object

Schema object name is equal to the JSON alias ” of the FRED schema (“camelized”) and contains all data connected to the FRED content.

Each schema object has the same basic structure:

 

 {
    <collection of technical attributes>,
    <collection of schema fields>,
    "workflowStates": [ <collection of states> ],
    "preselections": [ <simplified collection of preselections> ],
    "preselectionDetails": [ <detailed collection of preselections> ], 
    "rubrics": [ <simplified collection of rubrics> ],
    "rubricDetails": [ <detailed collection of rubrics> ], 
    "links": [ <collection of links groups> ], 
    "typologies": [ <collection of type information> ],
    "histories": [ <collection of history items> ],
    "attachments": [ <collection of attachments ]
 }

Technical attributes collection describe all identifiers, and other data that is common to the records in FRED database:

 

  • externalId – external id of the content. It is present when the content has been imported to FRED from external source and contains the id of the record it has been imported from.
  • id – internal id of the content in the FRED database
  • isDeleted – flag is set to true if the record is deleted
  • extension – id of the content that is an extension of the content. If equal to 0 or not present – the record does not have an extension.
  • modified – timestamp of last modification of the content
  • created – timestamp of content creation

Furthermore, if the content is the root content (which means that it is connected to the channel), the following channel properties may be present as the attributes:

 

  • channelName – short name of the channel
  • regionNames – comma separated list of region shortcuts when the event is emitted on the channel that has regions (presented as the array _regionNames in JSON format).
  • airDate – channel defined date of the content
  • airDateEpoch – channel defined date of the content (in epoch format)
  • startDate – calendar date of the start of the content
  • endDate – calendar date of the end of the content
  • startTime – channel defined start time of the content
  • endTime – channel defined end time of the content
  • start – calendar date/time of the start of the content
  • end – calendar date/time of the end of the content

Start/end parameters are duplicated to enable the scenarios in which either calendar or emission dates are used.

 

Schema fields

Inside of the Schema record node, you will find the schema field nodes used to export the fields. They are formatted in the following way:

 

 "fields":
 {
    "schema field name 1": <schema field value>,   
    "schema field name 2": <schema field value>,
    ...
 }

Thanks to this, they are clearly separated from the system fields and no name conflict can occur.

NOTE: if the export is mapper-based, this section contains the mapper fields and their values.

 

Single language and multi-language versions

Depending on the export settings, data can be exported either as single-language (as above) or multi-language. In the multi-language configuration, output of the “fields” structure differs and looks like this:

 

    "fields_en": 
    {
       ...
    },
    "fields_de":
    {
       ...
    },
    ...  // (fields for other languages exported)
    "fields":
    {
       ...
    }

In the language dependent section (“fields_de” etc), system will export all multilanguage fields that have the value in the language context plus all single-language fields. In this type of output all single-language fields are exported multiple times in each language dependent section and in the language independent section (“fields”). This of course makes the export file bigger but also greatly simplifies the querying of the data.

NOTE: When the field is marked with the Suppress FTS flag in the schema configuration it is exported only in the “fields” section. This flag means that the field does not bring any textual information. It makes sense to switch it on for the string identifiers for instance.

 

Workflow states

If the data workflows are defined in the selected areas, the section workflowStates contains the array of the record states in all workflows. The element of the array has the following structure:

 

"workflowStates": 
[ 
   { 
      "state": 
      { 
         "id": "<workflow id>", 
         "name": "<workflow name>" 
      }, 
      "name": "<state name>", 
      "value": <state value>, 
      "color": "<state color (as HEX string)>", 
      "user": "<user setting state>", 
      "timestamp": "<timestamp of state change>" 
   }, 
   ...
]

 

Preselections array

During production, the numerous photos that are attached to the content can be chosen for production (e.g by placing on the layout). The preselectionsarray provides quick information about this selection and is optimized for NoSQL queries.

The array consists of preselection ids (strings). Each string defines the photo selected and the context of the selection. Each is composed out of four parts divided with the $ sign:

 

  1. Product axis – defining the scope of the selection in relation to product/column. It can have one of the following forms:
    • <product json alias>_<column json alias> – when this is column level selection
    • <product json alias> – when this is product level selection
    • be empty when the selection is global
  2. JSON alias of preselection
  3. Time axis – defining the scope of selection in relation to time. It can have one of the following forms:
    • <issue year>_<issue number> – when this is the product issue selection
    • <date from>_<date to> – when this is the time range selection
    • be empty when the selection is global
  4. Phoboss mediafile id (sha1)

Regardless of which elements are empty – the preselection id always contains three $ signs.

For example:

 

"preselections":
[
   "$preselection1$$416f984f7f0dbb242bc038f336a0c128c65ec37b", /* global/always */
   "$preselection2$20160110_20161212$416f984f7f0dbb242bc038f336a0c128c65ec37b", /* global/range */
   "product1$preselection3$$416f984f7f0dbb242bc038f336a0c128c65ec37b", /* product/always */
   "product1$preselection4$issueyear_issuenr$416f984f7f0dbb242bc038f336a0c128c65ec37b", /* product/issue */
   "product1$preselection5$20160110_20161212$416f984f7f0dbb242bc038f336a0c128c65ec37b", /* product/range */
   "product1_column1$preselection6$$416f984f7f0dbb242bc038f336a0c128c65ec37b", /* column/always */
   "product1_column1$preselection7$issueyear_issuenr$416f984f7f0dbb242bc038f336a0c128c65ec37b", /* column/issue */
   "product1_column1$preselection8$20160110_20161212$416f984f7f0dbb242bc038f336a0c128c65ec37b" /* column/range */
]

 

Preselection details array

Beside of the simplified form, MP-Anything format also delivers more complete information about photo selections in form of preselectionDetailsarray. This array consists of objects of the following structure:

 

{
   "name": "<full preselection id>";
   "order": <order of preselection>,
   "legends": [ <array of photo legends> ],
   "frames": [ <array of the crop definitions> ],
   "selectedMediaFile": { <selected mediafile descr.> },
   "mediaRecord": { <selected mediarecord descr.> }
}

The elements of frames array have the following structure:

 

{
   "type": <crop type id>,
   "name": "<crop type name>",
   "cutx": <left upper corner of crop in pixels>,
   "cuty": <left upper corner of crop in pixels>,
   "cutw": <width of crop area>,
   "cuth": <height of crop area>,
   "approved": <is the cut approved by human? (bool)>
}

The following types of crop (and id’s) are possible:

 

  1. Automatic – the cut has been done automatically by Hubert
  2. Manual – cut has been created by human being
  3. Preferred cut – cut that shows the most important motive of the photo. Used for automatic scaling to the frames of different proportions.
  4. Based on mutation parent – cut has been inherited from the master product in the mutation process.

selectedMediaFile and mediaRecord objects are in the form specified in the chapter about Attachments.

 

Rubrics array

When the content is selected to one or more rubrics in the Hubert system, the rubrics arrray will be exported to inform the external systems about this fact.

The rubricsarray provides quick information about the selection and is optimized for NoSQL queries.

The array consists of rubric ids (strings). Each string defines the context of the selection. Each is composed out of four parts divided with the $ sign:

 

  1. Product axis – defining the scope of the selection in relation to product/column. It can have one of the following forms:
    • <product json alias>_<column json alias> – when this is column level selection
    • <product json alias> – when this is product level selection
    • be empty when the selection is global
  2. JSON alias of rubric
  3. Time axis – defining the scope of selection in relation to time. It can have one of the following forms:
    • <issue year>_<issue number> – when this is the product issue selection
    • <date from>_<date to> – when this is the time range selection
    • be empty when the selection is global
  4. Sort/layout type – in one of the following forms:
    • <sort>_<layout type>
    • <sort>_ – if the layout type is empty
    • empty

Regardless of which elements are empty – the rubric id always contains three $ signs.

For example:

 

"rubrics": [
    "product1_column1$rubric1$$sort_lt",
    "product1_column1$rubric1$20160110_20161212$sort_lt",
    "product1_column1$rubric1$issueyear_issuenr$sort_lt", 
]

Rubric details array

Beside of the simplified form, MP-Anything format also delivers more complete information about rubric selections in form of rubricDetailsarray. This array consists of objects of the following structure:

 

{
   "name": "<rubric id>",
   "product": "<product JSON alias>",
   "issueId": <issue id>,
   "issueYear": <issue year>,
   "issueNumber": <issue number>,
   "column": "<column JSON alias>",
   "rubric": "<rubric JSON alias>",
   "from": "<from date/time>", 
   "to": "<to date/time>",
   "sort": <sort>,
   "layoutTypeId": <layout type id>,
   "layoutTypeName": "<layout type name>"
}

Please note that according to the type of rubric, some of those fields may be empty.

 

Links node

In Hubert/FRED system, records can be linked to create relations between them. In MP-Anything format, those links are flatten to form the hierarchical structure, easy to handle in the document-oriented databases. All those references are present in the links node. This node has the following structure:

 

 "links": {
    "<linking path>": [
       {
          "created": "2014-06-06T10:22:58+02:00",
          "createdEpoch": 1402050178,
          "modified": "2014-06-06T10:22:58+02:00",
          "modifiedEpoch": 1402050178,
          "linkId": 5,
          "childId": 5716820,
          "parentId": 62638571,
          "record": { <schema record> }
       },
       ...
    ]
    ...
 ]

So basically the links node is the container for numerous link arrays.

 

Linking path node

Linking path is the special field name constructed as the concatenation of link names divided by the underscore sign. For instance if the record link has the name lnk4 and then it links to lnk5, the link path is constructed as lnk4_lnk5. Of course it can also be longer – in more complicated scenario it can be lnk4_lnk5_lnk21_lnk33

links object can contain a number of the linking paths. Each of them contains the array of link objects.

 

Link object

Link object describes the item attached to the linking path. It can have the following attributes:

 

  • created – timestamp of the link creation
  • createdEpoch – timestam of the link creation in epoch format
  • modified – timestamp of last link modification
  • modifiedEpoch – timestamp of last link modification in epoch format
  • linkId – id of the link in the schema definition
  • childId – id of the record attached in the link
  • parentId – id of record that is the parent in the link
  • record – schema record attached in the link

Thanks to the linking path node this structure is flat – no recurrence is needed when the JSON file is processed.

 

Typologies node

Typologies node is exported either in the language dependent portion of the record (for multilanguage exports) or on the schema level (single language exports). It contains information about the id’s of all typologies assigned to the record. The structure looks like following:

 

 "typologies": [
     {
        "name": "<name>",
        "fullName": "<full name>",
        "instances": [
          {
            "name": "tv_content_PR_BASE",
            "order": 0,
            "key": "7.41.213.1295",
            "levels": [
              7,
              41,
              213,
              1295
            ]
          }
        ]
     }
  ]

For each typology there is the typology node with the following attributes:

 

  • name – short name of typology
  • fullName – full name of typology
  • instances – array of instances of the typology classification

Instance object have the following fields:

 

  • name – name of the instance
  • order – order of the instance (zero base)
  • key – this subnode contains the path of typology id’s which can be use as the key to the typology converters delivered in typologies.json (see Configuration files chapter).
  • levels – this subnode contains the path of typology id’s in the form of indexed subnodes.

 

Histories node

This node appears only when the export of content occurences is enabled in the export configuration. The node has the following structure:

 

     "histories":
     [
          {
              "externalId": "NEXT:GDM71310330",
              "channelName": "ARD_D",
              "airDate": "2016-01-20Z",
              "airDateEpoch": 1453248000,
              "startDate": "2016-01-20Z",
              "startTime": "14:10:00Z",
              "start": "2016-01-20T14:10:00Z",
        },
        ...
    ]

So the histories is actually the array of objects describing the past and future occurences of the content in the time line.

 

Attachments node

attachments array contains the information about Phoboss photos/videos connected to the content. Depending of the Oxana project settings the array objects can be in one of two formats: legacy or extended.

 

Legacy format

Legacy format is basically the same format as it is defined in MP-Anytime 2.x specification plus optional information about the size of the photo and media file/media record ids. Resulting JSON fragment describing the attachment will look as follows:

 

{
   "attachmentId": "<sha1 of mediafile>",
   "areaId": "<area GUID>",
   "mediaFileId": <id of media file>,
   "mediaRecordId": <id of media record>,
   "width": <width of photo in pixels>,
   "height": <height of photo in pixels>,
   "isAutomatic": <true if photo has been attached by automat>
}

 

Extended format

You can get much more information about the photos switching the export to the Extended format. In its simplest form the export will look as follows:

 

"attachments":
[
   {
      "id": 4408125,
      "orientation": "horizontal",
      "type": "Scene",
      "attachmentArea": "mediapress",
      "mediaFiles": 
      [
         {
            "id": "a25358af0fa0af4f6a55d575ed20ca33e192625c",
            "areaId": "1f04a0a3-0851-4d0d-b66d-268163ef69a9",
            "width": 2598,
            "height": 1732,
            "fileLength": 0,
            "fileExt": null,
            "colorType": "TrueColor",
            "colorSpace": "sRGB"
          },
          ...
      ]
   },
   ...
]

The photos are described by:

 

  • id – identifier of the media record. Media record is the entity grouping the duplicate (or very similar) photos.
  • orientation – orientation of the photo. Can be either horizontal or vertical.
  • type – general type of the photo. It can be one of the following:
    • Scene – general scene (most commonly used type)
    • Poster
    • Title card
    • Cover – DVD/CD/BD cover
    • Actor
    • Generic
    • Genre – iconic photo for the movei genre
    • Face – photo of the face of person
    • Logo – logo of the broadcast
    • Trailer – trailer of the movid
  • attachmentArea – name of the area in which the photo was attached to the record.
  • mediaFile – collection of descriptions of the photos that are grouped by the media record.

 Each media file can have the following properties:

 

  • id – identifier of the media file
  • uploadArea – name of the area in which the media file has been uploaded to Phoboss
  • width – width of photo in pixels
  • height – height of photo in pixels
  • barcutWidth – sometimes broadcaster puts an additional bar on the photo with the extra information. Phoboss keeps the version of these photos with and wihout the bar. This parameter describes width of the photo after the bar is removed.
  • barcutHeight – as above. Height of the photo after the bar is removed
  • fileLength – lenght of the photo file in bytes
  • fileExt – extension/type of the photo file
  • colorType – color type of the media file. It can be one of the following values:
    • Undefined
    • Bilevel
    • Grayscale
    • GrayscaleAlpha
    • Palette
    • PaletteAlpha
    • TrueColor
    • TrueColorAlpha
    • ColorSeparation
    • ColorSeparationAlpha
    • Optimize
    • PaletteBilevelAlpha
  • colorSpace – color space of the media file. It can be one of the following values:
    • Undefined
    • CMY
    • CMYK
    • Gray
    • HCL
    • HCLp
    • HSB
    • HSI
    • HSL
    • HSV
    • HWB
    • Lab
    • LCH
    • LCHab
    • LCHuv
    • Log
    • LMS
    • Luv
    • OHTA
    • Rec601YCbCr
    • Rec709YCbCr
    • RGB
    • scRGB
    • sRGB
    • Transparent
    • XyY
    • XYZ
    • YCbCr
    • YCC
    • YDbDr
    • YIQ
    • YPbPr
    • YUV

 

Extended format options

There is a number of additional options, that allow you to shape the extended format exports.

 

Export keywords

When this option is chosen, along with the technical information about the photo, also the Phoboss metadata is exported. Phoboss metadata includes all additional textual information that was added to the photo by users (Phoboss keywords). This information can be exported in two forms determined by the Strategy setting on export definition:

 

  • FULL – exports all keywords from all selected areas but without additional logic that would include keywords from areas specified in the area2area settings.
  • FLATTENED (recommended) – exports all keywords from all selected areas as they are visible in Hubert system / Phoboss.

The keywords are exported in the following form:

 

{
   "id": 2660587,
   "orientation": "horizontal",
   "type": "Scene",
   "attachmentArea": "mediapress",
   "keywords": 
   {
      "jTvSubtitle": "Der letzte Vorhang",
      "jTvBroadcastType": "***",
      "jTvBroadcastSubtype": "Mysteryserie",
      "jTvLegend": "Jim (David Conrad, l.), Melinda (Jennifer Love Hewitt, M.) und Andrea Moreno (Aisha Tyler, r.) wollen einen entspannten Abend im Comedy Club verbringen, doch es kommt mal wieder ein Geist dazwischen ...",
      "jTvAdditionalInfo": "Author: ; Keywords: ; Rating: 0; Subject:",
      "jTvTitle": "Ghost Whisperer - Stimmen aus dem Jenseits",
      "jTvCastActor": [
         "David Conrad","Jennifer Love Hewitt","Aisha Tyler" ],
      "jTvProductionYearFrom": 2005,
      "jTvOriginalSubtitle": "Undead Comic",
      "jTvDirector": "Eric Laneuville",
   },
}

As you can see, this option adds keywords object to the media record description. This object includes all non empty keywords defined in the Phoboss admin for the exported areas.

 

Export url / Export preview url

Sometimes it would be handy to have the full urls to the photo and its thumbnail already in the export. By switching on the proper options you can provide exporting system with the templates where you can enter the custom url with the macro %ID% which will be expanded to the media file id. In result, new properties will be added to the media file description:

 

"url": "https://cdn.mysite.com/8e7a1ec8f088e06a4bbb7d8df54c36c415b8d210",
"previewUrl": "https://cdn.mysite.com/thumbnail/8e7a1ec8f088e06a4bbb7d8df54c36c415b8d210"

 

Indicate best file

As the media record can have multiples media files attached, it is sometimes difficult to choose the one that will be the best for a purpose. Oxana provides you with the way to automatically choose the best media file for you in the form of Indicate best file option. Choosing this option enables the Strategy combo box where you can define how the best photo should be chosen:

 

  • COPYRIGHT_SIZE – chooses the photos with best matching copyright and among them – chooses the one with the highest resolution
  • SIZE_COPYRIGHT – chooses the photos with the highest resolution and among them chooses the one with the best matching copyright

Switching this option on, adds an additional object to the media record description: bestMediaFile containing the data about the chosem mediafile. It also adds the isBest boolean field to each of the media files:

 

"attachments": [
        {
          "id": 5488385,
          "orientation": "horizontal",
          "type": "Scene",
          "attachmentArea": "mediapress",
          "bestMediaFile": 
            {
              "id": "480e21c94f86bb373591dc4df20be212c8a05395",
              "areaId": "1f04a0a3-0851-4d0d-b66d-268163ef69a9",
              "width": 2953,
              "height": 1949,
              "barcutWidth": 2953,
              "barcutHeight": 1949,
              "fileLength": 3990259,
              "fileExt": "JPG",
              "colorType": "TrueColor",
              "colorSpace": "sRGB",
              "isBest": true,
            },
          "mediaFiles": [
            {
              "id": "480e21c94586bb373591dc4df20be212c8a05332,
              "areaId": "1f04a0a3-0851-4d0d-b66d-268163ef69a9",
              "width": 2953,
              "height": 1949,
              "barcutWidth": 2953,
              "barcutHeight": 1949,
              "fileLength": 3990259,
              "fileExt": "JPG",
              "colorType": "TrueColor",
              "colorSpace": "sRGB",
              "isBest": false,
            }, ...

If the option Export only best file is selected, system exports only the bestMediaFile object and does not export mediaFiles array.

 

Export copyrights

Switchin this option on, adds an object copyright to the media file description:

 

{
   "id": "480e21c94f86bb373591dc4df20be212c8a05395",
   "areaId": "1f04a0a3-0851-4d0d-b66d-268163ef69a9",
   "width": 2953,
   "height": 1949,
   "barcutWidth": 2953,
   "barcutHeight": 1949,
   "fileLength": 3990259,
   "fileExt": "JPG",
   "colorType": "TrueColor",
   "colorSpace": "sRGB",
   "isBest": true,
   "copyright": 
   {
      "id": 9391148,
      "level": "unrestricted",
      "isFree": true,
      "channelGroupMatch": false,
      "channelMatch": false,
      "emissionMatch": false,
      "area": "mediapress",
   }
}

copyright object contains a number of properties:

 

  • id – internal id of the copyright
  • level – level of restriction imposed by the copyright. It can have the following values:
    • unrestricted – photo is free to use on any channel and no time restrictions are in place
    • channelRestricted – photo usage is restricted to the particular channel / group of channels
    • emissionRestricted – photo usage is restricted to the particular emission on particular channel / group of channels
  • isFree – true when the photo usage does not require payment to the photo agency
  • channelGroupMatch – true if the photo is used on the channel that belongs to the allowed group of channels
  • channelMatch – true if the photo is used on the channel that it is licensed to
  • emissionMatch – true if the photo is used for the emission it is licesed to
  • area – area in which the copyright has been created

When the Export copyright description is checked, object copyright also includes the description field, containing the textual description of the copyright extracted from the photo.

Because of the fact, that the same media file can be acquired from multiple sources and bear multiple copyrights, there is a need to specify the strategy of choosing the best copyright. Stategy option allows you to choose how the best copyright will be determined:

 

  • BEST_MATCHING_FREE – This strategy ensures that the copyright chosen matches the restriction level and that the selected photo is free. If the copyright fulfilling these conditions is not found, copyright object is not exported
  • BEST_MATCHING_PAID – This strategy ensures that the copyright chosen matches the restriction level and that the selected photo is commercial. If the copyright fulfilling these conditions is not found, copyright object is not exported
  • BEST_MATCHING – This strategy ensures that the copyright chosen matches the restriction level regardless of the the fact that it is free or commercial (preferring free). If the copyright fulfilling these conditions is not found, copyright object is not exported
  • BEST_PAID – This strategy does not guarantee the the copyright chosen matches the restriction level (although it triest to find the best match). But guarantees that the copyright choosen is commercial.
  • BEST_FREE – This strategy does not guarantee the the copyright chosen matches the restriction level (although it triest to find the best match). But guarantees that the copyright choosen is free.
  • BEST -This strategy does not guarantee the the copyright chosen matches the restriction level (although it triest to find the best match). It just chooses of the copyrights that matches best.

 

Configuration files

Files in the MP-Anything format contain a number of references to the configuration. To make the data complete, MP-Anything exports deliver couple of additional JSON files.

 

Channels.json

This file contains detailed definition of channels used in export. It has the following structure:

 

 <channels>
    <channel>
       <description>
       <schema>
       <parent-id>
       <timeline-type>
       <regions>
          <region>
          … 
       </regions>
    </channel>
    …
 </channels>

 

Channel node

Channel node describes single channel. It can have the following attributes:

 

  • id – unique id of the channel
  • name – short name of the channel
  • fullName – human readable name of the channel
  • externalId – name/id of the channel in external system if the channel is imported from other database
  • utcOffset – offset of the time in channel data according to UTC
  • lang – default language of the channel

Channel node can have the following subnodes:

 

  • description – verbose description of the channel
  • schema – name of the schema used to define events attached to the channel
  • parent – name of the channel that is the parent channel (channels can form the nested structure). It also has attribute id containing the id of the parent channel
  • timelineType – describes the way events are attached to the channel. Attribute id describes the id of the type. We can have the following types:
    • point – (0) each event has the start and event in the channel and the duration of the event is bound to the difference between end and start times (e.g. normal TV channel).
    • range – (1) start and end are not related to the duration of the event. Instead they describe the period when the event is available (e.g. VOD channels).
    • none – (2) events attached to the channel are not related to time. Channels of this type are a kind of bag for contents.
  • regions – subnode grouping the description of the regional variations of the channel (see below).

 

Region node

Region node describes the regional part of the channel. The node can have the following attributes:

 

  • id – unique id of the region
  • name – region name
  • fullName – human readable name of the region
  • externalId – name/id of the region in external system if the region is imported from other database
  • isMain – Boolean value describing if the region is default for the channel.

 

Rubrics.json

All rubrics used in export are described in the rubrics.xml file. Structure of this file looks as follows:

 

 <rubrics>
    <rubric>
       <schema>
       <color>
       <timeline-types>
          <timeline-type>
          …  
       </timeline-types>
       <properties>
          <property>
             <layout-types>
                <type>
                … 
             </layout-types>
          </property>
          …
       </properties>
    </rubric>
    …
 </rubrics>

 

Rubric node

Rubric node describes the single rubric. It can have the following attributes:

 

  • id – unique id of the rubric
  • name – short version of the rubric name
  • fullName – human readable name of the rubric
  • isVirtual – Boolean value describing whether the rubric is virtual (automatic) or manual.

Rubric node can also have several subnodes:

 

  • schema – name of the schema of records selected to the rubric
  • color – color of the rubric in Hubert system. In the form #AARRGGBB (where A is alpha channel, R – red channel, G – green chanel and B – blue channel. All in hexadecimal)
  • timelineTypes – grouping node for one or mode timeline-type nodes describing the timeline types that are active for the rubric (for timeline type description please refer to channels.xml definition).

 

Properties and property node

Each rubric can be bound to one or more sets of properties. Property set describes the values connected with the selection of the record in the context of product. This approach allows us to use the same rubric (record selection) in couple of different products. Property node can have the following attributes:

 

  • id – unique id of the property set
  • name – short version of the property set name
  • fullName – human readable name of the property set
  • layoutTypes – description of the enum that describes layout types available for the rubric.
    • id – id of the enum
    • name – name of the enum
    • types – array of the names of the types

 

Products.json

This file contains the information on the structure and state of Hubert products referenced in the MP-Anything export. Structure of this file looks like this:

 

 <products>
    <product>
       <configuration>
          <columns>
             <column>
                <channels>
                   <channel>
                      <regions>
                         <region>
                      </regions>
                   </channel>
                </channels>
                <rubrics>
                   <rubric>
                </rubric>
             </column>
          </columns>
          <states>
             <state>
          </states>
          <issues>
             <issue>
          </issues>
       </configuration>
    </product>
 </products>

 

Product node

Product node describes the single product (object, magazine) used in the export. It has the following attributes:

 

  • id – unique id of the product
  • name – short version of the product name
  • fullName – human readable name of the product

Each product can have multiple configurations that describe the changes made to the product structure over time. Those configurations are described within the configuration node.

 

Configuration node

This node describes single configuration of the product. It can have the following attributes:

 

  • id – unique id of the configuration
  • name – configuration name
  • validFromIssue – number of issue from which this configuration is active
  • validFromYear – year from which this configuration is active
  • validToIssue – last issue for which this configuration is active
  • validToYear – year for which this configuration is active
  • folder – folder in the Hubert system where the working files and pages for the configuration are stored (HFS link)
  • startsOn – index of the first day of issue. 0 – Saturday, 1 – Sunday, 2 – Monday … etc
  • period – number of days of the issue (7 – weekly magazine, 14 – biweekly etc)

 

Columns and Column nodes

Each configuration of the product has a number of columns. Column describes the set of data and its connection with the product structure. Column node can have the following attributes:

 

  • id – unique id of the column within configuration
  • logicalId – unique id of the column within product. This id can be used to link the appropriate columns between configurations.
  • name – short column name
  • fullName – human readable column name
  • schema – name of the schema of the records in the column
  • dayBegin – time when the column day begins

Each column contains the ordered collection of either channels or rubrics (never both). These collections are described in the form of channels and rubrics nodes.

 

Channels and Channel nodes

Each channel in column can have the following attributes:

 

  • id – unique id of the channel (reference to channels.json)
  • name – name of the channel
  • fullName – full name of the channel
  • dayBegin – time when the channel begins within the column

As channels can consist of multiple regions, column node can have subnode regions.

 

Regions and Region nodes

Each region in the context of the column can have following attributes:

 

  • id – unique id of the region (reference to channels.json)
  • name – name of the region
  • externald – external id of the region

 

Rubrics and rubric nodes

Rubrics node groups the rubrics of the column. It can have the attribute property-group that is the reference to one of property groups defined in rubrics.json

Rubric node describes the rubric of the column. It can have the following attributes:

 

  • id – unique id of the rubric (reference to rubrics.json)
  • name – name of the rubric
  • fullName – full name of the rubric

 

States and state nodes

For each configuration, there can be a number of production (workflow) states defined. Those definitions are exported under the States node. Each state node have the numeric id (exported as attribute) and human readable name (exported as content of the node).

 

Issues and Issue nodes

The Issues node groups information about issues of the product present in the system. Issue node can have the following attributes:

 

  • number – number of the issue
  • year – year of the issue
  • start – start date of the issue
  • end – end date of the issue
  • id – numerical id of the issue
  • issueState – id of the lowest state of the element of issue

 

Schemas.json

This file describes structure of the data exported – it lists all schemas used, all fields defined within them and the links between them. Structure of the file is like follows:

 

 <schemas>
    <schema>
       <description>
       <extended-by>
       <fields>
          <field>
          …
       </fields>
       <link-groups>
          <link-group>
             <fullnames>
                <fullname>
                …
             </fullnames>
          </link-group>
          …
       </link-groups>
    </schema>
    …
 </schemas>

 

Schema node

Schema node describes a chunk of data (record/FRED content) in the export file. It can have the following attributes:

 

  • id – unique id of the schema
  • name – short version of the schema name
  • fullName – human readable name of the schema
  • isTimeline – Boolean value describing if the schema can be attached to the channel

It can also have subnodes:

 

  • description – description of the schema
  • extendedBy – id and short name of the schema that is the direct extension to the current schema

 

Fields and Field nodes

Schema can contain a number of field definitions. Each definition (field node) can contain following attributes:

 

  • id – unique id of the field
  • name – short version of the field name
  • fullName – human readable name of the field
  • type – type of the field
  • enumId – id of the enum if the field is the ENUM type
  • typologyId – id of the typology if the field is the TYPOLOGY type
  • isMultilanguage – Boolean value describing if the field can contain Multilanguage values

Field nodes can also have the description subnode containing the description of the field.

 

Link groups and links

Each content can have multiple links grouped into number of link groups. Each link group node can contain the following attributes:

 

  • id – unique id of the link group
  • name – short version of the link group name
  • fullName – human readable name of the group name
  • schema – name of the linked schema
  • isSingleUplink – Boolean value denoting that the contents in the link group can only have one parent
  • maxLinks – maximal number of links in the group

Link group nodes can also have the full-names subnode containing the human readable names of the link-group for different languages.

 

Typologies.json

This file describes the typology structures that are used in the export. It has the structure equivalent to its XML counterpart.

Typology node

This node describes the single typology. It has the following attributes:

 

  • name – short name of typology
  • fullName – full name of typology

It also has the level  and converters subnodes.

 

Level subnode

Level subnode describes the single level of the typology structure. It can have the following attributes:

 

  • name – short name of the level
  • fullName – full name of the level

Each level can have the number of item subnodes.

 

Item subnode

Item subnode defines the single typology item. It can have the following attributes:

 

  • id – id of the item
  • externalI– external id of the item if the typology has been imported from external source
  • invName – language invariant name of the item

Each item can have the names/name subnodes with the names of the item in different languages. It can also have the level subnode to describe the hierarchical structure of the typology

 

Converters/converter nodes

This node serves as the container for one or more converter nodes. Each converter node describes one typology converter defined for typology. Each converter can have the following attributes:

 

  • name – short name of the converter
  • fullName – full name of the converter

It can also have a number of item subnodes describing the conversion. Each item will have two attributes:

 

  • key – typology path delimited with dots
  • value – textual value of the converter item

The key can be used for easy look up of the typology exported within the data (node typologies/typology/key).

Documentation

General
Rubric Assignment Logic
Rubric Validation
Photo Copyright Indicators
App Nap and Edward

Hubert CMS concepts
Overview

OXANA
OXANA Overview
OXANA Administration Panel
Mapper export configuration
Delivery models

MP-Anything Format
MP-Anything Introduction
MP-Anything 3.x.JSON Specification

Hubert API
Overview
Specification

Photoboss API
Overview
Specification

Permissions (ACL’s)
No Comments

Sorry, the comment form is closed at this time.