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.
14. Events in NewsML-G2
14.1. A standard for exchanging news event information
The sharing of event-related information and planning of news coverage is a core activity of news organisations, without which they cannot function effectively.
News agencies need to keep their customers informed of upcoming events and planned coverage. News organisations publishing on paper and digital media need to plan and co-ordinate their operations in order to make optimum use of their available resources and ensure their target audiences will be properly served.
Historically, this was a paper-based exercise, with news desks maintaining a Day Book, or Diary, and circulating information to colleagues and partners using written memoranda, sometimes referred to as the Schedule, or Budget.
Many organisations have moved, or are moving, to electronic scheduling applications. With software developers and vendors working independently on these applications, there is a risk that incompatibility will inhibit the exchange of information and reduce efficiency.
Consequently, there has been a drive among IPTC members to formalise a standard for exchanging this information in a machine-readable events format using XML, allowing it to be processed using standard tools and enabling compatibility with other XML-based applications and popular calendaring applications such as Microsoft Outlook.
The related NewsML-G2 Planning Item can be combined with Event information so that news organisations can plan their response to news events, such as job assignments, content planning and content fulfilment, sharing this if required with partners in a workflow. (See Editorial Planning – the Planning Item)
NewsML-G2 Events may be used to send and receive all, or part of, the information about:
-
a specific news event.
-
a range of news events filtered according to some criteria – an event listing.
-
updates to news events.
-
people, organisations, objects and other concepts linked to news events.
14.1.1. Business Advantages
An event managed using NewsML-G2 can serve as the "glue" that binds together all of the content related to a news story. For example, a news organisation learns of the imminent merger of two companies. This story can be pre-planned using Events in NewsML-G2 and assigned a unique Event ID by the event planning workflow, in the form of a QCode. When content related to this event is created (text, pictures, graphics, audio, video and packages), all of the separately-managed content to be associated using the QCode as a reference.
The result is that when users view content about this story, they can be provided with navigation to any other related content, or they can search for the related content.
The NewsML-G2 Events standard is the result of detailed collaborative work by IPTC experts operating in diverse markets throughout North America, Europe and Asia Pacific, highly experienced in the planning of news operations and the issues involved.
Adopters therefore have access to an "off the shelf" data model built on the specific needs of the news industry that can nevertheless be extended by individual organisations where necessary to add specialised features. The Events model is evolving as new requirements become known, and the IPTC endeavours to main compatibility with previous versions, giving users a straightforward upgrade path.
The NewsML-G2 Events model complies with the Resource Description Framework (RDF) promulgated by the W3C, which is a basic building block of the Semantic Web, and aligns with the iCalendar.
| A mapping of iCalendar properties to NewsML-G2 properties can be found in the NewsML-G2 Specification Page on the NewsML-G2 web site. See also IETF iCalendar Specification RFC 5545 specification that is supported by popular calendar and scheduling applications. |
There is considerable scope for using events planning to improve the efficiency and quality of news production, since an estimated 50-80% of news provision is of events that are known about in advance. When a pre-planned event is accessible from an editorial system, metadata from the event may be inherited by the news content associated with that event; this makes the handling of the news faster and more consistent. There is also an improvement in quality, since the appropriateness and accuracy of metadata may be checked at the planning stage, rather than under the pressure of a deadline.
The advantages of using a common standard to promote the efficient exchange of information are well understood. Using NewsML-G2 Events, providers can develop planning and scheduling products with greater confidence that the information can be consumed by their customers; recipients can cut development costs and time to market for the savings and services that flow from an efficient resource planning system that aligns with their operational model.
14.1.2. Events Structure
Events in NewsML-G2 use the same building blocks as all other NewsML-G2 Items:
-
Events use NewsML-G2 identification and versioning properties.
-
The <itemMeta> block holds management information about the Item.
-
The <contentMeta> block holds common administrative metadata about the event, or events, conveyed by the NewsML-G2 object.
| Please read the NewsML-G2 Basics chapter before reading this Chapter. |
There are two methods for expressing events using NewsML-G2, each suited to a particular type of information, or application, as shown in the diagram below:
-
Persistent event information that will be referenced by other events and by other NewsML-G2 Items is instantiated as Concept Items containing an <eventDetails> wrapper, or as members of a set of Event Concepts in a Knowledge Item. Events expressed as a Concept with a Concept ID are persistent and can be unambiguously referenced by other Items over time.
-
Transient event information that is "standalone" and volatile can be conveyed in NewsML-G2 using an <events> structure inside a News Item. Events expressed as an <event> in a News Item have no Concept ID and cannot be referenced from other Items.
These differences are illustrated in the following diagram:
Figure: Persistent Event as a Concept and (right) transient Events in a News Item
Managed (persistent) events would be appropriate when a provider makes each of the announced events uniquely identifiable. The event information can then be stored by the receivers and any updates to events can be managed. This model also enables content to be linked to events using the unique event identifier, and this enables linking and navigation of content related to news stories.
A "standalone" implementation would be used when an organisation periodically announces to its partners and customers lists of forthcoming events. These may be for information only and not managed by the provider. So, for example, a daily list may repeat items that appeared in a weekly list, but there is no link between them, and nothing to indicate when an event has been updated.
14.2. Event Information – What, Where, When and Who
In a news context, events are newsworthy happenings that may result in the creation of journalistic content. Since news involves people, organisations and places, NewsML-G2 has a flexible set of properties that can convey details of these concepts. There is also a fully-featured date-time structure to express event occurrences, which conforms to the iCalendar specification.
14.2.1. Complete Listing for an example Event
The following example shows a news event expressed as a Concept and conveyed within a Concept Item.
LISTING 14: Event sent as a Concept Item
All Scheme Aliases used in the listing below indicate IPTC NewsCodes vocabularies, except for the following alias values: ex-event, ex-frel and ex-ventyp.
<?xml version="1.0" encoding="UTF-8"?>
<conceptItem
xmlns="http://iptc.org/std/nar/2006-10-01/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://iptc.org/std/nar/2006-10-01/
./NewsML-G2_2.35-spec-All-Power.xsd"
guid="urn:newsml:iptc.org:20160422:qqwpiruuew4711"
version="18"
standard="NewsML-G2"
standardversion="2.35"
conformance="power"
xml:lang="en">
<catalogRef href="http://www.iptc.org/std/catalog/catalog.IPTC-G2-Standards_41.xml" />
<catalogRef href="http://www.example.com/events/event-catalog.xml" />
<itemMeta>
<itemClass qcode="cinat:concept" />
<provider qcode="nprov:IPTC" />
<versionCreated>2025-06-18T13:05:00Z
</versionCreated>
<pubStatus qcode="stat:usable" />
</itemMeta>
<contentMeta>
<urgency>5</urgency>
<contentCreated>2016-01-16T12:15:00Z</contentCreated>
<contentModified>2025-06-12T13:35:00Z</contentModified>
</contentMeta>
<concept>
<conceptId created="2025-01-16T12:15:00Z" qcode="ex-event:1234567" />
<type qcode="cpnat:event" />
<name>IPTC Autumn Meeting 2025</name>
<eventDetails>
<dates>
<start>2025-10-14T13:00:00Z</start>
<duration>P3D</duration>
</dates>
<location>
<name>86, Edgeware Road, London W2 2EA, United Kingdom</name>
<related rel="ex-frel:venuetype" qcode="ex-ventyp:confcentre" />
<POIDetails>
<position latitude="51.515659" longitude="-0.163346" />
<contactInfo>
<web>https://www.etcvenues.co.uk</web>
</contactInfo>
</POIDetails>
</location>
<participant qcode="eprol:director">
<name>Brendan Quinn</name>
<personDetails>
<contactInfo>
<email>mdirector@iptc.org</email>
</contactInfo>
</personDetails>
</participant>
</eventDetails>
</concept>
</conceptItem >The top level element of the Concept Item is <conceptItem>. The document must be uniquely identified using a GUID. By this means, event information re-sent using the same GUID and an incremented version number, allows the receiver to manage, update or replace the conveyed concept (event) information.
@guid and @version uniquely identify the Concept Item, for the purpose of managing and updating the event information. Items that reference the event itself MUST use the Concept ID. This is because the Concept ID uniquely references a persistent Web resource, whereas the GUID only identifies a document that may or may not persist.
To enable concepts to be identified by a Concept ID QCode, a reference to the provider’s catalog (or a catalog statement containing the scheme URI) MUST be included:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<conceptItem xmlns="http://iptc.org/std/nar/2006-10-01/"
guid="urn:newsml:iptc.org:20160422:qqwpiruuew4711"
version="18"
standard="NewsML-G2"
standardversion="2.35"
conformance="power"
xml:lang="en">
<catalogRef
href="http://www.iptc.org/std/catalog/IPTC-G2-standards_41.xml" />
<catalogRef
href="http://www.example.com/events/event-catalog.xml"
/>In the mandatory <itemMeta> wrapper the IPTC "Nature of Concept Item" NewsCodes expresses the type of Concept Item. (This is complementary to the "Nature of News Item" NewsCodes used with a News Item.) There are currently two values: "concept" and "scheme". (Scheme is used for Knowledge Items.)
<itemMeta>
<itemClass qcode="cinat:concept" />
<provider qcode="nprov:IPTC" />
<versionCreated>2025-06-18T13:05:00Z
</versionCreated>
<pubStatus qcode="stat:usable" />
</itemMeta>The Content Metadata for a Concept Item may contain only Administrative Metadata:
<contentMeta>
<urgency>5</urgency>
<contentCreated>2016-01-16T12:15:00Z</contentCreated>
<contentModified>2025-06-16T13:35:00Z</contentModified>
</contentMeta>14.2.2. What is the Event?
In order to convey event information, we first need to describe "what" the event is. In NewsML-G2, events MUST have at least one Event Name, a natural language name for the event. They MAY additionally have one or more natural language Definitions, properties that describe characteristics of the event, and Notes.
This Event content is contained in the <concept> wrapper. A Concept Item
has one, and only one, <concept> wrapper. Each Concept must carry a
<conceptId>, a QCode value that will provide a way for other Items to
reference the Concept. The type of concept being conveyed is expressed
using the <type> element with a QCode to tell the receiver that it
contains Event information, using the IPTC "Nature of Concept"
NewsCodes. (The applicable value for an Event Concept is "event")The
Scheme URI is http://cv.iptc.org/newscodes/cpnature/
and recommended Scheme Alias is "cpnat".
The event information is placed directly inside an <eventDetails> wrapper:
<concept>
<conceptId created="2012-06-16T12:15:00Z" qcode="ex-event:1234567"/>
<type qcode="cpnat:event" />
<name>IPTC Autumn Meeting 2025</name>
<eventDetails>
...
</eventDetails>
</concept>The generic properties of Events are similar to those of Concepts, covered in Concepts and Concept Items. In this framework, we can expand the "what" information of an Event by indicating one or more relationships to other events, using the properties of Broader, Narrower, Related and SameAs. (See Event Relationships)
14.2.3. When does the Event take place?
The "when" of an event uses the Dates wrapper to express the dates and times of events: the start, end, duration and recurrence.
<dates>
<start>2025-10-14T13:00:00Z</start>
<duration>P3D</duration>
</dates>Although start and end times may be specified precisely, in the real world of news, the timing of events is often imprecise. In the early stages of planning an event, the day, month or even just the year of occurrence may be the only information available. Providers also need to be able to indicate a range of dates and/or times of an event, with a "best guess" at the likely date-time. (See Dates and times for details)
14.2.4. Where does the Event take place?
The "where" of an event is expressed using Location, a rich structure containing detailed information of the event venue (or venues); including GPS coordinates, seating capacity, travel routes etc.
<location>
<name>86, Edgeware Road, London W2 2EA, United Kingdom</name>
<related rel="ex-frel:venuetype" qcode="ex-ventyp:confcentre" />
<POIDetails>
<position latitude="51.515659" longitude="-0.163346" />
<contactInfo>
<web>https://www.etcvenues.co.uk</web>
</contactInfo>
</POIDetails>
</location>Note that if in-depth location details are given in the Event structure, this is a "one-time" use of the information. This structure might be better used as part of a controlled vocabulary of locations, in which case the structures may be copied from a referenced concept containing the location information.
See Further Properties of Event Details for details of Location and a comprehensive list of other Event properties.
14.2.5. Who is involved?
Details of "who" will be present at an event are given using the Participant property. This can expressed simply using a QCode, URI or literal value, supplemented by a human-readable Name property, or optionally using additional properties describing the participants, their roles at the event, and a wealth of related information.
<participant qcode="eprol:director">
<name>Brendan Quinn</name>
<personDetails>
<contactInfo>
<email>mdirector@iptc.org</email>
</contactInfo>
</personDetails>
</participant>Note use of the IPTC Event Participant Role New Code (Scheme URI http://cv.iptc.org/eventparticipantrole/), with recommended Scheme Alias of "eprol" The event organisers are also an important part of the "who" of an event. A set of Organiser and Contact Information properties can give precise details of the people and organisations responsible for an event, and how to contact them. See Further Properties of Event Details for details
14.3. Event Coverage
The NewsML-G2 Planning Item is used to inform customers about content they can expect to receive and if necessary the disposition of staff and resources. (See Editorial Planning – the Planning Item).
The link between an Event and the optional Planning Item is created using the Event ID. The Planning Item conveys information about the content that is planned in response to the Event, including the types of content and quantities (e.g. expected number of pictures). The Planning Item also has a Delivery structure which enables the tracking and fulfilment of content related to an Event.
14.4. Event Properties in more detail
The examples below show the basic properties of events, starting with the Name and Definition of the event, with other descriptive details, moving on to show how relationships, location, dates and other details may be expressed.
14.4.1. Event Description
In the code sample that follows, we will begin to create an event using four properties:
-
Event Name is an internationalised string giving a natural language name of the event. More than one may be used, for example if the Name is expressed in multiple languages.
-
Definitions, two differentiated by @role ("short" and "long") will be created using the Block element template (which allows some mark-up).
-
Notes – also Block type elements – give some additional natural language information, which is not naturally part of the event definition, again using @role if required.
-
Using Related, the nature of the Event can be refined and other properties of an Event can be expressed.
| Property | Type | Cardinality | Notes |
|---|---|---|---|
<name> |
Intl String |
1..n |
The name of the event, with optional @role for each <name> used |
<definition> |
Block |
1..n |
A natural language definition. |
<related> |
Flexible |
0..n |
The nature of the event, and other information. The property is repeatable and may have a @rel attribute to indicate the relationship to the characteristic. See the examples for alternative ways to express related concepts. |
<note> |
Block |
0..n |
A repeatable natural language note of additional information about the event, with an optional @role. |
For example:
<name xml:lang="en">
Bank of England Monetary Policy Committee
</name>
<definition xml:lang="en" role="ex-definitionrole:short">
Monthly meeting of the Bank of England committee
that decides on bank lending rates for the UK.
</definition>
<definition xml:lang="en" role="ex-definitionrole:long">
The Bank of England Monetary Policy Committee meets each
month to decide on the minimum rate of interest that will
be charged for inter-bank lending in the UK financial
markets. <br />
</definition>
<!-- Using related with a QCode -->
<related qcode="ex-eventrel:meeting" />
<!-- alternative using URI -->
<related uri="http://www.example.com/meeting" />
<!-- alternative using value and valuedatatype -->
<related rel="ex-csrel:admission" value="7.0" valueunit="iso4217a:EUR"
valuedatatype="xs:decimal" />
<note role="ex-noterole:toeditors">
Note to editors: an embargoed press release of the +
minutes of the meeting will be released by the COI +
within two weeks.
</note>
<note role="ex-noterole:general">
The meeting was delayed by two days due to illness.
</note>14.4.2. Event Relationships
Large news events may be split into a series of smaller, manageable events, arranged in a hierarchy which can express parent-child and peer relationships.
A "master" event may be notionally split into sub-events, which in turn may be split into further sub-events without limit. Each event instance can be managed separately yet handled and conveyed within the context of the larger realm of events of which it forms a part using the concept relationships <broader>, <narrower>, <related> and <sameAs> relationship properties.
Figure: Hierarchy of Events created using Event Relationships
It is important to note from the above diagram that Broader, Narrower and Same As have specific relationships to the same type of Concept that is in this case Events. Related has no such restriction. thus:
-
Aquatics is Broader than Breast Stroke or Swimming or Diving, but not Opening Speech.
-
Diving is Narrower than Aquatics, but not Archery.
-
Aquatics may be the Same As Aquatics in some other taxonomy, but not necessarily the Same As Swimming or Diving in some other taxonomy.
-
Breast Stroke may be Related to an Event, a Person or other Concept Type.
The examples below show the use of the event relationship properties for the fictional Economic Policy Committee event:
| Property | Type | Notes |
|---|---|---|
<broader> |
Related Concept |
Repeatable. The event may be part of another event, in which case this can be denoted by <broader>. |
<narrower> |
Related Concept |
Repeatable. May be used to indicate that the event has related child events. In this case we want to notify the receiver that a child of this event is the scheduled medal ceremony. |
<related> |
Related Concept |
Repeatable. May be used to denote a relationship to another concept or event. In this case, we want to link the event to an organisation which is not a participant, but may later form part of the coverage of the event. We qualify the relationship using @rel and the IPTC Item Relation NewsCodes: |
<sameAs> |
Related Concept |
Repeatable. May be used to denote that this event is the same event in another taxonomy, for example another governing body’s taxonomy of events: |
For example:
<broader
type="cpnat:event" qcode="ex-events:TR2012-34625">
<name>Olympic Swimming Gala</name>
</broader>
<narrower qcode="ex-events:TR2012-34593">
<name>Men’s 100m Freestyle Medal Ceremony</name>
</narrower>
<related
rel="irel:seeAlso"
type="cpnat:organisation"
qcode="ex-org:asa">
<name>Amateur Swimming association</name>
</related>
<sameAs qcode="ex-iocevent:xxxxxx">
<name>Men’s 100m Freestyle</name>
</sameAs>14.4.3. Event Details Group
The first set of properties of Event Details is date-time information as described below. The further properties are described in Further Properties of Event Details
Dates and times
The IPTC intends that event dates and times in NewsML-G2 align with the iCalendar (iCal) specification. This does not mean that dates and times are expressed in the same FORMAT as iCalendar, but the implementation of NewsML-G2 properties that match iCalendar properties should be as set forth in the iCalendar specification.
The <dates> property contains the dates and times of the event, expressed using the child elements of <start>, <end>, and <duration>
-
The <start> is the date, optionally with a time, on which the event starts.
-
The <end> is the date, optionally with a time, at which the event finishes. Note that the end dates/times of events are non-inclusive. Therefore a one day event on September 14, 2011 would have a start date (2011-09-14) and would have EITHER an end date of September 15 (2011-09-15) OR a duration of one day (syntax: see in table below).
-
The <duration> of the event may be used in place of <end>. Either may be used, but not both.
The NewsML-G2 syntax for expressing start and end times of events is a valid calendar date with optional time and offset; the following are valid:
-
2011-09-22T22:32:00Z (UTC)
-
2011-09-22T22:32:00-0500
-
2011-09-22
The following are NOT valid:
-
2011-09-22T22:32Z (if time is used, all parts MUST be present.)
-
2011-09-22T22:32:00 (if time is used, time zone MUST be present.)
When specifying the duration of an event, the date-part values permitted by iCalendar are W(eeks) and D(ays). In XML Schema, the only permitted date-part values are Y(ears), M(onths) and D(ays). (The permitted time parts H(ours), M(inutes) and S(econds) are the same in both XML Schema and iCalendar.)
Note on iCalendar alignment
In order to remain aligned with the iCalendar specification, it is recommended that the date-time expressed by <end> is “exclusive”. For example, following the guidelines above, a one-day event could be expressed as:
<eventDetails>
<dates>
<start>2025-01-01</start>
<end>2025-01-02</end>
</dates>
...
</eventDetails>However, event information expressed like this would not be intuitive to the human reader, who could interpret this as a two-day event. The IPTC therefore strongly recommends when using <end>, that fully qualified date-times are expressed so that this event information is unambiguous, thus:
<eventDetails>
<dates>
<start>2025-01-01T00:00:00Z</start>
<end>2025-01-02T00:00:00Z</end>
</dates>
...
</eventDetails>
Alternatively, <start> and <duration> may be used:
<eventDetails>
<dates>
<start>2025-01-01</start>
<duration>1D</duration>
</dates>
...
</eventDetails>
The following table shows the permitted values for date-part in both standards
| Duration | XML Schema | iCalendar |
|---|---|---|
D(ays) |
||
W(eeks) |
||
M(onths) |
||
Y(ears) |
Since NewsML-G2 uses XML Schema Duration, ONLY the values listed as permitted under the XML Schema column can be used, and therefore W(eeks) MUST NOT be used.
In addition the IPTC recommends that to promote inter-operability with applications that use the iCalendar standard, Y(ears) or M(onths) SHOULD NOT be used; only D(ays) should be used for the date part of duration values.
Duration units can be combined, in descending order from left to right, for example:
-
P2D (duration of 2 days)
-
P1DT3H (1 day and 3 hours – note the "T" separator)
iCalendar specifies that if the start date of an event is expressed as a Calendar date with no time element, then the end date MUST be to the same scale (i.e. no time) or if using duration, the ONLY permitted values are W(eeks) or D(ays). In this case, only D(ays) may be used in NewsML-G2.
The following table lists the date-time properties of events details:
| Property | Type | Notes/Example | ||
|---|---|---|---|---|
<start> |
Approximate Date Time |
Mandatory, non-repeatable property has optional attributes: @approxstart, @approxend and @confirmationstatus (or its URI sibling @confirmationstatusuri). The date part may be truncated, starting on the right (days) according to the precision required, but MUST, at minimum, have a year, (However, note the IPTC recommendation on iCalendar alignment). For example:
The value of <start> expresses the date, optionally with a time, on which the event starts. With the information available, this might be a "best guess". By using @approxstart and @approxend it is possible to qualify the start date-time by indicating the range of date-times within which the start will fall. (Note: these are NOT the approximate start and end of the event itself, only the range of start date-times) @approxstart indicates the start of the range. If used on its own, the end of the range of dates is the date-time value of <start> For example, a possible start of an event on June 12, 2011, not before June 11, 2011, and no later than June 14 2011, would be expressed as: The Confirmation Status of <start> is expressed by a QCode using one of the recommended IPTC Event Date Confirmation NewsCodes (Scheme Alias http://cv.iptc.org/newscodes/eventdateconfirm/, recommended scheme alias "edconf"). This has values:
The @confirmationstatus may also be applied to <end> or <duration>, described below. |
||
<end> |
Approximate Date Time |
Non-repeatable element to indicate the exclusive end date and time of the event, and optionally a range of values in which it may fall, using the same property type and syntax as for <start> (See recommendation on iCalendar alignment) |
||
<duration> |
XML Schema Duration |
Non-repeatable. The time period during which the event takes place is expressed in the form:
* The IPTC recommends that these units should NOT be used. Example: The event will last for three hours. Note use of the "T" time separator even though no Date part is present. The <dates> wrapper may contain either an <end> date, or a <duration> but not both. |
||
<confirmation> |
QCode |
DEPRECATED as of NewsML-G2 v2.24 - the <confirmation> property is replaced by a @confirmationstatus attribute (alternative: confirmationstatusuri) on the Events Details properties of <start>, <end>, and <duration>. See the description of these properties, above. |
Recurrence Properties
This is a group of optional properties that may be used to specify the recurring instances of an event, and conforms to the iCalendar specification, including the use of the same enumerated values for properties such as Frequency (@freq). Recurrence MUST be expressed using EITHER
<rDate>: one or more explicit date-times that the event is repeated, OR
<rRule>: one or more rules of recurrence.
| Property | Type | Notes/Example |
|---|---|---|
<rDate> |
Date with optional Time |
Recurrence Date. Repeatable. If the recurrence occurs on a specific date, with an optional time part, or on several specific dates and times. |
<rRule> |
Recurrence Rule |
Repeatable. The property has a number of attributes that may be used to define the rules of recurrence for the event. The only mandatory attribute is @freq, an enumerated string denoting the frequency of recurrence. The enumerated values of @freq are:
@interval indicates how often the rule repeats as a positive integer. The default is "1" indicating that for example, an event with a frequency of DAILY is repeated EACH day. To repeat an event every four years, such as the Summer Olympics, the Frequency would be set to ‘YEARLY" with an Interval of "4": @until sets a Date with optional Time after which the recurrence rule expires: @count indicates the number of occurrences of the rule. For example, an event taking place daily for seven days would be expressed as: A group of @byxxx attributes (as per the iCalendar BYxxx properties) are evaluated after @freq and @interval to further determine the occurrences of an event: @bymonth, @byweekno, @byyearday, @bymonthday, @byday, @byhour, @byminute, @bysecond, @bysetpos. The following code and explanation is based on an example from the iCalendar Specification at http://www.ietf.org/rfc/rfc5545.txt First, the interval="2" would be applied to freq="YEARLY" to arrive at "every other year". Then, bymonth="1" would be applied to arrive at "every January, every other year". Then, byday="SU" would be applied to arrive at "every Sunday in January, every other year". Then, byhour="8 9" (note that all multiple values are space separated) would be applied to arrive at "every Sunday in January at 8am and 9am, every other year". Then, byminute="30" would be applied to arrive at "every Sunday in January at 8:30am and 9:30am, every other year". Then, lacking information from rRule, the second is derived from <start>, to end up in "every Sunday in January at 8:30:00am and 9:30:00am, every other year". Similarly, if any of the @byminute, @byhour, @byday, @bymonthday or @bymonth rule part were missing, the appropriate minute, hour, day or month would have been retrieved from the <start> property. The @bysetpos attribute contains a non-zero integer "n" between ‑366 and 366 to specify the nth occurrence within a set of events specified by the rule. Multiple values are space separated. It can only be used with other @by* attributes. For example, a rule specifying monthly on any working day would be /> The same rule to specify the last working day of the month would be @wkst indicates the day on which the working week starts using enumerated values corresponding to the first two letters of the days of the week in English, for example "MO" (Monday), SA (Saturday), as specified by iCalendar. |
<exDate> |
Date with optional Time |
Excluded Date of Recurrence. An explicit Date or Dates, with optional Time, excluded from the Recurrence rule. For example, if a regular monthly meeting coincides with public holidays, these can be excluded from the recurrence set using <exDate> |
<exRule> |
Recurrence Rule |
Excluded Recurrence Rule. The same attributes as <rRule> may be used to create a rule for excluding dates from a recurring series of events. For example, a regular weekly meeting may be suspended during the summer. Note the order of the above statement: the <rRule> elements must come before <exRule> The meaning being expressed is: "The event occurs weekly until Dec 24, 2011 with a break from after July 23, 2011 until September 3, 2011." |
Further Properties of Event Details
The event details group are wrapped by the <eventDetails> element
| Property | Type | Notes/Example |
|---|---|---|
<occurStatus> |
QCode |
Optional, non-repeatable property to indicate the provider’s confidence that the event will occur. For inter-operability, it is highly recommended to use the IPTC Event Occurrence Status NewsCodes scheme (http://cv.iptc.org/newscodes/eventoccurstatus/, recommended scheme alias "eocstat"). The values in the scheme indicating the provider’s confidence of the status of the event, for example "Planned, occurrence highly uncertain": |
<newsCoverageStatus> |
Qualified Property |
Optional, non-repeatable element to indicate the status of planned news coverage of the event by the provider, using a QCode and (optional) <name> child element. For inter-operability, it is highly recommended to use the IPTC News Coverage Status NewsCodes (https://cv.iptc.org/newscodes/newscoveragestatus/, recommended scheme alias "ncostat"). This contains values to express whether coverage is "intended", "not intended", "not decided", or "on request". |
<eventStatus> |
Qualified Property |
Optional, non-repeatable element to indicate the status of the event, for example "this event is in progress" or "this event happened and is now in the past", using a QCode and (optional) <name> child element. For inter-operability, it is highly recommended to use the IPTC Event Status NewsCodes (https://cv.iptc.org/newscodes/eventstatus/, recommended scheme alias "eventstatus"). This contains values to express whether the event is "scheduled", "in progress", "completed", "postponed" or "cancelled". |
<registration> |
Block |
Optional, repeatable indicator of any registration details required for the event: The property optionally takes a @role attribute. IPTC Registration Role NewsCodes may be used, which currently has four values:
|
<accessStatus> |
QCode |
Optional, repeatable property indicating the accessibility, the ease (or otherwise) of gaining physical access to the event, for example, whether easy, restricted, difficult. The QCodes represent a CV that would define these terms in more detail. For example, "difficult" may be defined as "Access includes stairways with no lift or ramp available. It will not be possible to install bulky or heavy equipment that cannot be safely carried by one person". Note that the IPTC does not currently define such a vocabulary. |
<subject> |
Flexible Property |
Optional, repeatable. The subject classification(s) of the event, for example, using the IPTC Subject NewsCodes: |
<location> |
Flexible Property/ |
Repeatable property indicating the location of the event with an optional <name>. |
<participant> |
Flexible Property/ |
Optional, repeatable, The people and/or organisations taking part in the event. The type of participant is identified by @type and a QCode. The following example indicates a person, an organisation would be indicated (using the IPTC NewsCodes) by type="cpnat:organisation" An IPTC Event Participant Role NewsCode is available: that holds roles such as "moderator", "director", "presenter" |
<participationRequirement> |
Flexible Property |
Optional, repeatable element for expressing any required conditions for participation in, or attendance at, the event, expressed by a URI or QCode. The IPTC does not currently define a vocabulary of possible participation requirements. |
<organiser> |
Flexible Property/ |
Optional, repeatable. Describes the organiser of the event. The IPTC Event Organiser Role NewsCodes, viewable at http://cv.iptc.org/newscodes/eventorganiserrole/ lists types of organiser such as, "venue organiser", "general organiser", "technical organiser". |
<contactInfo> |
Wrapper element |
Indicates how to get in contact with the event. This may be a web site, or a temporary office established for the event, not necessarily the organiser or any participant. See Contact Information |
<language> |
- |
Optional, repeatable element describes the language(s) associated with the event using @tag with values that must conform to the IETF’s BCP 47. An optional child element <name> may be added. |
<newsCoverage> |
DEPRECATED. News Coverage is part of the NewsML-G2 Planning Item. (See Editorial Planning – the Planning Item) |
Contact Information
Contact information associated solely with the event, not any organiser or participant. For example, events often have a special web site and an event office which is independent of the organisers’ permanent web site or office address.
The <contactInfo> element wraps a structure with the properties outlined below. An event may have many instances of <contactInfo>, each with @role indicating the purpose. These are controlled values, so a provider may create their own CV of address types if required, or use the IPTC Event Contact Info Role NewsCodes (http://cv.iptc.org/newscodes/eventcontactinforole/ with recommended Scheme Alias of "ecirol"), which has values of "general contact", "media contact", ticketing contact".
Each of the child elements of <contactInfo> may be repeated as often as needed to express different @roles.
| Property Name | Element | Type | Notes |
|---|---|---|---|
Email Address |
<email> |
Electronic Address |
An “Electronic Address” type allows the expression of @role (QCode) to qualify the information, for example: <email role=“addressrole:office”> info@ecb.eu </email> |
Instant Message Address |
<im> |
Electronic Address |
<im role=“imsrvc:reuters”> jc.trichet.ecb.eu@reuters.net </im> |
Phone Number |
<phone> |
Electronic Address |
|
Fax Number |
<fax> |
Electronic Address |
|
Web site |
<web> |
IRI |
<web role=“webrole:corporate”> www.ecb.eu </web> |
Postal Address |
<address> |
Address |
The Address may have a @role to denote the type of address is contains (e.g. work, home) and may be repeated as required to express each address @role. |
Other information |
<note> |
Block |
Any other contact-related information, such as “annual vacation during August” |
For example:
<email role="ecirol:media">
office@iptc.org
</email>
<im role="ecirol:general">
jdoe.iptc.org@reuters.net
</im>
<phone role="ecirol:general">
1-123-456-7899
</phone>
<phone role="ecirol:media">
1-123-456-7898
</phone>
<web role="ecirol:ticketing">
www.iptc.org/springmeeting.html
</web>Address details <address>
The Address Type property may have a @role to indicate its purpose; the following table shows the available child properties. Apart from <line>, which is repeatable, each element may be used once for each <address>
For example:
<address role="ciprol:office">
<line>20 Garrick Street</line>
<locality>
<name xml:lang="en">London</name>
</locality>
<country qcode="iso3166-1a2:UK">
<name xml:lang="en">United Kingdom</name>
</country>
<postalCode>WC2E 9BT</postalCode>
</address>14.5. Multiple Event Concepts in a Knowledge Item
Information about multiple events can be assembled in a Knowledge Item, which conveys a set of one or more Concepts. In this example, we will use a Knowledge Item to convey two related events.
The top-level <knowledgeItem> element contains identification, version and catalog information, in common with other NewsML-G2 Items:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<knowledgeItem xmlns="http://iptc.org/std/nar/2006-10-01/"
guid="urn:newsml:iptc.org:20110126:qqwpiruuew4712"
version="18"
standard="NewsML-G2"
standardversion="2.35"
conformance="power"
xml:lang="en">
<catalogRef href="http://www.iptc.org/std/catalog/catalog.IPTC-G2-Standards_41.xml" />
<catalogRef href="http://www.example.com/events/event-catalog.xml"
/>The <itemMeta> block conveys Management Metadata about the document and the <contentMeta> block can convey Administrative Metadata about the concepts being conveyed, and in this case we can show Descriptive Metadata that is common to all of the concepts in the Knowledge item,
The Core Descriptive Metadata properties common to all NewsML-G2 Items that may be used in a Knowledge Item are: <language>, <keyword>, <subject>, <slugline>, <headline> and <description>.
<itemMeta>
<itemClass qcode="cinat:concept" />
<provider qcode="nprov:IPTC" />
<versionCreated>2021-06-10T12:00:00Z</versionCreated>
<pubStatus qcode="stat:usable" />
</itemMeta>
<contentMeta>
<urgency>5</urgency>
<contentCreated>2016-01-16T12:15:00Z</contentCreated>
<contentModified>2025-06-12T14:35:00Z</contentModified>
<subject qcode="medtop:20000304">
<name>media</name>
</subject>
<subject qcode="medtop:20000309">
<name>news agency</name>
</subject>
<subject qcode="medtop:20000763">
<name>IT/computer sciences</name>
</subject>
</contentMeta>The two events in the listing are related, with the relationship indicated by the second event using the <broader> property to show that it is an event which is part of the three-day event listed first
First event:
<conceptSet>
<concept>
<!-- FIRST EVENT! -->
<conceptId created="2025-06-26T12:15:00Z" qcode="ex-event:1234567" />
<name>IPTC Autumn Meeting 2025</name>
<eventDetails>
...Second event: a session on news gathering and verification below (ex-event:91011123) has a ‘broader’ relationship to the IPTC Autumn Meeting above (ex-event:1234567).
<concept>
<!-- SECOND EVENT! -->
<conceptId created="2025-09-26T12:00:00+00:00" qcode="ex-event:91011123" />
<name>Newgathering and Verification Strategy</name>
<broader type="cpnat:event" qcode="ex-event:1234567">
<name>IPTC Autumn Meeting 2025</name>
</broader>
<eventDetails>
...14.5.1. Full listing of the Event Knowledge Item
Note that although Knowledge Items are a convenient way to convey a set of related events, there is no requirement that all of the events in a KI must be related, or even that other concepts conveyed by the Knowledge Item are events; they may be people, organisations or other types of concept.
LISTING 15: Two Related Events in a Knowledge Item
All Scheme Aliases used in the listing below indicate IPTC NewsCodes vocabularies, except for the following alias values: ex-accst, ex-frel, ex-ventyp and ex-event.
<?xml version="1.0" encoding="UTF-8"?>
<knowledgeItem
xmlns="http://iptc.org/std/nar/2006-10-01/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://iptc.org/std/nar/2006-10-01/
./NewsML-G2_2.35-spec-All-Power.xsd"
guid="urn:newsml:iptc.org:20101019:qqwpiruuew4712"
version="18"
standard="NewsML-G2"
standardversion="2.35"
conformance="power"
xml:lang="en">
<catalogRef href="http://www.iptc.org/std/catalog/catalog.IPTC-G2-Standards_41.xml" />
<catalogRef href="http://www.example.com/events/event-catalog.xml" />
<itemMeta>
<itemClass qcode="cinat:concept" />
<provider qcode="nprov:IPTC" />
<versionCreated>2025-06-18T13:05:00Z
</versionCreated>
<pubStatus qcode="stat:usable" />
</itemMeta>
<contentMeta>
<urgency>5</urgency>
<contentCreated>2016-01-16T12:15:00Z</contentCreated>
<contentModified>2025-06-12T13:35:00Z</contentModified>
<subject qcode="medtop:20000304">
<name>media</name>
</subject>
<subject qcode="medtop:20000309">
<name>news agency</name>
</subject>
<subject qcode="medtop:20000763">
<name>information technology and computer science</name>
</subject>
</contentMeta>
<conceptSet>
<concept>
<!-- FIRST EVENT! -->
<!-- x -->
<conceptId created="2025-01-16T12:15:00Z" qcode="ex-event:1234567" />
<name>IPTC Autumn Meeting 2025</name>
<eventDetails>
<dates>
<start>2025-10-13T13:00:00Z</start>
<duration>P3D</duration>
</dates>
<registration>Registration with the IPTC office is required.
A <a href="https://admin.iptc.org/eventreg/aum2025/">
web form</a> may be used until 14 October 2025
</registration>
<participationRequirement>
<name>Membership</name>
<definition>Only members of the IPTC and their invited
guests may attend.
</definition>
</participationRequirement>
<accessStatus qcode="ex-access:easy" />
<language tag="en" />
<organiser qcode="nprov:IPTC" role="eorol:general">
<name>International Press Telecommunications Council</name>
<organisationDetails>
<founded>1965</founded>
</organisationDetails>
</organiser>
<contactInfo>
<email>mdirector@iptc.org</email>
<note>Brendan Quinn, Managing Director</note>
<web>http://www.iptc.org</web>
</contactInfo>
<location>
<name>86, Edgeware Road, London W2 2EA, United Kingdom</name>
<related rel="ex-frel:venuetype" qcode="ex-ventyp:confcentre" />
<POIDetails>
<position latitude="51.515659" longitude="-0.163346" />
<contactInfo>
<web>https://www.etcvenues.co.uk</web>
</contactInfo>
</POIDetails>
</location>
<participant qcode="eprol:moderator">
<name>Robert Schmidt-Nia</name>
<definition>Chairman of the Board of the IPTC</definition>
</participant>
<participant qcode="eprol:director">
<name>Brendan Quinn</name>
<definition>Managing Director</definition>
</participant>
</eventDetails>
</concept>
<concept>
<!-- SECOND EVENT! -->
<!-- x -->
<conceptId created="2025-01-16T12:00:00Z" qcode="ex-event:91011123" />
<name>Newgathering and Verification Strategy </name>
<broader type="cpnat:event" qcode="ex-event:1234567">
<name>IPTC Autumn Meeting 2025</name>
</broader>
<eventDetails>
<dates>
<start>2025-10-15T14:30:00Z</start>
<duration>PT30M</duration>
</dates>
<participationRequirement>
<name>Registration</name>
<definition>Pre-registration required for all attendees
</definition>
</participationRequirement>
<accessStatus qcode="ex-access:easy" />
<language tag="en" />
<participant qcode="eprol:presenter">
<name>Evi Varsou</name>
<definition>Presenter</definition>
</participant>
<participant qcode="eprol:moderator">
<name>Brendan Quinn</name>
<definition>Moderator</definition>
</participant>
</eventDetails>
</concept>
</conceptSet>
</knowledgeItem>14.5.2. Indicating changes to part of a Knowledge Item
When multiple Events are conveyed as Concepts in a Knowledge Item, and a sub-set of the Event Concepts is updated, providers may use the <partMeta> helper element to inform customers WHAT has changed in the new version of the Knowledge Item.
The <partMeta> element uses the standard XML ID/IDREF; the example shows the Event with @id="eventA" was modified on ‘2016-09-15’, as indicated by the Part Meta with @contentrefs="eventA":
<knowledgeItem
...>
<itemMeta>
...
</itemMeta>
<contentMeta>
...
</contentMeta>
<partMeta contentrefs="eventA">
<contentModified>2025-09-15</contentModified>
</partMeta>
<conceptSet>
<concept id="eventA">
<!-- FIRST EVENT! -->
<!-- x -->
<conceptId created="2025-08-30T12:00:00+00:00"
qcode="ex-event:1234567" />
...
</concept >
<conceptid="eventB">
<!-- SECOND EVENT! -->
<!-- x -->
<conceptId created="2025-08-30T12:00:00+00:00"
qcode="ex-event:91011123" />
...
</concept>
</conceptSet>
</knowledgeItem>14.6. Conveying Events in a NewsML-G2 Package
A news provider may wish to create a service that consists of collections of events that are significant to a specific editorial theme, for example, this could be the day’s Top Finance Events.
When such Events are available as Concept Items, they may be referenced in a Package using <itemRef> and @residref. (See the Packages chapter for details of the Package Item structure and Item references)
Alternatively, because they are managed and persistent Events identified using URIs, or their short format QCodes, collections of event concepts may be referenced within a Package <group> using Concept Reference <conceptRef> as follows:
<groupSet root="G1">
<group id="G1" role="ex-group:main">
...
<conceptRef type="cpnat:event"
qcode="ex-iptcevents:20081007135637.12">
<name xml:lang="fr">Barack Obama arrive à Washington</name>
</conceptRef>
...
</group>
</groupSet>Note the optional @type indicating that the referenced concept is an Event, and the optional <name> child element is a natural-language name for the event extracted from the concept being referenced.
Note the following guidelines on packaging Event Concepts:
-
"Hint" properties – these are properties extracted from the original concept and conveyed with the reference to the concept – are restricted to <name> only when using <conceptRef>. When using <itemRef>, ANY property may be extracted from the referenced Concept Item.
-
The provider must take care that "Hint" properties do not re-define the original concept. When a provider distributes concepts using Concept Items or Knowledge Items, changes to the original concept MUST be issued via an updated Concept Item and/or Knowledge Item and if a @version is used with the <itemRef>, @residref must be updated to correspond with the revised concept’s version.
-
If for the referenced concept a Concept Item is available then this concept’s Item MAY be referenced by <itemRef>; this is the preferred option. This MAY include Hint properties copied from the Concept Item.
-
If for the referenced concept a Concept Item is available then this concept MAY be referenced using <conceptRef> as a valid alternative option, for example when a package includes a mix of concepts for which some Concept Items are available and some are not available, but the provider wants to express the references in a consistent way. However, in a case such as this the constraint on the use of Hints has to be accepted.
-
If for a referenced concept there is no Concept Item and only a URI as identifier is available, then <conceptRef> MUST be used; no Hint properties, except a name, are available as there is no Concept Item available as a source for copying Hints.
The standard method for exchanging concept information in the NewsML-G2 context is the Knowledge Item, which is a container for concepts and the detailed properties of each concept being conveyed. A provider would use Knowledge Items to send comprehensive information about many events, and receivers might incorporate this information into their own editorial diary, or Day Book.
By contrast, when a Package is employed to reference Event concepts, this represents an Editorial product, in which a discrete number of events considered to be significant or pertinent to a particular topic, are selected and published.
The Events Package has the following characteristics:
-
The value of the package is in the journalistic judgement used to select the events, not in the compilation of the event information itself.
-
When using <conceptRef>, the package is a lightweight container that references each event and a human-readable name; no further details of the events are given. In this case, the package is transient in nature: it will not be referenced over time except as an archived item of editorial content.
-
It may be ordered to indicate the relative significance of the events in the context of the package, but no other relationship between the events is expressed or implied.
-
New versions of the Package may be published; events may be replaced or deleted from the package, but details of the events themselves cannot be changed.
The characteristics of a KI are:
-
It represents Knowledge; the value is in the compilation of the details about each event in the KI: the "when and where" and other practical information about each event.
-
The KI contains persistent information about each event concept that may be expected to be frequently used and if necessary updated over time.
-
The concepts in the KI cannot be ordered, but may be related.
-
New versions of the KI can be published and the concepts that it contains can be updated, but they must not be deleted, as this would break existing references to the concepts.
14.7. Events Workflow
Figure: Event Flow using Package Items and Knowledge Items
The flow diagram shows how the News Provider creates and compiles event information and publishes it in a Knowledge Item, and that the Customer’s events management system subscribes to this information.
Later, the News Provider’s editorial team reviews the events database and creates an ordered list of the "Top Ten" news events of the day. The News Provider publishes the list as a Package Item. The Package Item is ingested by the Customer’s editorial system, and the Customer’s journalists use it as a guide in planning the news coverage of the day, looking up details of each event (hosted in the Knowledge Item) as needed.
14.8. Events in a News Item
Many news providers, particularly news agencies, provide their customers with event information as a list of events, for example a list of cultural events taking place in a city’s theatres. In many cases, these were provided as a text story, with minimal mark-up.
Conveying these events in a News Item as described below can be useful, as the structured mark-up enables them to be re-formatted by software, for example as tables or listings in print and online media. Note, however, that this is a limited and specific use case; events in this form are NOT persistent, and cannot be managed as part of the News Planning process (as described in Editorial Planning – the Planning Item).
The Content Set of the Events News Item uses the <inlineXML> element to convey an <events> wrapper containing one or more <event> instances, each of which is a separate self-contained set of event information:
<contentSet>
<inlineXML>
<events>
<event>
<name>Newsgathering and Verification Strategy</name>
<eventDetails>
<dates>
<start>2025-10-15T14:00:00Z</start>
<end>2025-10-15T14:30:00Z</end>
</dates>
</eventDetails>
</event>
</events>
</inlineXML>
</contentSet>The full listing is shown below. Note the Item Class of this News Item is "ninat:composite".
LISTING 16: A Set of Events carried in a News Item
All Scheme Aliases used in the listing below indicate IPTC NewsCodes vocabularies, except for the following alias values: ex-frel, ex-ventyp and ex-facilncd.
<?xml version="1.0" encoding="UTF-8"?>
<newsItem
xmlns="http://iptc.org/std/nar/2006-10-01/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://iptc.org/std/nar/2006-10-01/
./NewsML-G2_2.35-spec-All-Power.xsd"
guid="urn:newsml:iptc.org:20090122:qqwpiruuew4711"
version="18" standard="NewsML-G2" standardversion="2.35" conformance="power"
xml:lang="en">
<catalogRef href="http://www.iptc.org/std/catalog/catalog.IPTC-G2-Standards_41.xml" />
<itemMeta>
<itemClass qcode="ninat:composite" />
<provider qcode="nprov:IPTC" />
<versionCreated>2025-06-18T12:44:00Z
</versionCreated>
<pubStatus qcode="stat:usable" />
</itemMeta>
<contentSet>
<inlineXML>
<events>
<!-- x -->
<!-- FIRST EVENT! -->
<!-- x -->
<event>
<name>IPTC Autumn Meeting 2025</name>
<eventDetails>
<dates>
<start>2025-10-14T13:00:00Z</start>
<duration>P3D</duration>
</dates>
<location>
<name>86, Edgeware Road, London W2 2EA, United Kingdom</name>
<related rel="ex-frel:venuetype" qcode="ex-ventyp:confcentre" />
<POIDetails>
<position latitude="51.515659" longitude="-0.163346" />
<contactInfo>
<web>https://www.etcvenues.co.uk</web>
</contactInfo>
</POIDetails>
</location>
</eventDetails>
</event>
<!-- x -->
<!-- SECOND EVENT! -->
<!-- x -->
<event>
<name>Annomarket text analytics EU project</name>
<eventDetails>
<dates>
<start>2025-10-15T14:00:00-04:00</start>
<end>2025-10-15T15:00:00-04:00</end>
</dates>
</eventDetails>
</event>
<!-- x -->
<!-- THIRD EVENT! -->
<!-- x -->
<event>
<name>Accidental Heroes</name>
<definition>
News stories and random incidents provide the inspiration behind
this new production from the Lyric Young Company, which blends the
inconsequential with the life-defining in a physical and visually
arresting new show.
<br />
The Lyric Young Company has worked with award-winning
writer/director Mark Murphy to create Accidental Heroes.
<br />
</definition>
<related rel="ex-frel:facility" qcode="ex-facilncd:Food" />
<related rel="ex-frel:facility" qcode="ex-facilncd:AirConditioning" />
<eventDetails>
<dates>
<start>2025-10-23T19:30:00Z</start>
<end>2025-02-05T23:59:59Z</end>
<rRule freq="DAILY" byday="TH FR SA" />
</dates>
</eventDetails>
</event>
</events>
</inlineXML>
</contentSet>
</newsItem>14.8.1. Adding event concept details to a News Item
Expressing Events as Concepts in a Concept Item gives implementers great scope for including and/or referencing events information in other Items, such as News Items conveying content. This is achieved by adding the event as a <subject> element of the <contentMeta> container. For example in 0 an event was conveyed as a concept within the Concept Set of a Knowledge Item:
<knowledgeItem
...>
<conceptSet>
<concept>
<!-- FIRST EVENT! -->
<!-- -->
<conceptId created="2025-01-16T12:15:00Z" qcode="ex-event:1234567" />
<name>IPTC Autumn Meeting 2025</name>
<eventDetails>
...
</eventDetails>
...
</knowledgeItem>The QCode ex-event:1234567 uniquely identifies the event, and later news coverage of the event can reference it using the <subject> element, as shown below:
<newsItem
...>
<contentMeta>
...
<subject type="cpnat:event" qcode="ex-event:12345657">
<name>IPTC Autumn Meeting 2025</name>
</subject>
...
</contentMeta>
...
</newsItem>Referencing an event using Subject enables News Items to be searched and/or grouped by event, and also helps end-users manage the content for events with a wide coverage and many delivered Items.
14.8.2. Using <bag> to create a composite concept
Providers can put an event and related concepts together to create a new composite concept using a <bag> child element of <subject>.
For example, a financial news service sends a News Item conveying content about a takeover of a small company by a larger global company. This takeover story has an event concept, which enables the provider to add a subject property containing the QCode of the Event:
<subject type="cpnat:event" qcode="ex-finevent:takeover123AB" />The provider also adds <subject> properties for each company:
<subject type="cpnat:organisation" qcode="isin:exampleSmallCompany" />
<subject type="cpnat:organisation" qcode="isin:exampleGlobalCompany" />However, a new, richer, composite concept combining the concept IDs for the Event and the two companies could be created instead using <bag>:
<newsItem ...>
...
<contentMeta>
...
<subject type="cpnat:abstract">
<name>GlobalCompany takes over SmallCompany</name>
<bag>
<bit type="cpnat:event" qcode="ex-finevent:takeover123AB" />
<bit type="cpnat:organisation" qcode="isin:exampleSmallCompany" />
<bit type="cpnat:organisation" qcode="isin:exampleGlobalCompany" />
</bag>
</subject>
...
</contentMeta>
...
</newsItem>|
In this example, the <subject> does not have its own identifier; these properties must NOT be used when <subject> has a <bag> element |
Using @significance with <bag> (Events only)
The composite structure of <bag> enables providers to "fine tune" the subject properties of an event using @significance. This feature is only available for events: the <bag> MUST contain a <bit> of type "cpnat:event" in order to use @significance with other <bit> members of the <bag>.
The example below shows that the significance of an event to all of the entities referenced in the <bag> is different: for an end-user interested in news about a small company, the fact that it has been taken over by a large company is more significant. To the follower of news about the large company, the story is less significant.
<subject type="cpnat:abstract">
<name>GlobalCompany takes over SmallCompany</name>
<bag>
<bit type="cpnat:event" qcode="ex-finevent:takeover123AB" />
<bit type="cpnat:organisation" qcode="isin:exampleSmallCompany" significance="100"/>
<bit type="cpnat:organisation" qcode="isin:exampleGlobalCompany" significance="10"/>
</bag>
</subject>