NewsML-G2 2.35

Preview. Built from the published NewsML-G2 documents by tools/prosedoc. This layout is a harness for reviewing structure — it is not the published site.

2. Representing News newsItem

An XML Schema file corresponding to the specifications for this item is available (see The Full Set of Specification Documents)

2.1. Description

A newsItem aims to convey news with the sense of the reporting of a newsworthy event or fact. Its content is gathered by journalists, presented with a journalistic style, and updated according to the progression of the story.

Examples of newsItems are a news report, a picture, a graphical illustration of some event, a video clip or an illustrated biography.

Typical characteristics of a newsItem are:

  • Its content may be of any media type or format, e.g., the thumbnail, preview and high definition renditions of a picture.

  • It can also convey more structured news information, e.g., information about companies, sports events and general events, in instances when this information is related to an event or fact.

  • Its content is of short term interest: newsItems are volatile, and interest in them fades as time passes (“nothing is older than yesterday’s news”).

  • It is expressed via a set of alternative renditions of some media content.

  • It will usually be updated only for a short period of time, as long as the covered event evolves, and then may be archived.

  • It refers to an arbitrary set of concepts and entities.

  • It may be associated with other newsItems or Web resources via typed links.

2.2. Indication of Compliance with a Standard and Conformance Level

The IPTC newsItem standard attribute MUST be set to “NewsML-G2” from NewsML-G2 2.9 on. “EventsML-G2” MAY be used up to version 1.7 of the EventsML-G2 standard.

The standardversion attribute must reflect the version of the standard as it is implemented by the corresponding XML Schema.

The IPTC conformance level to which the newsItem conforms MAY be omitted if the conformance level is "core"; or it MUST be indicated by the conformance attribute value “power” as shown in the examples below.

2.2.1. Sample Core Conformance Level

<newsItem
    standard="NewsML-G2"
    standardversion="2.24"
    http://iptc.org/std/nar/2006-10-01/>
    ...
</newsItem>

2.2.2. Sample Power Conformance Level

<newsItem
    standard="NewsML-G2"
    standardversion="2.35"
    conformance=”power”
    http://iptc.org/std/nar/2006-10-01/>
    ...
</newsItem>
Freezing of Core Conformance Development. The last version of NewsML-G2 that supports Core Conformance is 2.24. All features added to the standard from 2.25 onwards are supported at Power Conformance only. However, to maintain backwards compatibility with previous versions of NewsML-G2, conformance of documents MUST continue to be specified as "power", even though this is implicitly the only conformance level that can apply. The standardversion documented in this Specification is “2.35”.

2.3. Identification and Versioning

It is possible to positively identify a newsItem as it moves through the news workflow and is transferred from place to place and from system to system.

A newsItem MUST have a guid attribute holding a persistent and globally unique identifier. IPTC recommends using an IRI but this is not a requirement. Any string capable of acting as a globally unique identifier may be used.

The IPTC provides the newsml-URN for this purpose, specified by a successor of RFC-3085.

A newsItem MAY have a version number, and this version number MUST be increased when the Item is updated. If explicitly set, the first version number MUST be set to 1 and any subsequent version number for that Item MUST be unique. If the version number is not explicitly set, a value of 1 MUST be assumed by the recipient of the Item.

Sample:

<newsItem
    standard="NewsML-G2"
    standardversion="2.35"
    conformance=”power”
    guid="urn:newsml:iptc.org:20071231:sample"
    version="2"
    http://iptc.org/std/nar/2006-10-01/>
</newsItem>

2.4. Catalog of Controlled Vocabularies

NewsML-G2 recommends the use of controlled values for most properties. Each news provider is free to use its own taxonomies of subjects, genres, geopolitical areas, organisations etc., and to use any value scheme it decides in the Items it provides. NewsML-G2 controlled values are expressed by QCodes or by fully-expanded URIs. When using QCode values, a provider must declare the schemes being used in the Item by means of a catalog, which MUST be included at the top of each Item.

Due to the large number of the same schemes potentially used in many single Items, and knowing that bandwidth is important to the News industry, the catalog may be stored remotely and referenced by the Item using catalogRef

If a provider exclusively uses fully-expanded URIs in place of QCodes, catalog and/or catalogRef may be omitted.

A remote catalog MUST have an href attribute which contains the URL of a remote catalog. A remote catalog takes the form of an XML file with a catalog element as root. (An XML requirement is to add the NewsML-G2 namespace definition to the catalog element.)

The URL of a remote catalog acts both as a locator and a global identifier, therefore:

  • The URL of a remote catalog MUST NOT be relative.

  • If a remote catalog is functionally changed, the URL used to access it MUST be changed. Functional changes are:

    • the addition or removal of a scheme declaration,

    • a change to any scheme alias,

    • a change to any scheme URI.

    • a change to any of the combinations of schema alias and scheme URI.

One or more additional titles for a catalog or catalogRef MAY be provided in different languages and variants.

To extend the information about the catalog some optional attributes of the catalog element may be used:

  • url: defines the location of the catalog as remote resource.

  • authority: defines the authority controlling this catalog

  • guid: a Globally Unique Identifier for this kind of catalog as managed by a provider

  • version: version corresponding to the guid of the catalog

In general, a given provider will define a unique catalog of all used schemes, store it in a central repository and reference it from all Items it provides. A provider MAY declare several catalogs in the same Item. This may be especially useful for an aggregator who uses property values from different sources, but requires a way to avoid scheme alias clashes. In this case, catalog and remote catalog elements MAY appear in any order, and their order is not relevant.

