We use cookies to give you the best experience and to help improve our website
Find out what cookies we use and how to disable themThis is part 1 of the multi-part standard that specifies a common data model for cities. Part 1 is a standard for Foundation Level concepts.
A common data model enables city software applications to share information, plan, coordinate, and execute city tasks, and support decision making within and across city services, by providing a precise, unambiguous representation of information and knowledge commonly shared across city services. This requires a clear understanding of the terms used in defining the data, as well as how they relate to one another. This requirement goes beyond syntactic integration (e.g. common data types and protocols), it requires semantic integration: a consistent, shared understanding of the meaning of information.
To motivate the need for a standard city data model, consider the evolution of cities. Cities deliver physical and social services that traditionally have operated as silos. If during the process of becoming smarter, transportation, social services, utilities, etc. were to develop their own data models, then we would have smarter silos. To create truly smart cities data must be shared across these silos which can only be accomplished through the use of a common data model. For example, “Household” is a category of data that is commonly used by city services. Members of Households are the source of transportation, housing, education, and recreation demand. It represents who occupies a home, age, occupations, where they work, abilities, etc. Though each city service may gather and/or use different aspects of a Household, much of the data needs to be shared with each other.
The city data model is stratified into three levels of abstraction. The Foundation Level covers very general concepts such as Time, Location, and Activity. The City Level covers concepts that are general to cities and span all services such as Households, Services, Residents. The Service Level spans concepts commonly associated with a particular service but still shared with other services, such as Vehicles and Transportation network. The process of development of this standard is to iteratively select a city service and apply the ontology engineering development process to create, extend and/or modify each level of the standard.
Before proceeding with a city service, discussions will be conducted and liaison relationships created with ISO, IEC, ITU-T, IEEE and other standards bodies whose focus is on the selected service. The first service to be selected is Transportation Planning. Discussions have been undertaken with TC204 WG1 and liaison relationships established. Based on this focus, we define the first three parts of our city model standard as being composed of:
• Part 1: Foundation level concepts, including Time, Location, Activity
• Part 2: City level concepts, including Household, Organization, People
• Part 3: Service level concepts: Transportation Planning concepts such as transportation assets and networks
Subsequent services will result in additional parts to the standard and revisions to existing parts.
This standard provides definitions in a machine-readable form using the Semantic Web Ontology language OWL. This enables the development of software tools that can consume, verify, and make inferences about city data. It will ensure that data can be easily combined and shared in order to effectively support city planning and operations.
This is Part 1 of 3: part 1 focuses on the technical definition of concepts that are fundamental to city services: Time, Location, Parthood, Activities, Resources, Recurring Events, Change, and Units of Measure.
You are now following this standard. Weekly digest emails will be sent to update you on the following activities:
You can manage your follow preferences from your Account. Please check your mailbox junk folder if you don't receive the weekly email.
You have successfully unsubscribed from weekly updates for this standard.
Comment on proposal
Required form fields are indicated by an asterisk (*) character.