Smarter city data model standards landscape, Part 1: Core

Cities face many challenges on their path to becoming smarter. Information exchange is particularly challenging among city agencies, regardless of city size. The proliferation of different vendor solutions deployed across agency and departmental boundaries is the root of the problem. The solution is defining a common, standards-based smarter city data model that determines how information is structured and what it represents on a semantic level. This article focuses on the core concepts and standards that are common across multiple smarter city domains, such as public safety, transportation, and water.


Arnaud Le Hors (, Senior Software Engineer, IBM

Photo of Arnaud Le HorsArnaud Le Hors, a member of IBM software standards group, is responsible for driving the coordination of several IBM standards activities from a strategic and technical point of view. Arnaud has been working on open standards for 15 years, both as a staff member of the X Consortium and W3C. He has been involved in every aspect of the standards development process, including technical, strategic, political, and legal, both internal and external to an SDO and to a company like IBM. Arnaud was involved in the development of standards such as HTML and XML and one of the lead architects for Xerces, the XML parser developed by the Apache Software Foundation.

John Meegan (, Senior Software Engineer, IBM

John Meegan is a senior member of the IBM Software Group Strategy and Technology group where he is currently focused on standards efforts for IBM's smarter city and cloud initiatives. Before his standards work, he spent several years developing the IBM Software Group open source strategy, working with both customers and industry consultants to communicate and refine the strategy. He also spent several years in the Software Group Strategy organization, where he contributed to the formulation of the initial IBM web application server strategy, leading to the eventual launch of the IBM WebSphere product family. He received a Bachelor of Arts (BA) degree in Computer Science from Columbia University.

Keith Wells (, Advisory Software Engineer, IBM

Keith Wells photoKeith Wells, a developer on the Software Standards team, has enjoyed opportunities to actively develop code, demos, tactics and strategies with many standards over the past ten years. Keith is technically curious and feels passion and excitement developing interesting and practical products as well as collaborating with people who also have diverse skills.

20 September 2011

Also available in Chinese Russian Spanish


This article, the first in our series about standards relevant to data modeling for smarter city solutions, focuses on core concepts common across multiple smarter city domains, such as transportation, public safety, and water. We will provide standards for other domains in future parts of this series.

Our primary objective for Part 1 is to provide a reference for the standards relevant to data modeling for smarter city solutions. We identify gaps where standards are not yet defined. We recommend how to use existing standards and how to address standards gaps.

The IBM Smarter Cities vision is based on the premise that the world is becoming more interconnected, instrumented, and intelligent, and this constitutes an opportunity for new savings, efficiency, and possibility for progress. Underneath this premise lies the foundational element of standards.

Standards are key for:

  • Interoperability
  • Data representation and exchange
  • Aggregation
  • Virtualization
  • Flexibility

While it is possible to develop ad hoc solutions, these limit long-term impact.

Cities are inherently heterogeneous, which often causes diverse vendor solutions to be deployed across agency and departmental boundaries. As a result, cross-agency collaboration and information exchange may be hampered. Smarter city solutions need to facilitate the triage and selection of pertinent information for use across agencies in a structured manner. Establishing a standards-based data model is imperative.

Data models define how information is structured and what it represents on a semantic level. For instance, an accident report would:

  • Define the contents.
  • Set the structure of the contents.
  • Set relationships to other information.

It might identify the location of the accident, for example, and provide representational data using a postal address, geographic coordinates, or some other location system.

For an agency to process and correctly interpret information provided by another agency, it needs to understand the underlying data model. Each agency typically uses its own data model designed to address its specific needs within the constraints imposed by legacy systems.

Reconciliation of the disparity in the data models is vital. Defining a common smarter city data model simplifies the translation process since mapping to and from agency specific models is confined to the common model. Smarter city solutions should consider and use various standards to help define and leverage a common data model.

Scenario: Planned roadwork

Walking through an end-to-end flow of a typical city scenario can effectively identify key concepts for a smarter city information model. We can position the context of existing standards and identify standards gaps. The planned roadwork scenario below highlights key concepts common in most smarter city solutions. The intent of this section is to be illustrative and not exhaustive.

Brief description

The planned roadwork scenario is an upcoming event involving major road repair at a busy city intersection. The road repair originates in the transportation agency as a planned activity scheduled for a specific date and location with specified duration.

Coordination of the repair requires impact determination by other affected city domains that include buses and trains, water, utility, buildings, and public safety. Collaboration among the domains effectively minimizes overall disruption to traffic flow, facilitates shorter duration of the repairs, and reduces total cost.

Personnel critical to the coordination of the planned roadwork scenario include:

  • Operators
  • Supervisors
  • Responders
  • Analysts
  • Asset managers

In addition, a number of key performance indicators (KPIs) are created and maintained to track the effectiveness of a specific response and its associated procedures. Examples of KPIs include:

  • Response time
  • Time to closure
  • Cost to city
  • Savings to city
  • Impact to city services

Basic flow of events

  1. The asset manager in the transportation agency plans for major road repairs, in two months time, to a busy city intersection with estimated duration of one week.
    1. The asset manager creates a work order to manage the repair.
  2. After receiving the work order, the transportation agency operator creates an advisory to notify other city agencies and departments of the repair work.
  3. Analysts within affected agencies and departments perform initial impact analysis, which they might optimize using business rules and analytics to automate standard operating procedures.

    After they determine agency-specific impacts, all will perform a collaborative overall analysis (refer to step 4).

    1. Bus department determines one of its bus routes will be impacted.
    2. Water agency determines pipe maintenance (in same area) could be synced with the road repair.
    3. Electric utility determines underground infrastructure maintenance (in same area) could be synced with the road repair.
    4. Public Housing department determines several of its buildings will be impacted.
    5. Police department determines it may need to assign police officers to the scene to direct traffic during rush hour when the repairs are active.
  4. The supervisors of the impacted agencies initiate an inter-agency collaboration and impact analysis.
    1. Asset managers across all the impacted agencies/departments coordinate and finalize action plans.
    2. Because the road repair will impact several agencies, a supervisor at the city level assumes overall ownership of coordinating the work effort.
  5. Roads, bus, water, utility, buildings, and public safety supervisors inform their respective asset managers to execute maintenance and scheduling plans.
    1. Work is coordinated across the agencies to ensure safety and smooth operation.
    2. Appropriate broadcasts are issued to alert the citizen community of:
      1. Road closures and alternate routes
      2. Bus rescheduling and reroute plans
      3. Water service disruption to public drinking supply
      4. Utility service disruption indicating outage schedule
      5. Building service disruption to residents of affected properties
    3. The supervisor at the city level is kept abreast of progress and target completion.
  6. Maintenance work is completed, on schedule, in a coordinated fashion by agency personnel (responders).
    1. Work orders across all impacted agencies are closed.
    2. Appropriate broadcasts are issued to alert the citizen community.
  7. The supervisor at the city level executes a post mortem cost and impact analysis to determine the effectiveness of overall response.

Key model concepts

There are several model concepts that are fundamental to the planned roadwork scenario described above: organization, alert, incident, person, asset, work order, process, KPI location, and time. In addition, there are strong relationships amongst many of these concepts. The applicability of existing standards and the extent of standards gaps vary significantly for each concept.

  • Organization
    • Definition: A group of persons organized for a particular purpose
    • Examples: Police department, public housing department, bus department, transportation agency, water agency, electric utility
    • Key attributes: Name, type of organization, description, identification, website
    • Key relationships: Organizations (parent-child), assets, location
    • Standards assessment: National Information Exchange Model (NIEM): NIEM-Core (nc:)OrganizationType, UCore (Universal Core) organization
    • Definition: A warning or alarm for an imminent event
    • Examples: Road repair advisory
    • Key attributes: Sender, description, urgency, severity, certainty, onset time, location, supporting resources
    • Key relationships: Sender (organization or person), location, incident, work orders
    • Standards assessment: The Common Alerting Protocol (CAP) has extensive support for the alert concept. The UCore Event concepts are also applicable.
  • Incident
    • Definition: An occurrence or an event that may require a response
    • Examples: Road repair, automobile accident, water main bursting, criminal activity
    • Key attributes: Date and time of the incident, description, ID
    • Key relationships: Location, alerts, work orders, owner (organization or person)
    • Standards assessment: NIEM:nc:IncidentType, CAP:alert:incidents, UCore Event, Service-Oriented Architecture (SOA) Ontology Event
  • Person
    • Definition: A human being, an individual
    • Examples: James, Bob, Sally
    • Key attributes: Full name, given name, family name, gender, date of birth, place of birth, citizenship, country of birth
    • Key relationships: Employer, location, address, organization, role (such as operator, supervisor, responder, analyst, asset manager)
    • Standards assessment: NIEM:nc:PersonType, UCore Person, SOA Ontology Human Actor
  • Asset
    • Definition: A tangible object that can be tracked over time
    • Examples: Road, water pipe, electric capacitor, bus, building
    • Key attributes: Description, ID
    • Key relationships: Organization, person, manufacturer, location, work order, incident
    • Standards assessment: NIEM:ip: AssetType, UCore Entity
  • Work order
    • Definition: An order to do some work; to fix, repair or replace
    • Examples: Road repair, utility maintenance on a main valve, re-routing of buses
    • Key attributes: Description, ID, comment, priority, status, location, start date/time, stop date/time
    • Key relationships: Work steps, work orders (parent-child), incident, alert, organization, maintenance history, specification, person, assets
    • Standards assessment: No relevant standards identified at this time.
  • Process and procedure
    • Definition: A series of actions to accomplish a goal
    • Examples: Road repair notification and coordination
    • Key attributes: Process document
    • Key relationships: Process steps, work orders, incident, alert, organization, person, assets
    • Standards assessment: SOA Ontology Process
  • Key Performance Indicator
    • Definition: A measurement or criteria to assay the condition or performance of a person, process, or thing
    • Examples: Response time, time to closure, cost to city, savings to city, impact to city services
    • Key attributes: Description, metrics, thresholds
    • Key relationships: KPI (parent-child), organization, incident, alert, process and procedure, asset
    • Standards assessment: No relevant standards identified at this time.
  • Location
    • Definition: A geographic place, point, position, or area identified by its coordinates in an earth based coordinate system, name, or address
    • Examples: Road repair location: city intersection, water pipe location
    • Key attributes: Geographic coordinates, postal address, TimeStamp
    • Key relationships: Person, organization, asset, incident, alert
    • Standards assessment: NIEM:nc:LocationType, UCore Location, Geography Markup Language (GML) Point, OpenGIS® Open Location Service (OpenLS) Location
  • Time
    • Definition: Measuring system used to sequence events, to compare the durations of events and the intervals between them, and to quantify rates of change such as the motions of objects
    • Examples: Start time, end time
    • Key attributes: Years, months, weeks, days, hours, minutes, seconds, milliseconds
    • Key relationships: Duration
    • Standards assessment: NIEM:nc:DateTime, W3C DateTimeDescription

Standards inventory

This section highlights existing standards that are pertinent to smarter city modeling. We provide a brief description of the standard and positioning with other relevant standards. We include recommendations on how you should use the standard. We cover the list of recommended standards from the National Incident Management System (NIMS) and others in this document. (See Resources.)

National Information Exchange Model (NIEM)

NIEM is an XML-based information exchange framework from the U.S. representing a collaborative partnership of agencies and organizations across all levels of government (federal, state, tribal, and local) and with private industry. (See web site details in Resources.) The purpose of this partnership is to share critical information effectively and efficiently at key decision points across multiple domains, which include the justice, public safety, emergency and disaster management, intelligence, and homeland security. NIEM is designed to develop, disseminate, and support enterprise-wide information exchange standards and processes that will enable jurisdictions to automate information sharing.

The NIEM data model consists of core and domain-specific concepts. It shares and deciphers core concepts universally among all (or almost all) domains. Examples of entities that are core include:

  • Activity
  • Address
  • Case
  • Date and time
  • Document
  • Item
  • Incident
  • Location
  • Organization
  • Person

To become a universal component, all domains must agree on the semantics and structure of the component. Once established, the set of NIEM universal components is stable and relatively small.

NIEM facilitates the inclusion of external standards even though there may be overlapping semantics. For example, substitution groups and adapter types for external geospatial components have been defined for:

  • Open Geospatial Consortium (OGC),
  • Logical Interchange Format (LIF),
  • LandXML,
  • International Association for Interoperability (IAI), and
  • ANSI.

NIEM domain-specific concepts are unique to a single agency or unit of government. NIEM domains include:

  • Biometrics
  • CBRN (chemical, biological, radiological, and nuclear)
  • Emergency management
  • Immigration
  • Infrastructure protection
  • Intelligence
  • International trade
  • Justice
  • Maritime
  • Screening
  • Youth and family services

NIEM has been gaining adoption in many U.S. federal agencies and state and local governments, as well as expanding into other domains. In addition, other national government agencies are considering NIEM. For example, Eurojust and SEMIC-EU have included an investigation of NIEM as a part of their development of European governmental exchange standards. NIEM, however, is not considered an international standard, nor does it address international vocabularies or taxonomies at this time.

Smarter city modeling efforts should consider the use of both the NIEM core and domain-specific concepts. For core, the concepts for people, places, events, and things are especially relevant. Smarter city models must be able to consume and emit NIEM compliant messages.

Universal Core

Universal Core (UCore) is a U.S. Federal information sharing initiative that supports the National Information Sharing Strategy and all associated departmental and agency strategies. (See Resources.) UCore enables information sharing by defining an implementable specification (XML schema) containing agreed upon representations for the most commonly shared and universally understood concepts of who, what, when, and where. UCore specifies a framework, metadata, extension rules, security marking, and physical schema to permit content sharing between dissimilar systems. However, a key objective in creating UCore is to keep it simple, easy to explain, and easy to implement.

To facilitate adoption, UCore establishes Communities of Interest, or knowledge domains, to encourage adoption of common vocabularies. Many agencies and organizations already have formats to represent and share information assets. Unfortunately, those formats are often incompatible across community boundaries. UCore is not expected to replace complex data sharing within highly developed domains. UCore allows each community to continue representing their information assets using their community-defined schemas. Pertinent information is extracted from existing message formats (like NIEM) to create a conforming UCore message.

The UCore digest communicates information about entities, events, people, organizations, locations, collections, and the relationships that link them together. The digest provides the common set of XML elements that all UCore producers and consumers understand. UCore also provides a taxonomy of terms in the form of a Web Ontology Language (OWL) file for classifying events and entities. This file lists specific taxonomic terms, along with their definition and source. The taxonomic terms are used in the digest as part of the what element.

From a smarter city modeling perspective, UCore should be used to define and model the core concepts of entities and assets, events and alerts, people, organizations, locations, and collections, along with the relationships that link them together. In addition, a smarter city model should leverage the OWL-based UCore taxonomy of terms that classify events and entities. Lastly, a smarter city model must be able to consume and emit UCore messages.

Common Alerting Protocol (CAP)

The Common Alerting Protocol (CAP) is one of the EDXL initiatives. (See Resources.) EDXL is a set of incident and emergency-related standards for data interoperability from OASIS. EDXL is a broad initiative to create an integrated framework for a wide range of emergency data exchange standards to support operations, logistics, planning, and finance.

CAP standardizes the content of alerts and notifications across all hazards, including law enforcement and public safety as well as natural hazards such as severe weather, fires, earthquakes, and tsunamis. CAP can be used to define and model the core concept of an alert, including key attributes such as category, status, scope, certainty, severity, urgency, onset time, expiration time, response type, instructions, etc.

Although CAP was created in the context of EDXL to address the specific needs of the emergency management domain, it is being adopted in the industry as a general-purpose alert protocol. As such, CAP qualifies as a core standard for smarter city solutions, which explains its inclusion in this article. EDXL, as a whole, is emergency management specific and will be discussed in a follow-up article specific to the emergency management domain.

Geospatial standards

The Open Geospatial Consortium (OGC) is an international organization of over four hundred organizations offering an array of standards for geospatial and location-based services. (See Resources.) These standards are freely available at no cost and cover data models, encodings, interfaces, and best practices.

OGC Abstract Specification

The OGC Abstract Specification provides the conceptual foundation on which the OGC Standards Baseline, the core OGC standards, is built. The OGC Reference Model describes these standards and how they relate to one another. (See Resources.)

Geospatial information encompasses both location and time. Locations can be described either as civic locations, such as a postal address, or as numeric coordinates in a coordinate reference system. The OGC Abstract Specification defines coordinate reference systems that have a reference to the Earth. It includes datum that define the origin, orientation, and scale of the coordinate system tied to the Earth.

OpenGIS Geography Markup Language (GML)

OGC's most prominent standard, GML, defines an XML grammar for the exchange of geospatial information on the Internet. The standard is available as an XML Schema and has become the reference for the transport and storage of geographic information in the industry. (See Resources.)

Because GML only covers geographic features, locations in GML can only be expressed based on geometric points. In particular, GML does not support civic locations. For this reason, GML is sub-optimal for the development of a core reference data model for smarter city solutions. Using one of the richer, higher-level standards that builds on GML, such as OpenGIS Location Services (OpenLS), appears to be a better approach.

OpenLS is designed for enabling location-based applications and defines several data types that are not part of GML such as location. OpenLS's location encompasses several types of locations, including an address defined in such a way that it can accommodate international addresses, a point of interest identified by name such as the name of a restaurant, or a geographic position defined by its coordinates. All of these types of locations can be of use in smarter city scenarios including the previously described planned roadwork.

OpenLS is defined as an XML Schema, based on GML's XML schema.

We will discuss other OGC standards, namely CityGML and KML, later in this series.

Time Ontology in OWL

Time Ontology in OWL is a W3C working draft describing the vocabulary and relationships for dates, times, durations, and time zones. (See Resources.) This ontology allows facts to be expressed about date and time content. For example, you can use this ontology to determine conflicts in schedules, compare dates, describe a particular interval of time, calculate the time in a particular geographical location, or simply describe temporal information in a web page.

Some OWL classes defined in this ontology include Interval, DurationDescription, DateTimeDescription, and DayOfWeek.

The concept of time is ubiquitous across the smarter city landscape: optimizing the scheduling of work crews to repair a road, determining the optimum time of day to schedule the work and avoid traffic delays, broadcasting an outage schedule for water or electricity, or rerouting buses for a period of time when the road is being repaired. The W3C Time Ontology serves as a solid model for temporal concepts in smarter city scenarios such as these.

SOA Ontology

The Open Group (TOG) Service-Oriented Architecture (SOA) Ontology provides both an OWL and UML ontological description for the core concepts, terms, and semantics of service-oriented architecture. (See Resources.) This common vocabulary allows businesses and software engineers to map business and marketing domains to technical terms to solve problems and create opportunities. The SOA Ontology creates a foundation, enables interoperability for municipal services, and promotes clarity and understanding for developing services between business and technical people.

The SOA Ontology describes these concepts and their relationships: service, process, task, event, human actor, effect, system, policy, service contract, service interface, and element.

This open standard can provide a basis for the process and procedure concepts included in the previously described planned roadwork scenario. It can also be used to describe working assumptions for defining and planning municipal programs and web-based service delivery.


As smarter city data model implementations progress, you should take the following steps to ensure consistency with the critical standards specified in this article:

  • Leverage the standards specified in section two of this document to help identify and model smarter city core entities
  • Design data models to carry the information necessary for an adequate mapping to and from these standards where appropriate. (Leveraging these standards does not mean designing a smarter city data model as a patchwork of these standards.)
  • Take into account all attributes and relationships specified where multiple standards define the same entity (i.e., organization, person, location, and more).
  • If similarly named entities exist in multiple standards but are significantly different, consider defining separate concepts for the entities.
  • Ensure that your smarter city model is able to consume and emit entities and concepts for all standards defined in section two of this document.
  • As smarter city models evolve and standards gaps are identified, consider engaging appropriate standards bodies to assist and address these gaps.


Standards will play an important role in the development of smarter city data models. This article has identified a number of critical standards applicable to core concepts you should use in the development of these data models. Future articles, extending into other domains, will evaluate additional standards for inclusion in smarter city data models.

Standards Index

Information about the standards listed in this table is not exhaustive. Send any additional information to the authors for future revision.

Standard Examples of supported concepts Current deployments
Common Alerting Protocol (CAP) Category, status, scope, certainty, severity, urgency, onset time, expiration time, response type, instructions International standard (OASIS plus ITU-T Recommendation X.1303) with deployments primarily in the U.S., which include: Department of Homeland Security, National Weather Service, United States Geological Survey, California Office of Emergency Services, Virginia Department of Transportation, and Oregon RAINS.
National Information Exchange Model (NIEM) Activity, address, case, date and time, document, item, incident, location, organization, person U.S. specific, with deployments that include: U.S. Department of Homeland Security, U.S. Department of Justice, U.S. Citizenship and Immigration Services, Federal Emergency Management Agency (FEMA), Law Enforcement Information Sharing Program, Logical Entity eXchange Specifications, OneDOJ, and the Department of Health and Human Services.
OpenGIS Geography Markup Language (GML) Point International standard (OGC) that is widely used in the industry, and considered the reference in its space.
OpenGIS Location Services (OpenLS) Location International standard (OGC)that is used for location based applications such as cell phone apps.
SOA Ontology Service, process, task, event, human actor, effect, system, policy, service contract, service interface, element International standard (TOG) that encapsulates SOA vocabulary and relationships and is used to describe and model SOA solutions.
Universal Core Entities and assets, events and alerts, people, organizations, locations, collections U.S. specific standard that is jointly managed by Department of Defense, Justice, and Homeland Security, and the Office of the Director of National Intelligence. Within the DoD, the Marine Corps, Navy, and Air Force appear to be committed to supporting UC.
W3C Time Ontology in OWL Interval, DurationDescription, DateTimeDescription, DayOfWeek International standard (W3C) with and uncertain adoption. Our web search revealed no concrete deployments.




  • Connect with other developerWorks users through developerWorks community while exploring the developer-driven blogs, forums, groups, and wikis.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Open source on developerWorks

Zone=Open source
ArticleTitle=Smarter city data model standards landscape, Part 1: Core