The main reason for using a sameAsScheme indicator for a scheme in the catalog is speeding up QCode processing: a NewsML-G2 processor does not have to check the individual concept for its sameAs relationships but can apply this relationship directly to a concept if the scheme identifier of this concept (used as property value) matches the scheme identifier in the sameAsScheme child in the catalog.

Another reason for establishing a sameAsScheme relationship between a scheme A of a provider and a referenced scheme B is to provide additional information about concepts; this could be identical information from scheme B in a different language or deeper information in the same language(s) as available with scheme B.

Detailed information on the structure of catalogs and their processing is given in Dealing with Controlled Values.

Sample:

<newsItem
    standard="NewsML-G2"
    standardversion="2.35"
    guid="urn:newsml:iptc.org:20071231:sample"
    version="2"
    xmlns="http://iptc.org/std/nar/2006-10-01/">
    <catalogRef href="http://aprovider.com/cv/newsml-g2-catalog-4.xml"/>
</newsItem>

2.5. Signature Information

A digital signature may be associated with a whole Item or only parts of it. For example, it is possible to sign each individual news content component of a newsItem using their local identifiers as a local reference.

A digital signature is a unique seal placed on data. It is difficult to forge and assures that any change made to the signed data cannot go undetected.

This specification supports the model and syntax defined by the W3C in [XMLDSIG], and introduced by the following: “XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere”.

This specification model excludes two functionalities defined by the W3C XML-Signature Processing Recommendation. These are: “Signed content included within an XML Signature Construct” and “Detached Signatures”.

Therefore this specification offers the following features:

  • A Signature MUST be “enveloped” (the Signature Component is contained within the Item being signed).

  • A Signature MUST sign the Item containing the Signature component or child components of the Item containing the Signature.

  • The Signature MUST NOT be “enveloping” (it cannot sign content found within the signature itself).

  • A Signature MUST NOT be “detached” (a detached Signature Component would not be contained within the Item being signed and could be external to the containing document).

  • A Signature MUST NOT be related to Items and Components external to the enclosing document (via references).

2.6. Rights Information

The content of a newsItem is bound to a set of copyrights and licensing information.

A rightsInfo wrapper element acts as a container for a set of properties related to rights, which offer a basic expression of the copyright and usage conditions associated with an Item.

This available properties are accountable person, a copyrightHolder, a set of copyrightNotice elements, usageTerms, and dataMining rights. The optional dataMining element expresses data mining permissions and constraints, using the recommended vocabulary of values defined by the PLUS Coalition at https://ns.useplus.org/LDF/ldf-XMPSpecification#DataMining.

The order of the properties is flexible: The non-repeatable properties MUST come first, then the repeatable properties MAY be inserted in any order.

The expression of rights can be verbose, and the volume of information exchanged or stored may suffer from the repetition of such information. Therefore each property provides an href attribute as an alternative locator of a remote expression of rights. In the case where both inline and remote expression of rights is indicated, the inline expression MUST take precedence.

In some situations, different parts of the content are associated with different sets of rights; the rightsInfo element is therefore repeatable.

Each set of rights provides a set of optional attributes (idrefs, scope, aspect), which indicate which part of the content is bound to these rights. Please review the comprehensive Processing Model below.

The rightsInfo element also provides optional time validity attributes (validfrom and validto) which express the date and time between which the set of rights properties apply.

Each provider may add a set of metadata properties which have to be defined in a non-IPTC-G2 namespace. See also XML Namespaces and Extension Points in XML.

2.6.1. Processing Model

Rights Use Case 1 of 3: Rules for adding rightsInfo expressions taking the News Provider View

To be answered: How to apply rightsInfo elements referencing only a part of a NewsML-G2 Item?

image

  1. How a rightsInfo element applies to an Item can be refined in two ways:

    1. making a statement about the scope, i.e. whether this rightsInfo element applies to the whole or part(s) of the Item, and

    2. making a statement about the rights-related aspect of the Item or part(s) of the Item to which rightsInfo applies.

  2. There are two ways to express the scope:

    1. In a general way: all elements of an Item are split into either the set of metadata properties or the content. Thus it can be expressed that

      • rightsInfo is about the Item as a whole by not having a scope attribute

      • rightsInfo is about the metadata properties only by adding a scope attribute with a value of
        "riscope:metadata"

      • rightsInfo is about the content only by adding a scope attribute with a value of "riscope:content" To see which parts of an Item fall under the content-scope, and which parts under the metadatascope, check the definition in the Rights Info Scope NewsCodes.

      • When making a statement about the scope in this general way an idrefs attribute MUST NOT be present on this rightsInfo element (else the scope will only apply to the element(s) with a corresponding id).

    2. In a specific way: by adding the ID(s) of XML element(s) to the idrefs attribute this rightsInfo applies only to all element(s) which have a corresponding id. This specific addressing of elements overrides rightsInfo expressions which use the general addressing mechanism.

      The application of rightsInfo is not inherited by the children of itemMeta and contentMeta if these wrapper elements are targeted using their IDs. Therefore their IDs should not be added to idrefs. If the referenced XML element is a partMeta element then:

      • If a scope attribute is not present then rightsInfo applies to both the content described by this partMeta element and to the metadata children of this partMeta element.

      • If a scope attribute is present its value(s) determines whether rightsInfo applies to the content described by this partMeta element or to the metadata children of this partMeta element.

        In compliance with the specification of the idrefs attribute, IDs of only the following XML elements may be included into the list of values of idrefs:

      • all metadata properties as per the definition of the Rights Info NewsCode for "riscope:metadata".

      • the child elements inlineXML, inlineData and remoteContent of contentSet of a News Item as they provide renditions of the full content, the child element concept of conceptSet of a Knowledge Item and the child element group of groupSet of a Package Item.

        Explicitly excluded are all child elements of inlineXML of a News Item as they contain only parts of the content. In this case a partMeta element must be used to describe this part and the value of the partid attribute of this partMeta element must be added to the list of values of the idrefs attribute of the rightsInfo element.

  3. The scope and idrefs attributes allow one to determine to which XML elements a rightsInfo element applies. In some cases it is necessary to associate a rightsInfo element with a particular aspect of an XML element. For example, a keyword element may contain a term associated with a photograph.

    One aspect of the keyword element to which a rightsInfo element may apply is the term itself. Another aspect to which a rightsInfo element may apply is the selection and application of this term to this photograph. Rights on these two aspects could be different. The aspect attribute allows one to determine to which rights-related aspects the rightsInfo element applies.

    • If an aspect attribute is not present then all aspects from the Rights Aspect NewsCodes apply.

    • If an aspect attribute is present then only the aspects from the Rights Aspect NewsCodes listed in the attribute apply.

    • If a target does not support a specific aspect which is listed in the aspect attribute then this aspect should be ignored for this target.

