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:
- Data representation and exchange
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.
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:
- 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
- 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.
- The asset manager creates a work order to manage the repair.
- After receiving the work order, the transportation agency operator creates an advisory to notify other city agencies and departments of the repair work.
- 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).
- Bus department determines one of its bus routes will be impacted.
- Water agency determines pipe maintenance (in same area) could be synced with the road repair.
- Electric utility determines underground infrastructure maintenance (in same area) could be synced with the road repair.
- Public Housing department determines several of its buildings will be impacted.
- Police department determines it may need to assign police officers to the scene to direct traffic during rush hour when the repairs are active.
- The supervisors of the impacted agencies initiate an inter-agency
collaboration and impact analysis.
- Asset managers across all the impacted agencies/departments coordinate and finalize action plans.
- Because the road repair will impact several agencies, a supervisor at the city level assumes overall ownership of coordinating the work effort.
- Roads, bus, water, utility, buildings, and public safety supervisors
inform their respective asset managers to execute maintenance and
- Work is coordinated across the agencies to ensure safety and smooth operation.
- Appropriate broadcasts are issued to alert the citizen
- Road closures and alternate routes
- Bus rescheduling and reroute plans
- Water service disruption to public drinking supply
- Utility service disruption indicating outage schedule
- Building service disruption to residents of affected properties
- The supervisor at the city level is kept abreast of progress and target completion.
- Maintenance work is completed, on schedule, in a coordinated fashion
by agency personnel (responders).
- Work orders across all impacted agencies are closed.
- Appropriate broadcasts are issued to alert the citizen community.
- 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.
- 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.
- 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
- 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
- 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.
- 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
- 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
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:
- Date and time
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),
- International Association for Interoperability (IAI), and
NIEM domain-specific concepts are unique to a single agency or unit of government. NIEM domains include:
- CBRN (chemical, biological, radiological, and nuclear)
- Emergency management
- Infrastructure protection
- International trade
- 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 (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.
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.
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.
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.|
- Learn more about the IBM Smarter Cities initiative by visiting the project page.
- See the list of recommended standards from the National Incident Management System (NIMS) on the FEMA website.
- Learn more about the National Information Exchange Model (NIEM).
- Find details on UCore.
- See details on EDXL.
- Learn more about EDXL-CAP.
- Read further about the Open Geopspatial Consortium.
- See more details about the OGC Abstract Specification.
- Learn more about the OGC Reference Object Model.
- See more details about GML and OpenLS.
- Read further about W3C Time Ontology.
- Read The Open Group SOA Ontology Technical Standard 1.0" (developerWorks Dec 2010) for further information about this standard.
- Find more details about The Open Group Service Oriented Architecture Ontology.
- Find extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
- Follow developerWorks on Twitter tweets.
- Listen to developerWorks podcasts for interesting interviews and discussions about software development.
- Connect with other developerWorks users through developerWorks community while exploring the developer-driven blogs, forums, groups, and wikis.