Rights Use Case 2 of 3: How to detect all parts of an Item which are governed by a specific rightsInfo expression taking the Copyright Holder View

To be answered: To which markup does this specific rightsInfo apply?

image

  1. The goal of the processing: the result will be multiple sets of elements and/or parts of content which all are governed by a rightsInfo expression. Each of the sets corresponds to one of the Rights Aspect NewsCodes, and MAY be empty after the processing if no corresponding parts of an item are found.

  2. Select the rightsInfo element to be processed; this is the "base" for all subsequent processing steps.

  3. If no idrefs attribute exists in the base:

    1. If a scope attribute is not present: all the content and all metadata properties of this item are governed by the base’s rights expression; they all should be included into a temporary result set. Continue with step 5.

    2. If a scope attribute is present:

      • If its value is "riscope:metadata": only metadata properties are in the scope of this rightsInfo element, add only all metadata elements of this item to a temporary result set. Continue with step 5.

      • If its value is "riscope:content": only content is in the scope of this rightsInfo element, add only all content of this item to a temporary result set. Continue with step 5.

  4. If an idrefs attribute is present in the base, iterate over each of the IDs listed by the idrefs attribute and find the referenced element:

    1. If the referenced element is a partMeta element then check if a scope attribute is present in the base:

      1. If a scope attribute is not present: a) the partMeta content and b) all the partMeta metadata properties are governed by the base’s rights expression; they all should be included into a temporary result set. Continue with step 5.

      2. If a scope attribute is present:

        • If its value is "riscope:metadata": only metadata properties are in the scope of this rightsInfo element, add only the metadata elements of this partMeta element to a temporary result set. Continue with step 5.

        • If its value is "riscope:content": only content is in the scope of this rightsInfo element, add only the content described by this partMeta element to a temporary result set. Continue with step 5.

    2. If the referenced element is not a partMeta element: add the referenced element to a temporary result set. In this case the scope is implied by the element that is referenced and any scope attribute should be ignored. Continue with step 5.

  5. Check the base for an aspect attribute:

    1. If an aspect attribute is not present then all members of the temporary result set should be copied to each of the result sets for the different Rights Aspects.

    2. If an aspect attribute is present then all members of the temporary result set should be copied only to the result sets corresponding to the Rights Aspects which are present in the aspect list.

  6. Final step: iterate over the result sets for the different Rights Aspects and interpret the included parts of the content or metadata elements according to the associated aspect. Some members of the result set may not be in a scope specified in the definition of the aspect; such members should be excluded from the result set.

Rights Use Case 3 of 3: How to detect the rightsInfo expression(s) that apply to a specific part of an Item taking the Content/Metadata User View

To be answered: For a specific element, which rightsInfo is applicable?

image

  1. The goal of the processing: the result will be multiple sets of rightsInfo elements, all of which will apply to this part of the Item. Each of the sets correspond to one of the Rights Aspect NewsCodes, and MAY be empty after the processing if no corresponding rightsInfo elements were found.

  2. Select the part of the Item for which the corresponding rightsInfo expression(s) should be determined, this part is the "target" for all subsequent processing steps.

    This part must be: * the full content, or * one of the renditions of the content as a whole, or * a part of the content which is described by a partMeta element, or * a single metadata property. The metadata wrappers itemMeta or contentMeta should NOT be selected as a target of this processing.

  3. Define into which scope of rightsInfo elements the target falls:

    Match the target against the definitions of corresponding parts for "riscope:content" and "riscope:metadata" of the Rights Info Scope NewsCodes and determine to which scope the target belongs.

    Be aware that partMeta elements fall under BOTH scopes.

  4. Iterate over each rightsInfo element which has no idrefs attribute:

    1. If a scope attribute is not present in the rightsInfo element then check the rightsInfo element against the rules of step 6 and add it to result sets as defined. Mark the added rightsInfo element as "generic scope rightsInfo". Continue with step 7.

    2. If a scope attribute is present and the target falls in the scope of the attribute’s value (see step 3) then check the rightsInfo element against the rules of step 6 and add it to result sets as defined. Earmark the added rightsInfo element as "generic scope rightsInfo". Continue with step 7.

  5. Iterate over each rightsInfo element which has an idrefs attribute that includes the ID of the target:

    1. If a scope attribute is not present then check this rightsInfo element against the rules of step 6.

      Be aware that a rightsInfo element which is referencing the target by idrefs overrules rightsInfo elements which reference the target by scope. For that reason if the target should be added to the result set then first delete any rightsInfo element which is marked as "generic scope rightsInfo" from the result set, and then add this rightsInfo element. Continue with step 7.

    2. If a scope attribute is present and the target falls in the scope of the attribute’s value (see step 3) then check the rightsInfo element against the rules of step 6.

      Be aware that a rightsInfo element which is referencing the target by idrefs overrules rightsInfo elements which reference the target by scope. For that reason if the target should be added to the result set then first delete any rightsInfo element which is marked as "generic scope rightsInfo" from the result set, and then add this rightsInfo element. Continue with step 7.

  6. Check any aspect attribute of a rightsInfo element:

    1. If an aspect attribute is not present then the rightsInfo element should be added to the result sets corresponding to each of the Rights Aspect Newscodes.

    2. If an aspect attribute is present then the rightsInfo element should be added only to the result sets corresponding to the Rights Aspects which are present in the aspect list.

  7. Final step: iterate over the result sets for the different Rights Aspects and interpret the included parts of the content or metadata elements according to the associated aspect. Some members of the result set may not be in a scope specified in the definition of the aspect; such members should be excluded from the result set.

2.7. Item Metadata

Such information is wrapped in the mandatory itemMeta wrapper element and split between news management metadata and Item links.

2.7.1. Management Metadata

Management metadata is bound to the Item as a whole and reflects its processing in a professional workflow.

The order of the properties in this set is imposed by the W3C XML Schema.

Table 1. Item Management Group Elements

Element Title Element Name Cardinality

Item Class

itemClass

-1

Content Provider

provider

-1

Date Item Version Created

versionCreated

-1

Date Item First Created

firstCreated

(0..1)

Date Item Embargo Ends

embargoed

(0..1)

Publish Status

pubStatus

(0..1)

Role in the Workflow

role

(0..1)

File Name

filename

(0..1)

Generator Tool

generator

(0..1)

Profile

profile

(0..1)

Editorial Service

service

(0..unbounded)

Item Title

title {itemMeta}

(0..unbounded)

Editorial Note

edNote

(0..unbounded)

Member Of

memberOf

(0..unbounded)

Instance Of

instanceOf

(0..unbounded)

Signal

signal

(0..unbounded)

Alternative Representation

altRep

(0..unbounded)

Deliverable Of

deliverableOf

(0..1)

Hash Value

hash

(0..unbounded)

Expires

expires

(0..unbounded)

Original Representation

origRep

(0..unbounded)

Incoming Feed ID

incomingFeedId

(0..unbounded)

Metadata Creator

Attribution of metadata creation

(0..unbounded)

The IPTC provides a mandatory standardised scheme applicable to the itemClass property of a newsItem, identified by the URI http://cv.iptc.org/newscodes/ninature/.

Each provider may add a set of metadata properties which have to be defined in a non-IPTC-G2 namespace. See also XML Namespaces and Extension Points in XML.

2.7.2. Processing the Publish Status of an Item

The IPTC makes these values normative for the exchange of Items between a provider and its customers:

  • usable: The Item MAY be published without restriction.

  • withheld: Until further notice, the Item MUST NOT be made public by whatever means. If the Item has been published the publisher MUST take immediate action to withdraw or retract it.

  • canceled: (note: U.S. spelling) The Item MUST NOT be made public by whatever means. If the Item has been published the publisher MUST take immediate action to withdraw or retract it.

Embargoes are managed by the embargoed property. At the level of the data model the embargoed element could be linked now to an edNote element if the existing embargoed is empty (<embargoed />).

Details are described in the Processing model below.

State Transition Diagram

This depicts the state transition diagram reflecting the ways in which the pubStatus values are intended to be used. Thus, upon creation of an Item, allowed statuses are usable and withheld. It is possible to withhold a usable document; it is possible to release a withheld document; it is possible to cancel a usable or withheld document. Once an Item has had its status set to canceled, it has reached a final state.

image Figure 1. State Transition Diagram

Reliability of Items with a status of Withheld or Canceled

The use of Withheld or Canceled indicates that parts of the previous version of the Item were not correct (and in the case of Canceled, cannot be corrected), and therefore cannot be considered as reliable information. This raises the issue as to which parts of the Item version with a publish status of Withheld or Canceled should be considered as correct and reliable.

These attributes and elements MUST be considered as correct and reliable: the Item guid and version, the pubStatus element including the qcode and/or uri attributes. The edNote element SHOULD be considered as reliable. All other metadata properties of the Item MAY be considered as reliable, but the element(s) conveying the content of the Item SHOULD NOT be considered as reliable.

Use Cases Associated with a Status of Withheld
  1. A provider distributes a story as a newsItem (version 1) with the status usable. At a later stage he learns that there may be a problem with the information included in the Item. He sends a new version of the newsItem (version 2) with a status set to withheld. All recipients systems must display a warning on this newsItem, and recipient publishers must postpone the publication of the information contained in the newsItem until further notice. The news provider has confirmation that the information is false and decides to set the status to canceled (version 3).

  2. An eCommerce system proposes a large collection of illustrated articles managed as news items. The publisher managing the system sees that the information included in a newsItem (version 1) is not up to date, and decides to hide this Item from its customers until it is properly revised. He sets its status to withheld (version 2), edits the newsItem and set its status back to usable (version 3).

Processing Model on the Recipient Side

Here is the processing model on the recipient side and relies on the pubStatus and embargoed properties:

  1. Test pubStatus = canceled:

    The Item must not be used, ever. Any usage of the Item must be prohibited, if needed by the way of alerts.

    Else: next

  2. Test pubStatus = withheld:

    The Item must not be used until further notice. Any usage of the Item must be prohibited, if needed by the way of alerts.

    Else: next

  3. Test pubStatus = usable:

    Test embargoed as described in the table below:

Table 2. Test pubStatus = Usable

<embargoed> <pubStatus> How to Process

Element is absent.

Usable

Item is usable and not embargoed.

Element exists, provides a Date/Time value.

Usable

The embargo on the item ends at the given date and time.

Element exists, but is empty.

Usable

The item is embargoed as long as a condition applies which is described in an editorial note.

Corresponding edNote exists.

The edNote should be formulated like this: <edNote @role="noteRole:embargo">Until end of speech</edNote>

Element exists, but is empty.

Usable

The item is embargoed indefinitely. This may be overridden by a contractual agreement between the provider and the client.

No corresponding edNote exists.

2.7.3. Processing of versionCreated

If the value provided by any date/time field does not conform to the appropriate syntax (e.g. format “YYYY-MM-DDTHH:MM:SS[+-]HH:MM”) it MUST be considered as being not existent.

In the case of the mandatory versionCreated property the full Item MUST be considered as being void.

2.7.4. Best Practice for expressing an update or correction of an item

An Update is expressed by using the concept URI http://cv.iptc.org/newscodes/signal/update (as QCode with the recommended scheme alias: sig:update) as value of the signal property under the Item Meta of an Item. This signal indicates that some part of the item has been updated. This implies that this version of the item is not the inital version.

A Correction is expressed by using the concept URI http://cv.iptc.org/newscodes/signal/correction (as QCode with the recommended scheme alias: sig:correction) as value of the signal property under the Item Meta of an Item. This signal indicates that some part of the item has been corrected. This implies that this version of the item is not the inital version. This Correction signal does not indicate in which version(s) of the item the corrected error existed.

In addition a concept from the Severity NewsCodes (http://cv.iptc.org/newscodes/severity/) may be used as a refinement of how severe the impact of this update or change is. The IPTC acknowledges that the rules for applying the severity are set by the news provider of the item.

Further the Editorial Note (edNote) property under Item Meta may be used to provide details about the update or correction like pointing at a name in the text which has been corrected of if paragraph with updated information has been added to the text.

2.7.5. Best Practice for issuing a content warning

A Content Warning is expressed by using a QCode for the concept URI http://cv.iptc.org/newscodes/signal/cwarn with the signal property. (With the recommended alias the QCode is “sig:cwarn”.) This signal indicates that the content of the item should be reviewed as it may be perceived as being offensive.

In addition, refinement of the reason(s) for the content warning MAY be expressed by using concept(s) from the Content Warning NewsCodes http://cv.iptc.org/newscodes/contentwarning/ with the exclAudience property.

Examples:

Content Warning signal without specific Content Warning NewsCodes
<signal qcode="sig:cwarn"/>
Content Warning signal with specific Content Warning NewsCodes (relating to nudity and language)
<signal qcode="sig:cwarn"/>
<exclAudience qcode="cwarn:nudity"/>
<exclAudience qcode="cwarn:language"/>

A powerful feature of NewsML-G2 is the capability to associate Items via links. It is therefore possible to create a network of news resources, for management and navigation purposes.

The link element offers a generic mechanism for linking Items within the NAR framework as well as creating links from Items to other Web resources.

The semantic of the link MAY be refined via a relationship attribute (rel). In the absence of such indicator, the implied meaning of the link is "see also" (i.e. a navigation link).

The IPTC provides a recommended scheme of link relationships identified by the URI http://cv.iptc.org/newscodes/itemrelation/.

To identify the target resource either the residref attribute or the href attribute MUST be set, optionally both MAY be used in parallel. The residref attribute identifies the target resource by its globally unique identifier (if the resource has such an identifier), while the href attribute identifies the location of the target resource in e.g. a (remote) file system. If the target resource is an Item and the residref attribute is used, a version attribute MAY indicate the target Item version; in the absence of version information, the target resource is the latest version available.

A provider MAY explicitly express the format of residref using the residerefformat attribute with a QCode (or as a URI using its sibling residrefformaturi) in conjunction with the recommended IPTC Value Format NewsCodes (recommended scheme alias "valfmt") at http://cv.iptc.org/newscodes/valueformat/.

The content type, a.k.a. IANA Media Type of the target resource MAY be indicated by the contenttype attribute. It MAY be complemented by a format attribute to refine the Media Type information.

In order to ease the processing of a linked resource, the size in bytes of the target resource MAY be indicated. This feature is useful if the target on the link is a Web resource. If the target resource is an Item, the size which is given here MUST be the size of the XML representation of the Item.

A rank attribute may represent the rank of the link among other links.

This property also provides timeValidityAttributes (validfrom and validto) which express the date and time between which the link is valid.

Supplemental metadata extracted from the target resource (usually an Item) may be added to the linking information as child elements. Such information is not constrained by the data model. It may be part of the target Item Metadata (e.g. Publish Status, Alternative Location …​), Content Metadata (e.g. Intended Audience, Subject, Genre …) or Characteristics of the content (e.g. Size, Content Type, Format, or specific characteristics like the Height and Width of a picture). Different sets of characteristics may be provided, corresponding to specialized content components.

All properties SHOULD be included directly under the link property (see the details for this inclusion in the Hint and Extension Point section).

Link processing rules:
  1. Processor on the consumer side: If a guid and a version are provided, check whether the specific version of the Item is accessible using this information.

  2. Processor on the provider side: If a guid and a version are provided deliver only the item version with the requested version number.

  3. Processor on the consumer side: If only a guid is available and no version, check whether an item is delivered by the provider. Consider a delivered version of the item as being the latest one.

  4. Processor on the provider side: if only a guid is requested and not version, check if any version of the item exists, and if yes provide the one with the highest version number.

  5. Check whether the value of the href attribute allows some direct retrieval of the target resource via the Web (e.g. if the scheme is http: or ftp:), or an implicit resolution mechanism (e.g. DOI).

  6. Check whether an Alternative Representation (altRep) is exposed in the link. This information may complement the href attribute and provide an immediate URI resolution mechanism for Items. Multiple locations may be given, as allowed in the Item Metadata component. In such a case the processor will use the role qualifier and URL scheme for choosing the most appropriate resource.

  7. Signal an error or ignore the link.

2.9. News Content Metadata

News Content Metadata is directly associated with the news information conveyed by the Item, independently of the processing of the Item in a professional workflow. Such information which applies to the whole content of the Item is wrapped in the contentMeta wrapper element and split between administrative and descriptive metadata. Be aware that some NewsML-G2 Items adopt only a subset of the metadata properties listed below. Informtion about a part of the content is wrapped by Part of Content Metadata.

2.9.1. Administrative Metadata

This is a set of properties associated with the administrative facet of content, i.e. data that cannot be inferred from “consuming” (reading, listening to, watching) the content.

All properties are optional. The order of the properties in this set is flexible: the non-repeatable properties MUST come first and then the repeatable properties may be inserted in any order.

Table 3. Administrative Metadata Group Elements

Element Title Element Name Card

Urgency

urgency

(0..1)

Date Content Created

contentCreated

(0..1)

Date Content Modified

contentModified

(0..1)

Located

located

(0..unbounded)

Information Source

infoSource

(0..unbounded)

Creator

creator

(0..unbounded)

Contributor

contributor

(0..unbounded)

Audience

audience

(0..unbounded)

Excluded Audience

exclAudience

(0..unbounded)

Alternative Identifier

altId

(0..unbounded)

Dates Processing Model

Two optional dates are associated with the content of an Item.

contentCreated and contentModified processing rules:

Date Value Rules
  1. If the value provided by any date/time field does not conform to the appropriate syntax (e.g. format “YYYY-MM-DDTHH:MM:SS[+-]HH:MM”) it MUST be considered as being not existent.

  2. If contentCreated is present it MUST NOT be later than versionCreated.

    Error handling if it is later: at the creator’s site an error alert should be issued, on the receiver’s site it should be set to versionCreated.

  3. If contentModified is present contentCreated SHOULD be present as well. In this case contentModified MUST NOT be earlier than contentCreated.

    Error handling if it is earlier: at the creator’s site an error alert should be issued, on the receiver’s site it should be set to contentCreated

  4. If contentModified is present it MUST NOT be later than versionCreated.

    Error handling if it is later: at the creator’s site an error alert should be issued, on the receiver’s site it should be set to versionCreated.

Date Processing Rules
  1. The recipient processor MUST first check if a contentModified element is present.

  2. If not it MUST check if a contentCreated element is present.

  3. If a contentCreated element is not present the processor SHOULD assume that the content was created at the time indicated by versionCreated element in itemMeta.

Audience Processing Model

Audience processing may be used to form ad hoc groups of recipients for which the Item is particularly significant or to filter out some users from the list of intended recipients of an Item.

The audience is expressed as a set of “positive” values (audience)and a set of “negative” values (exclAudience). The logic is to make the content easy to find to the audience identified by the positive values, but keep this content away from the audience identified by the negative values. An attribute of each property may indicate the expected significance of the content for this specific audience, and acts as a threshold for recipient filters.

The model for the audience processing is only a part of the overall filter that is used to determine whether a particular recipient is entitled to have access to the Item. It could be combined with the processing of other properties to further narrow the number of Items that match the recipient profile.

The processing rule has to be considered as a function which returns TRUE to indicate the recipient is entitled to receive the content, FALSE in case he is not entitled and NULL if the item does not contain any audience statements that apply to the Recipient.

Audience processing rules
  1. If any of the exclAudience properties applies to the recipient: return FALSE

  2. If any of the audience properties applies to the recipient: return TRUE.

  3. Return NULL.

2.9.2. Descriptive Metadata

This is a set of properties associated with the descriptive facet of news content, i.e. data that can be inferred from “consuming” (reading, listening to, watching) the news.

All properties are optional, repeatable and may be inserted in any order.

Table 4. Descriptive Metadata Group Elements

Element Title Element Name Card

Language

language

(0..unbounded)

Genre

genre

(0..unbounded)

Keyword

keyword

(0..unbounded)

Subject

subject

(0..unbounded)

Slugline

slugline

(0..unbounded)

Headline

headline

(0..unbounded)

Dateline

dateline

(0..unbounded)

By

by

(0..unbounded)

CreditLine

creditline

(0..unbounded)

Description

description

(0..unbounded)

2.9.3. Other Content Metadata

Each provider may add a set of metadata properties which have to be defined in a non-IPTC-G2 namespace. See also XML Namespaces and Extension Points in XML.

2.10. Part of Content Metadata

Streamed content may be split into different sections (called “shots” in the video world). Images may also be split in regions.

A specific set of metadata MAY be associated with any individual content part. Such metadata is wrapped in a partMeta element, which is repeatable in the newsItem and MUST be inserted after contentMeta.

Each part MAY have a part identifier (partid) and a sequence number (seq).

Each part MAY be illustrated by an icon e.g. a keyframe of a video clip which takes the form of an IRI. It is not mandatory for such icon to be a pure extraction of the content. If multiple icon elements are present they MUST represent the same visual content, only differentiated by rendition, contentType or format.

A section of a stream MAY be defined by a timeDelim element. The time scope is expressed as start and end timestamp attributes plus an additional time unit (timeunit) attribute. Both timestamp values MUST be within the overall content duration.

The start timestamp is the start time of the part in a timeline. The expressed value is excluded from the timeline. Using Edit Unit requires the frame rate or sampling rate to be known, this must be defined by the referenced rendition of the content.

The end timestamp is the end time of the part in a timeline. The expressed value is included. Using the Edit Unit requires the frame rate or sampling rate to be known, this must be defined by the referenced rendition of the content.

A region of an image MAY be defined by a regionDelim element. Currently regions are limited to rectangles defined by {x, y, width, height} coordinates in pixels expressed as a set of attributes.

The role of this part in a stream of content MAY be defined by the role property.

If, during the processing of the content, it appears that part delimiters do not correspond to any physical content, then the corresponding set of metadata MUST be discarded.

News Administrative and Descriptive Metadata may be applied to each part, in complement to the administrative and descriptive metadata applicable to the whole content.

Each provider may add a set of metadata properties which have to be defined in a non NewsML-G2 namespace. See also XML Namespaces and Extension Points in XML.

2.10.1. Edit Units and Time Codes

It is recommended that time and durations are expressed in “Edit Units” (editUnit), which represent the smallest editable portion of content, i.e. a video frame or an audio sample.

\$Edit Unit = 1 div(Edit Rate)\$.

For video, the Edit Rate is the Frame Rate (frames per second). For audio, the Edit Rate is the Sample Rate (Hz).

The use of Edit Unit is independent of the mode of representation of time (e.g. timecode) in editing devices. The timecode associates one value to each video frame or audio sample.

For video, the usual timecode format is HH:MM:SS:FF (Hours:Minutes:Seconds:Frames).

In the case of simple frame rates (e.g. 25 fps, 30 fps, 50 fps or 60 fps), the conversion of a number of EditUnits to timecode is simple.

However, there exist other frame rates (e.g. 29.97 fps, 59.94fps) for which this calculation requires more attention. A precise calculation would consist of replacing e.g. 29.97 fps by its exact value 1.001/30 fps and multiplying the number of Edit Units by 1.001 before conversion on the basis of 30 fps. Another method consists of calculating the timecode using the drop frame method defined in SMPTE 12M. The drop frame method is an approximation based e.g. on 29.97 fps (1.001001001/30 fps). The drop frame timecode is not systematically used, particularly if content is of a short duration with insignificant drift with the actual clock time. SMPTE 12M will evolve as it doesn’t address higher frame rates with progressive scanning.

For audio, the usual video timecode (HH:MM:SS:FF) is used if the content also contains video. A time restricted timecode (HH:MM:SS) is often used for audio only content.

The time reference will be the one of reception or edition in the production system, which should be able to locate content in time based on the number of Edit Units.

2.10.2. Time Unit Types and Start/End Timestamp Formats

The format of the Start Timestamp (start) and/or End Timestamp (end) is implied by the associated Time Unit type (timeunit), see the Time Delimiter element timeDelim.

Table 5 defines the processing of values of the three related attributes but be aware: they are required by the XML Schema but may either show invalid values or be empty.

Table 5. Time Unit Type and Start/End Value Processing

Time Unit Type [@timeunit] Start/End Timestamp [@start / @end] How to Process

Invalid value

None

Ignore the Time Delimiter.

Invalid value

One or both

The default Time Unit Type value of editUnit MUST be used; the related format is used to parse the Timestamp value(s).

Valid value

None

Ignore the Time Delimiter.

Valid value

One or both

The defined Time Unit Type value MUST be used; the related format is used to parse the Timestamp value(s).

2.11. Assertions About Concepts

When a concept is used as the value of many properties or by a property with a limited granularity of concept details, it may be useful to group supplemental information about this concept at a unique location.

The optional and repeatable assert property provides information about a concept identified by a qualified code, a full URI or a literal value. The information is given as a set of properties providing metadata about the concept. Many assertions may be included in an Item.

Any property of the concept may be included at this point, especially its name, its relationships with other concepts, its definition.

This information is only up to date at the time of last modification of the Item. Any changes applied to a concept after that time are not reflected by an assert element.

2.12. References to Inline Concepts

When the same concept appears as a string in several different labels or in the textual content of a newsItem, it may be useful to group information about this concept at a unique location.

The optional and repeatable inlineRef property provides information about a concept found in some textual content. The string associated with the concept can be tagged by any element which provides an attribute of type ID. One or more local identifiers MAY be listed as value of the idrefs attribute of the inlineRef element.

If the concept is taken from a controlled vocabulary it MUST be identified by a qualified code or a full URI, in any other case it SHOULD be identified by a literal value, and supplemental information MAY be given as a set of properties relative to the concept.

It is possible to give values for the confidence with which the metadata has been assigned, the relevance of the metadata to the string to which it is attached, and why the metadata has been included.

2.13. Derivation of Concepts

Increasingly, metadata values are not added explicitly by human interaction but by an automated derivation using some kind of knowledge network. In this case it could be valuable to indicate the concept(s) or value(s) from which a specific value of a metadata property has been derived. For this purpose the optional derivedFrom and derivedFromValue elements can be used.

The qcode or uri attribute of the derivedFrom element defines the concept from which another concept has been derived. The idrefs attribute of this element refers to the id attributes of all properties in this NewsML-G2 Item whose value has been derived from the concept represented by derivedFrom.

The derivedFromValue element represents the non-Concept value that was used for deriving the value of one or more properties in this NewsML-G2 Item. The mandatory sourceidref attribute refers to the id of the element that provides the value used for the derivation; the mandatory idrefs attribute refers to the ids of elements whose values have been derived from the value represented by this property.

2.13.1. Attribution of metadata creation

The entity (person, organisation, system) responsible for creating metadata is expressed by the metadataCreator element, which is used in conjunction with the creator attribute (note: NOT the creator element) as follows:

  1. If an element specifies a creator: the Creator of the element is expressed by the value of creator.

  2. If an element does not specify a creator and a Metadata Creator is specified: the element’s Creator is expressed by the value of the metadataCreator element.

  3. If an element does not specify a creator and a metadataCreator is not specified: the element’s Creator is indeterminate.

See also metadataCreator

2.14. newsItem Content

Content may be included by value or by reference, and useful characteristics are represented along with such content, in order to facilitate its processing.

Alternative renditions of the news content, i.e. different technical representation of the same logical content, are wrapped by a contentSet wrapper element. Their order of appearance in contentSet is of no relevance. Their presence is optional: this allows for a lightweight and extensible representation of information.

Each rendition SHOULD by defined by a rendition attribute.

All alternative renditions SHOULD be derived from an original rendition by a software processor. For example: images in different resolutions, vector graphics and alternative bitmap images, text in different formats (e.g. NITF and PDF). The rendition from which all other renditions originate is indicated by the original attribute of contentSet; this attribute takes as a value the local identifier (id) of the original content component included in the contentSet.

They are three kinds of content components, Inline XML, Inline Data and Remote Content:

  • The inlineXML wrapper element holds XML content which is directly embedded in the element.

    The root element of this structure must be the root element of the language. Content may belong to any XML language capable of expressing generic or specialized news information, e.g. NITF, XHTML, SportsML or XBRL. The XML vocabulary is identified by a content type attribute (contenttype).

  • The inlineData wrapper element holds data encoded as a string in the same encoding as the full XML document, for example utf-8.

    Data not covered by this encoding, such as binary data, MUST use a special encoding resulting in a text string. In the case of binary data (images, graphics, video, audio etc) the encoding attribute SHOULD be used to express the encoding used, and the media type of the data SHOULD be expressed by the contenttype attribute, for example “image/jpeg”, “video/quicktime”. The encoding is expressed using a QCode or URI, and it is recommended to use the IPTC Encoding NewsCodes (Scheme URI http://cv.iptc.org/newscodes/encoding/ and recommended Scheme Alias "encd")

    Any characters that are not within the definition of xs:string, such as syntax characters used in HTML, MUST be escaped or placed within CDATA. and the contenttype attribute SHOULD be used (for example “text/plain”, “text/markdown”, “text/html”), but the encoding attribute SHOULD NOT be used.

    When encoding binary assets, it is highly recommended that only relatively small objects are conveyed using <inlineData>; normally the <remoteContent> wrapper should be used to convey binary assets.

  • The remoteContent wrapper element may be used for representing any kind of media and data format.

    The data is stored independently of the newsItem and is referenced via a hyperlink (href). The size in bytes of the remote content MAY be indicated. The element MAY also have validfrom and validto (timeValidityAttributes) which express the date and time between which the reference is active.

    The same rendition of content MAY be present at different remote locations. In this case alternative locators of the content are provided by altLoc child elements of one remoteContent element; multiple remoteContent elements with the same rendition value SHOULD NOT be used.

The description of the content in each content component MAY be complemented by a contenttype, a format acting as an optional refinement of the content type, an indication on the software tool used to generate the content generator and the date and time when the content was generated, plus additional News Content Characteristics.

All these three types of content component elements have an id attribute. For this attribute a special constraint applies: its value MUST be persistent for all versions of the Item for its entire lifecycle. The reason for this constraint is that NewsML-G2 elements referencing a target NewsML-G2 Item may further point inside this Item to reference a specific content component by its persistent id.

2.14.1. News Content Characteristics

newsContentCharacteristics are the physical properties of media content like the height and width of a picture, the word count of a news story or the duration of an audio clip, that help in making selections among different renditions of the same logical news content.

The characteristics defined by the IPTC are a small and typical set of properties. Individual providers may add more characteristics they consider reasonable, i.e. audio data for professional broadcasting may require a different set from audio content for a podcast.

2.14.2. Channels

Some binary streams support the notion of channel or track: for example DVDs are MPEG-2 encoded and provide several audio tracks in different languages. It may be important to indicate media characteristics on a per-channel level.

A repeatable channel {News Item}] element MAY therefore be defined as a child of a remoteContent element.

Each logical channel MAY have a local identifier (chnid), an indication of the media type of the data conveyed by the channel and an indication of the role the data plays in the scope of the full content, for example “voice over”.

Each logical channel MAY be additionally described by the news content characteristics corresponding to the media conveyed in the channel.