City Data Model Project Collaboratory - User contributions [en-ca]

Pattern:Sensors Pattern

2022-09-21T11:59:05Z

MarkFox: Created page with "{{Pattern Definition |Description=The Sensors Pattern is included in this document due to the importance of data collection for all manner of city services. Data collection ef..."

{{Pattern Definition
|Description=The Sensors Pattern is included in this document due to the importance of data collection for all manner of city services. Data collection efforts take various forms – whether through manual canvassing or the use of sensors. With a growing access to the Internet of Things, data from available sensors will continue to expand, likely to include observations about persons, vehicles, and so on. It is important to not only capture the collected data, but the source of the observations.
The representation of sensors shall conform to the ontology specified in The W3C Recommendation “The SSN (Semantic Sensor Network) Ontology” [6]. It is included in its entirety with the prefix ‘ssn’. The W3C standard ontology for sensors and their observations, the SSN (Semantic Sensor Network) Ontology, accessed from http://www.w3.org/ns/ssn/ shall be used in the context of this document.
|Key Concepts and Classes=The SSN Ontology does not make any commitments as to whether instances of ssn:Property should be generic (e.g. ex:temperature) or specific to the feature of interest (e.g. ex:mybodytemperature). Current documentation suggests that this is a choice for the modeler. On the other hand, the City Data Model prescribes a definition of instances of ssn:Property at a generic level; this will enable the querying of sensors that observe some property (e.g. vehicle presence) regardless of the location. This is useful as there can be different kinds of sensors that observe the same properties (e.g. loop detectors vs Bluetooth sensors) and while they might not share the exact feature of interest, they can be in close enough proximity to be related and so a property indicating their similarity is desirable.
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Contact Pattern

2022-09-21T11:58:17Z

MarkFox: Created page with "{{Pattern Definition |Description=Contact information is relevant for a range of concepts in the city domain. For example, a building can have some associated address, similar..."

{{Pattern Definition
|Description=Contact information is relevant for a range of concepts in the city domain. For example, a building can have some associated address, similarly a person or an organization can have some contact address (or phone number, email address, and so on). Note that a person’s contact address can differ from their place of residence.
Rather than define these attributes separately for persons, organizations, and so on, it makes sense to capture the general concepts associated with contact information in a separate pattern.
The iContact ontology, accessed at http://ontology.eil.utoronto.ca/icontact.owl, is the basis of the core concepts and properties identified as necessary to define this type of information.
|Key Concepts and Classes=Both Address and PhoneNumber classes are designed to accommodate international versions. In addition to drawing from the iContact ontology, the pattern reuses concepts from the Spatial Location Pattern (defined in ISO/IEC 5087-1) to associate an address with a location.
The Address Class has the following properties:
• hasAddressType: Specifies the type of address, e.g., home, work.
• hasStreetNumber: Specifies the number of the street for the address.
• hasStreet: Specifies the name of the street for the address.
• hasStreetType: Specifies the type of the street for the address, e.g., road, drive.
• hasStreetDirection: Specifies the direction of the street for the address, e.g., east, west.
• hasUnitNumber: Specifies the unite or suite number of the address.
• hasPostalBox: Specifies the box number for the address.
• hasBuilding: Specifies the name of the building for the address.
• hasCitySection: Specifies the section of the city for the address.
• hasCity: Specifies the name of the city for the address.
• hasProvince Specifies the state or province for the address.
• hasPostalCode: Specifies the zip or postalcode for the address.
• hasCountry: Specifies the country for the address using ISO 3166-2 alpha-2 2 letter country code.
• spatialloc:hasLocation: Specifies a placename (e.g., geonames.org) and geometry for the address.
• wgs84:lat: Specifies the latitude for the address.
• wgs84:long: Specifies the longitude for the address.
The PhoneNumber class has the following properties:
• hasCountryCode: Specifies the country code for the number.
• hasAreaCode: Specifies the area code for the number.
• hasPhoneNumber: Specifies the remaining digits of the number after the area code.
• hasPhoneType: Specifies the type of phone number, e.g., cell phone, home phone, etc.
|Classes=Address, PhoneNumber
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Bylaw Pattern

2022-09-21T11:56:57Z

MarkFox: Created page with "{{Pattern Definition |Description=“Municipal by-laws are public regulatory laws which apply in a certain area. The main difference between a by-law and a law passed by a nat..."

{{Pattern Definition
|Description=“Municipal by-laws are public regulatory laws which apply in a certain area. The main difference between a by-law and a law passed by a national/federal or regional/state body is that a by-law is made by a non-sovereign body, which derives its authority from another governing body, and can only be made on a limited range of matters. A local council or municipal government derives its power to pass laws through a law of the national or regional government which specifies what things the town or city may regulate through by-laws. It is therefore a form of delegated legislation.” (Wikipedia, 2020)
“A municipal by-law is no different than any other law of the land, and can be enforced with penalties, challenged in court and must comply with higher levels of law. Municipal bylaws are often enforceable through the public justice system, and offenders can be charged with a criminal offence for breach of a bylaw.” (Alberta, 2017)
The intent of the Bylaw Pattern is to capture the major components of a city bylaw, such as dates, geographic areas of application, penalties, etc. It is not intended to provide a legal semantics with which to codify a particular bylaw. The following three types of bylaws are represented in the Bylaw Pattern (Alberta, 2017):
1. Main bylaws;
2. Amending bylaws, which reflect material changes, in principle or substance, to an existing bylaw; and
3. Revision bylaws, which reflect limited changes to an existing bylaw.
|Key Concepts and Classes=The core concept of the Bylaw Pattern is Bylaw. Its properties decompose a Bylaw into conceptual relevant components that support linking with other city concepts, and enable efficient search. The following are a Bylaw’s properties:
• schema:title: A short name for the Bylaw, to be used in other descriptions to refer to the Bylaw.
• schema:legislationJurisdiction: identifies the city that enacted the Bylaw. The range is restricted to City.
• schema:legislationIdentifier: a unique identifier for the bylaw. The range is a xsd:string.
• schema:abstract: a brief statement of the bylaw’s purpose. The range is a xsd:string.
• schema:keywords: keywords used to categorize the bylaw for search purposes. The range is zero of more xsd:string.
• schema:jurisdiction: The City or CityDivision where the bylaw applies. The range is restricted to City or CityDivision.
• schema:legislationType: Type of bylaw chosen from bylawMain, bylawAmending or bylawRevision.
• schema:legislationLegalForce: Specifies whether the Bylaw is currently in force, not in force or partially in force.
• hasDefinition: Words or phrases that are defined to have a specific meaning within the context of the Bylaw. The range is restricted to Definition.
• impacts: who and/or what is impacted by the Bylaw. Restricted to Person, Organization, LandArea, City, CityDivision and/or Activities.
• schema:legislationDate: Date which the Bylaw is officially adopted/signed by the legislationJurisdiction City or CityDivision.
• schema:datePublished: Date the Bylaw is officially published.
• dateInEffect: Date after which the Bylaw is in effect.
• schema:expires: Date the Bylaw expires.
• hasClause: Clauses that make up the body of the Bylaw. Restricted to Clause.
• hasPenaltyClause: Clauses that specify penalties for not adhering to the Bylaw.
• hasSeveranceClause: Clauses that specify that the bylaw remains valid if any portion of the bylaw is found to be invalid by a higher jurisdiction.
• hasTransitionClause: Clauses that cover the period during which entities affected by the bylaw can do things to conform to the new conditions.
• hasRepealClause: Clauses that specify all previous bylaws that deal with subjects that are addressed in the new bylaw must either be repealed or amended.
• hasSchedule: Schedules that are attached to the Bylaw and are referenced by the Bylaw. A Schedule is part of the Bylaw.
A MainBylaw is a subclass of Bylaw and has the following additional properties:
• schema:legislationType: value bylawMain
An AmendingBylaw is a subclass of Bylaw and has the following additional properties:
• schema:legislationChanges: The Bylaw that is being amended.
• schema:legislationType: value bylawAmending
An RevisionBylaw is a subclass of Bylaw and has the following additional properties:
• schema:legislationChanges: The Bylaw that is being amended.
• schema:legislationType: value bylawRevision
A Definition concept that specifies the defined terms used in the Bylaw. It has the following properties:
• schema:name: the formal term being defined. It is an xsd:string.
• schema:description: the definition of the schema:name.
A Clause is a statement of a rule, provision, requirement, etc. that is part of the body of the Bylaw, or its schedules, penalties, etc. It has the following properties:
• schema:identifier: Unique identifier/number for the clause. It is an xsd:string.
• schema:name: title or name of the clause, if any. It is an xsd:string.
• schema:description: the content of the clause.
• hasType: one of (severance or penalty or transition or repeal or schedule or bylaw)
• hasClause: links to any subclauses of this clause.
• mereology:properPartOf: The part of the Bylaw or clause this clause is contained in.
A Schedule is attached to the Bylaw and is part of the Bylaw. It has the following properties:
• schema:identifier: Unique identifier/number for the schedule. It is an xsd:string.
• schema:name: title or name of the schedule, if any. It is an xsd:string.
• schema:description: an introductory description of the Schedule. It is an xsd:string.
• hasClause: links to all clauses contained in the Schedule.
• mereology:properPartOf: The Bylaw this Schedule is part of.
|Classes=Bylaw, MainBylaw, AmendingBylaw, RevisionBylaw, Definition, Clause, Schedule
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Contract Pattern

2022-09-21T11:55:16Z

MarkFox: Created page with "{{Pattern Definition |Description=A contract is a legal document that specifies some agreement(s) between two or more parties. The aim of the Contract Pattern is not to formal..."

{{Pattern Definition
|Description=A contract is a legal document that specifies some agreement(s) between two or more parties. The aim of the Contract Pattern is not to formalize the semantics of all possible involved legal concepts, but rather to enable to representation of the general structure and contents of a particular contract. The Contract Pattern adopts the definition of Contract specified in the Financial Business Ontology (FIBO) [8] specified at: https://spec.edmcouncil.org/fibo/ontology/FND/Agreements/Contracts/ with a key modification that a Contract is defined as a type of Document and is distinct from an Agreement (not a subclass, as specified in FIBO).
|Key Concepts and Classes=A Contract is a document with the additional following properties:
• specifiesAgreement: identifies the Agreement(s) that are specified by some Contract.
• hasParty: identifies the person(s) and/or organization(s) that are involved in the Contract.
• hasSignatory: identifies the Person(s) responsible for signing the Contract.
• hasContractualElement: identifies the decomposition of a Contract into more precise parts.
• isValidFor: identifies the Interval in time over which the Contract is valid for, if applicable.
• isExecutedOn: identifies the Interval or Instant in time at which the terms in the Contract are executed, if applicable.
A ContractualElement represents a part of a contract. Therefore, it can only exist in the context of some Contract.
• hasContractText: identifies the excerpt of text from the Contract that corresponds to the Contractual Element.
A ContractualElement may be more precisely identified as:
• ConditionPrecedent: a part of the contract that identifies conditions that must be met in order for the contract to take effect.
• ContractualCommitment: a part of the Contract that identifies some Agreement between the parties.
• ContractualDefinition: a part of the Contract that defines key terms that are referred to in the Contract.
• NonBindingTerm: a part of the Contract that is not legally binding.
• Representation: a part of the Contract that specifies some assertions that are taken to be true at the time of the contract and serve to influence a party’s decision to enter into the Contract.
• Warranty: a part of the Contract that promises some indemnification if an assertion made in the Contract is false.
|Classes=Contract, ContractualElement, ConditionPrecedent, ContractualCommitment, ContractualDefinition, NonBindingTerm, Representation, Warranty
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Indicator Pattern

2022-09-21T11:53:05Z

MarkFox: Created page with "{{Pattern Definition |Description=ISO/IEC 21972 is normative, providing the pattern for a city Indicator. In the remainder of this section, we repeat only the top level concep..."

{{Pattern Definition
|Description=ISO/IEC 21972 is normative, providing the pattern for a city Indicator. In the remainder of this section, we repeat only the top level concepts and their properties for an Indicator.
|Key Concepts and Classes=An indicator is a quantity. It may be ratio of a numerator and denominator that are also quantities. It has a city and time period associated with it. The numerator and denominator quantities may have different units of measure.
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:City Service Pattern

2022-09-21T11:52:07Z

MarkFox: Created page with "{{Pattern Definition |Description=Cities provide a variety of services to residents and businesses, including health and social services. The city service pattern, is based on..."

{{Pattern Definition
|Description=Cities provide a variety of services to residents and businesses, including health and social services. The city service pattern, is based on the Canadian Government Reference Model (CGRM), depicted in Figure 3. It identifies the following concepts as a basis for understanding the services that governments (Wiseman, 2015):
• Programs are major city initiatives that address the needs of their constituents (citizens, clients). They are a mandate to achieve Outcomes by delivering Services. For example, ending homelessness. “For the citizens and clients of government, programs are abstract, whereas services are real. They represent the point of interaction between governments and their clients.” (Wiseman, 2015)
• Services deliver outputs to clients that contribute to program outcomes. For example, providing shelters for the homeless.
• The processes are activities that deliver services. For example, homeless person registration, bed allocation, etc.
• Resources are used in carrying out processes. For example, shelter space, beds, and personnel.
|Key Concepts and Classes=A Program defines a set of services that focus on a shared set of Outcomes. For example, a “poverty reduction program” can be made up of a set of Services such as mobiles services that provides food and clothing to those that live on the street, and a training service that provides basic skills for those living on the street. A Program has a set of Stakeholders that can contribute or benefit. The following are the Program properties:
• hasService: Identifies the Services that make up the Program.
• hasOutcome: Identifies the Outcomes that the program is trying to achieve.
• hasContributingStakeholder: Identifies the stakeholders that contribute to the Program.
• hasBeneficialStakeholder: Identifies the stakeholders that benefit from the Program.
• hasInput: Identifies the Inputs to the Program.
• hasOutput: Identifies the Outputs of the Program.
A Program is composed of one or more Services. As described in the Program description, a poverty reduction program can have many services with each service comprised of different activities, Inputs, Outputs and Outcomes. The following are the Service properties:
• activity:hasSubActivity: Identifies the Activities that make that comprise the Service.
• hasInput: Identifies the Inputs to the Service.
• hasOutput: Identifies the Outputs of the Service.
• hasOutcome: Identifies the Outcomes that are specific to the Service.
• hasContributingStakeholder: Identifies the stakeholders that contribute to the Service.
• hasBeneficialStakeholder: Identifies the stakeholders that benefit from the Service.
Outcome’s “are what stakeholders experience as a result of a city Programs and/or Services. They can be positive or negative, intended or unintended.” Outcome contains the following properties:
• hasBeneficialStakeholder: Identifies the Stakeholder affected.
• hasIndicator: Identifies the set of Indicators the organization assigns to the Outcome.
• schema:description: A general description of the Outcome as a string.
• fromPerspectiveOf: Identifies the Stakeholder who is determining the importance of the Impact.
• hasImportance: Specifies how important the Impact is (high, medium, low).
• intendedImpact: Identifies the intended direction of the change.
Stakeholder is a person or organization that either contributes to or benefits from a Program and/or Service. It has the following properties:
• schema:name (title): A title for the stakeholder as a string.
• schema:description: A general description of the stakeholder as a string.
• hasCatchmentArea: Specifies the regional span of the stakeholders.
• perform: Links to the activities performed by the stakeholder.
Input defines the resources and the stakeholders that contribute them that are input to an Activity:
• forActivity: The Program or Service or Activity this is an input for.
• hasContributingStakeholder: The Stakeholders that contribute the resources as input.
• hasResource: Specifies the input Resource.
• hasPlannedAmount: Specifies the amount of the input Resource
• hasActualAmount: Specifies actual amount of input Resource used.
• i72:for_time_interval: Specifies the time interval over which the input is used.
• sch:name: Name for the Input.
• sch:description: Description for the Input.
Output is a quantitative summary of an activity. For example, if the activity is ‘we provide training’ and the output is ‘we trained 50 people to NVQ level 3’. Or a production output could produce 100 meals for the homeless. Basic to these outputs is “what” has been produced and the quantity.
• forActivity: Identifies the Activity or Service that produces the Output.
• i72:value: Identifies that amount that is produced.
• hasResource: Identifies the Resource that is produced such as a skill, or a type of Meal.
• usedByIndicator: Identifies the Indicators that use this Output in determining the value of the Indicator.
|Classes=Program, Service, Outcome, Stakeholder, Input, Output
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=CityPattern.jpeg
|Caption=City Service Pattern
}}
}}

File:CityPattern.jpeg

2022-09-21T11:52:05Z

MarkFox:

Pattern:City Pattern

2022-09-21T11:48:08Z

MarkFox: Created page with "{{Pattern Definition |Description=The City Pattern combines basic information about the: • land area occupied by a city, • administrative areas of the city, e.g., distri..."

{{Pattern Definition
|Description=The City Pattern combines basic information about the:
• land area occupied by a city,
• administrative areas of the city, e.g., districts, wards, neighbourhoods, and
• government organization that runs a city.
• City’s Bylaws.
|Key Concepts and Classes=A City has the following properties:
• schema:legalName: The legal name of the city.
• hasLandArea: identifies the spatial areas occupied by the city.
• hasGovernment: identifies the GovernmentOrganization that manages the city.
• hasBylaw: identifies the bylaws in existence in the city.
• hasAdministrativeArea: identifies administrative areas within the city. They do not have to be distinct and can be hierarchical.

A CityAdministrativeArea is an area that has the authority and the power to make administrative or policy decisions. It can be specialized for use by a City to reflect its unique areas such as Districts, Wards, Neighbourhoods, Prefectures, etc. Its properties are similar to a City:
• hasName: The name of the area.
• hasLandArea: identifies the spatial areas occupied by the area.
• hasPopulationSize: number of people living in the area.
• hasGovernment: identifies the GovernmentOrganization that manages the area, if any.
hasBylaw: identifies the bylaws in existence in the area.
hasAdministrativeArea: identifies sub administrative areas with this administrative area.
• administrativeAreaOf: identifies administrative areas this administrative area.is part of.
|Classes=City, CityDivision
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Extended Organization Pattern

2022-09-21T11:46:32Z

MarkFox: Created page with "{{Pattern Definition |Description=Organizations provide another source of influence on the behaviour in the urban system. An organization is defined broadly as a formal or sem..."

{{Pattern Definition
|Description=Organizations provide another source of influence on the behaviour in the urban system. An organization is defined broadly as a formal or semi-formal groups for which structure and behaviour are defined. Organizations such as schools and businesses are particularly important for cities as they determine regular travel patterns and other activities for much of the population.
The Organization Pattern is drawn from the TOVE model of an Organization, originally presented in [7]. In particular, definitions of the concepts of Organization, Organization Agent, Role, and Goal are adopted here. In addition, the Organization Pattern introduces the concepts of Students and Employees who are members of certain types of Organizations. Using the Spatial Location Pattern, the Organization Pattern captures the location of a person's work or school. The Change Pattern is used to support the representation of variable attributes of an organization, such as its location and members.
|Key Concepts and Classes=The Organization class extends org_s:Organization to include city specific properties.
• Organization: A company or other sort of formal or informal group of individuals in the urban system with some identified structure and behaviour.
o An Organization may own Property, including different types of Buildings.
o An Organization may have an address.
o An Organization has at least 2 members.
o An Organization has some Goal(s); this represents some state or complex states, and allows for the representation of various groups' responsibilities.
o An Organization may be divided into sub-organizations which are themselves Organizations.
• Organization Agent: Members of an organization.
o Organization Agents have goals, authority, and may be members of some team.
o An Organization Agent plays a Role within the Organization.
• Role: A Role has a single (possibly complex) Goal.
A Role has some authority, requires some skill, and may also have some associated processes.
• Firm: A Firm is a type of organization.
o A Firm has an address and an industry type, and some Employees.
o A Firm may have a Business Establishment(s).
• Business Establishment: A Business establishment is a physical location where a Firm conducts business.
o A Business Establishment has a Location and may have an address.
• Employee: A Firm has some Employees, whom it employs for some Occupation.
o An Employee is a type of Organization Agent.
o An Employee may be employed at a particular Business Establishment.
o An Employee may be responsible for one or more Roles within the Organization.
o An Employee is employed by some Organization, unless the Person is self-employed.
o An Employee has a Wage/Salary and may work at some Location (this may be the location of the Firm, an alternate Location, or a Location that is subject to change).
o An employee has some employment status. An employment status may be categorized as one of: full-time regular, part-time regular, full-time-work-at-home, part-time-work-at-home
• Occupation: An occupation describes the type of work performed by some employee. Different classes of occupations may be defined, such as: General Office / Clerical, Manufacturing / Construction / Trades, Professional / Management / Technical, Retail Sales and Service
OperatingHours class specifies the operating hours of an organization. It uses the Recurring Event Pattern (defined in ISO/IEC 5087-1) to introduce a more specific definition of hours of operation as a specialization of a RecurringEvent.
o dayofWeek: specifies the day of the week for this instance of OperatingHours.
o hasOpeningTime: specifies the opening time for this instance of OperatingHours.
o hasClosingTime: specifies the closing time for this instance of OperatingHours.
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:City Resident Pattern

2022-09-21T11:43:33Z

MarkFox: Created page with "{{Pattern Definition |Description=As different cities have different definitions of who is that city’s Resident, the City Resident Pattern can contain the properties require..."

{{Pattern Definition
|Description=As different cities have different definitions of who is that city’s Resident, the City Resident Pattern can contain the properties required by each. Central to all the definitions is the concept of residing. Variously referred to as a home or domicile in which the resident spends significant amounts of time; they can own it, rent it or just stay in it. Legally, “reside means to dwell permanently or continuously. It expresses an idea that a person keeps or returns to a particular dwelling place as his fixed, settled, or legal abode. The meaning of reside implies a continuous arrangement” ; reside has both a temporal and spatial dimension. The city of Toronto’s definition of a city resident includes the concept of owning property or owning or operating a business in the city. For Beijing, nationality is a unique aspect.
|Key Concepts and Classes=The CityResident class is a subclass of Person. The properties of the CityResident class are used to construct the definition of a resident for a particular city. These properties are:
• a residence property hasResidence that specifies one or more individuals of Residence, where each individual specifies a residence distinguished by city, address and/or time interval. A resident can have more than one residence;
• a citizenship property citizenOf that specifies one or more Citizenship’s, each specifying the country (Country) and time interval (time:ProperInterval) the resident is a citizen. A person can be a citizen of more than country and for different time intervals;
• an ownership property “owns”, that specifies zero or more ControlledEntity’s where entity’s are buildings (Building) and/or land areas (LandArea) that the resident owns; and
• a business operate property “operates”, that specifies zero or more ControlledEntity where the entity is an Organization that the resident operates.
The ControlledEntity and Citizenship classes are necessary to capture the time interval during which an entity is owned or operated, or the person is a citizen of a country.
In the following definition of CityResident, the properties identified fall into two types:
• Properties that are required in all specializations of Resident, e.g., Toronto Resident, Beijing Resident, and
• Properties that are optional, but if used by a specialization of Resident, have their ranges restricted.
A major part of determining whether a person is a resident of a city is the specification of where and when they have resided. The hasResidence property is required and links a CityResident to a Residence. The cardinality of the property is greater than one as over time a person may reside in more than one place/address, in the same city and/or different cities.
The Residence class identifies the following optional properties that can be used by specializations of the class:
• a location property forCity whose range is a single city (City),
• a time interval property time:hasTime whose range is a single time interval,
• the home type property hasHomeType whose range is a single type of home, such house, apartment, etc.,
• an address property hasAddress whose range is a single address, and
• a property hasResidentialRelationship whose range specifies whether the resident rents, owns, etc. the home.
The temporal intervals of individuals of Residence can used to determine a total or partial ordering of a person’s residencies, as a person may reside in more than one place at the same time.
All specializations (subclasses) of Resident shall have at least one hasResidence property that identifies where they reside. The remaining properties are optional and their specifications are intended to constrain their use in the context of specializations of Resident. For example, if an optional property is used in the definition of Toronto Resident, then its range is restricted to what is specified in Resident.
|Classes=CityResident, Residence, ControlledEntity, Citizenship
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Land Use Pattern

2022-09-21T11:40:57Z

MarkFox: Created page with "{{Pattern Definition |Description=The Land Use Pattern provides the necessary concepts to describe a particular classification(s) applied to some area of land. It introduces t..."

{{Pattern Definition
|Description=The Land Use Pattern provides the necessary concepts to describe a particular classification(s) applied to some area of land. It introduces the generic concept of a LandUseClassification which may be extended to capture specific classification systems as required. It can be extended with classifications from Land-Based Classification Standards (LBCS), Canada Land Use Monitoring Plan (CLUMP), and Agriculture and Agri-Food Canada (AAFC). A goal of future work will be to define the classifications in greater detail such that any relationships between classifications in different systems can be inferred. The Land Use Pattern imports the Spatial Location Pattern (defined in ISO/IEC 5087-1); in particular, Land Areas have some location (a Feature) which may be described as a geometry, they may also be related to other Land Areas (or arbitrary spatial Features) by the spatial relations such as containment, contact, overlaps, and so on.
|Key Concepts and Classes=A Land Area is a way of defining some area in an urban system.
• A Land Area has a Location at a given point in time
• A Land Area may be classified as having some Land Use Classification.
• There may be other types (subclasses) of Land Area, defined in more precise or different ways, such as a Zone.
• A Land Area may have some Area. This is currently a variant property and we have yet to determine whether this is equivalent to the area of the Geometry of the Land Area location (e.g. there may be various values with different accuracy from different sources).
• A Land Area may have some population that is subject to change over time.
• A Land Area may have a number of employed residents that is subject to change over time.
Land Use Classifications provide a means of describing the land cover/use in a standard way. Various classification systems are used to identify types of land use. See Annex C for examples of how the pattern may be extended with specific classification systems.
|Classes=LandArea
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Building Pattern

2022-09-21T11:39:10Z

MarkFox: Created page with "{{Pattern Definition |Description=The Building pattern defines the concepts to capture information about individual buildings, thus describing land use from a different perspe..."

{{Pattern Definition
|Description=The Building pattern defines the concepts to capture information about individual buildings, thus describing land use from a different perspective and at a finer level of granularity than typical land use classifications. The Infrastructure Pattern is reused here, as Buildings and Building Units are defined as types of (subclasses) Infrastructure Elements. The Building pattern also reuses the Spatial Location pattern in order to capture the location of a building. While we expect the address of a building to remain constant its exact location can change over time, as in the case of a remodeling or extension. The possibility is supported by the Building pattern, which also reuses the Change pattern and captures the location as a variant property. Other attributes of a building are also captured, such as the type of building, units contained in a building, their monetary value, and so on. The Mereology pattern is used to capture the disaggregate parts of a building, and the Units of Measure pattern is required to capture attributes required for land value considerations, such as sale prices and square footage.
|Key Concepts and Classes=A Building is a structure with some location in the urban system. The location of the Building in space may change (e.g. due to construction). – this may be described in terms of both actual (e.g. 2D and 3D space) location occupied by the building and associated locations (e.g. a point coordinate). There are different types (subclasses) of buildings, such as House, Apartment Building, Office Building, and so on. A Building has a market value.
A Building contains one or many units. A Building has some height, some footprint area, and some floor area. The floor area is often greater than the footprint area as it accounts for the area of each floor of the building. However, floor area excludes unoccupied areas such as basements.
A BuildingUnit has a size (square footage, number of rooms). A Building or BuildingUnit may contain some Facility(s), e.g. kitchen, bath, or air conditioning. Note that this is distinct from the notion of including amenities that are not a physical part of the Building (or BuildingUnit), but which may be part of the Tenure. A BuildingUnit has an address. A BuildingUnit has a value and may have some rental fee.
Different types (subclasses) of Building may be defined as required. It is recommended to avoid confusing type of building structure with building use. For example, a “Detached House” is a type of building whereas an “Office” is not. A Building also requires some degree of permanence; a “Duplex” or a “Garage” may be defined as types of buildings, whereas a tent may not. Also note that a Building refers only to the structure, not the surrounding area; an airport terminal is a building, an aircraft hangar is a building, but the entire airport complex is not.
A Building (or class of buildings) may be described as having some associated use and/or function. The values of a building’s use or function properties may be populated according to one or more existing classification systems. In this way it is also possible to extend the pattern with various subclasses of Building, as required for a given application.
|Classes=Building, BuildingUnit, Facility
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Transportation Infrastructure Pattern

2022-09-21T11:38:05Z

MarkFox: Created page with "{{Pattern Definition |Description=The Transportation Infrastructure pattern defines the concepts that are relevant in describing the physical transportation infrastructure and..."

{{Pattern Definition
|Description=The Transportation Infrastructure pattern defines the concepts that are relevant in describing the physical transportation infrastructure and their characteristics. This includes the concepts of a Road, Bridge, and Tunnel. The Infrastructure Pattern is reused here, as these transportation structures are all defined as types of (subclasses) Infrastructure Elements.
|Key Concepts and Classes=A Road is a type of Infrastructure Element. It describes a part of the physical transportation infrastructure that has been improved in order to allow travel by motor vehicles, persons, bicycles and similar methods of conveyance. Road is identified as such by some governing body. It has some location and name. It may be decomposed into parts as Road Segments. A Road Segment is another type of Infrastructure Element, it is part of a Road and has some location.
A Rail Line is a type of Infrastructure Element. It describes a part of the physical transportation infrastructure that has been fitted with tracks in order to allow travel by trains and other sorts of rail vehicles. No distinction is made between types of rail at this level. A Rail Line is identified as such by some governing body. It has some location and name. It may be decomposed into parts as Rail Line Segments. A Rail Line Segment is another type of Infrastructure Element, it is part of a Road and has some location.
A Bridge is a type of Infrastructure Element. It describes a part of the physical transportation infrastructure that enables travel over some area. It has some location and name, and may contain some Road or Rail Line Segments. It may be decomposed into parts as Bridge Segments. A Bridge Segment is another type of Infrastructure Element, it is part of a Road and has some location.
A Tunnel is a type of Infrastructure Element. It describes a part of the physical transportation infrastructure that enables travel underneath some area. It has some location and name, and may contain some Road or Rail Line segments. It may be decomposed into parts as Tunnel Segments. A Tunnel Segment is another type of Infrastructure Element, it is part of a Road and has some location.
|Classes=Road, RoadSegment, RailLine, RailLineSegment, Bridge, BridgeSegment, Tunnel, TunnelSegment
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Infrastructure Pattern

2022-09-21T11:36:35Z

MarkFox: Created page with "{{Pattern Definition |Description=The Infrastructure pattern defines the concepts needed to capture various types of city infrastructure, such as buildings and roads. The Infr..."

{{Pattern Definition
|Description=The Infrastructure pattern defines the concepts needed to capture various types of city infrastructure, such as buildings and roads. The Infrastructure pattern reuses the Spatial Location pattern (from ISO/IEC 5087-1) in order to capture the location of these infrastructure elements.
It is extended by the Building pattern, and the Transportation Infrastructure pattern. It can be extended with other types of infrastructure as required.
|Key Concepts and Classes=An Infrastructure Element is a generic representation of a city structure of interest. All infrastructure elements may have some defined location and shall be associated with some location, where locations are spatial Features as defined in ISO/IEC 5087-1. The Mereology pattern (from ISO/IEC 5087-1) is also reused in order to support the possible representation of infrastructure parts (e.g. road segments) and their associated wholes (e.g. the entire road). The following are its properties:
• spatialloc:hasLocation: specifies the location of the element as a geo:Feature.
• mereology:hasProperPart: specifies any sub-parts of the element.
• genprop:hasIdentifier: specifies identifiers for the element provided by the city.
• genprop:hasName: specifies names of the element.
• genprop:hasDescription: specifies descriptions of the element.
• activity:hasStatus: specifies the status of the infrastructure element. Note that instances of InfrastructureStatus are not defined in this document.
|Classes=InfrastructureElement
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Provenance Pattern

2022-08-24T12:58:22Z

MarkFox: Created page with "{{Pattern Definition |Description=The concept of provenance is important for many applications in the smart city domain. It is often important to represent the origin of a par..."

{{Pattern Definition
|Description=The concept of provenance is important for many applications in the smart city domain. It is often important to represent the origin of a particular record, document, or other object. To do this in a consistent way requires a mechanism to represent the provenance of objects. The ontology for representing provenance shall conform to the ontology specified in the W3C Recommendation “PROV-O: The PROV Ontology”.
|Key Concepts and Classes=The core classes of Agent and Activity in PROV-O are extended with specialized classes that are related to the Agent and Activity patterns defined in this standard.
— Entity: An Entity is a generic concept that may represent a physical, digital, or abstract kind of thing. For example, a data record or a physical piece of equipment may both be considered Entities. An Entity has the following core properties:
wasDerivedFrom: the wasDerivedFrom property indicates that the Entity was derived from some other Entity. This may occur in cases of revisions (e.g. of documents), or in cases where one entity is used in the creation of another. For example, the results of some predictive model may be derived from some dataset).
wasAttributedTo: the wasAttributedTo property identifies the Agent(s) that is in some way responsible for the creation of the Entity.
wasGeneratedBy: the wasGeneratedBy property identifies the Activity(s) that produced or otherwise resulted in the existence of the Entity.
— Activity: An Activity is something that acts on Entities (such as consuming or transforming them). An Activity has the following core properties:
used: the used property identifies an Entity(s) that was used by a particular Activity. For example, if some set of data was generated by the activity of running a predictive simulation model, then the input dataset(s) would be identified as used by the simulation model prediction activity.
wasAssociatedWith: the wasAssociatedWith property identifies an Agent(s) that is in some way responsible for the activity taking place.
— Agent: An Agent is a generic concept that may represent a person, software system, organization, or any other object that may be responsible for the occurrence of an activity.
|Classes=Agent, Activity, Entity
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Agreement Pattern

2022-08-24T12:56:54Z

MarkFox: Created page with "{{Pattern Definition |Description=An agreement exists between two or more agents. It is established at some point in time and it may be considered valid only in some Location..."

{{Pattern Definition
|Description=An agreement exists between two or more agents. It is established at some point in time and it may be considered valid only in some Location and/or for some interval in time. An agreement may be defined at varying levels of detail, this is supported with the introduction of the ComplexAgreement and AtomicAgreement class. A complex agreement may be decomposed into sub-agreements, whereas an atomic agreement cannot. Similar to the approach taken for the representation of activities, a complex agreement may be decomposed into disjunctive or conjunctive sub-agreements. This allows for the representation of both types of agreement composition. At their simplest level, the AtomicAgreement describes a commitment to some activity; this is captured with the commitsToActivity property. Finally, agreements involve some specification of rights or commitments of the involved parties. This is represented as a relationship between the involved Agent and a particular activity. The precise nature of the relationship indicates the type of agreement. The possible relationships are defined according to the elements of the so-called primary rules[20] of the Hohfeldian analytical system[21], (and their opposites): claim and privilege.
|Key Concepts and Classes=— involvesAgent: identifies the Agents that are party to the Agreement.
— validIn: identifies the location where the agreement is valid.
— establishedOn: specifies the Instant of time at which the Agreement was created.
— validFor: specifies the time Interval during which the Agreement is in force.
ComplexAgreement is a subclass of Agreement and has one additional property:
— hasSubAgreement: identifies two or more Agreements that comprise the Agreement.
Elements of the Hohfeldian analytical system are used to define the following subproperties of the inverse of involvesAgent (agentInvolvedIn) in order to represent the nature of the agreement between two (or more) agents in greater detail:
— hasClaim: the hasClaim property indicates that an Agent is the beneficiary of an Activity fulfilled by another Agent in the Agreement (i.e., the Agent with the duty to fulfil the Activity), e.g. payment of wages, provision of services.
— hasNoClaim: the hasNoClaim property indicates that an Agent has no claim on (i.e. has no right to) the described Activity. For example, under certain circumstances an Agent may have no claim to a service provided by another Agent (e.g. a person under the legal drinking age has no claim to any services provided by a bar).
— hasPrivilege: the hasPrivilege property indicates that an Agent is not required to fulfil the described Activity. For example, if gratuities are left to an person’s discretion then they have the right (privilege) not to include a tip in their payment.
— hasDuty: the hasDuty property indicates that an Agent is required to fulfil the described Activity. Contrary to the example above, if gratuities are mandatory, then the person is required (has a duty) to include the tip in their payment.
The relationship between these properties in a given Agreement can be summarized by the following opposites and correlatives, as originally identified by Hohfeld[21]:
— If agent A hasClaim, then A lacks a hasNoClaim
— If agent A hasPrivilege, then A lacks a hasDuty
— If agent A hasClaim, then some agent B hasDuty
— If agent A hasPrivilege, then some agent B hasNoClaim
AtomicAgreement is a subclass of Agreement. It has no decomposition and specifies the “essence” of an agreement. In particular, it identifies how Agents participating in the Agreement are involved:
— forActivity: identifies the Activity the AtomicAgreement is for.
— inverse hasClaim: links the Agreement to any Agent that has a claim.
— inverse hasNoClaim: links the Agreement to any Agent that does not have a claim.
— inverse hasDuty: links the Agreement to any Agent that has a duty to perform the Activity.
— inverse hasPrivilege: links the Agreement to any Agent that has the privilege to perform the Activity.
|Classes=Agreement, ComplexAgreement, AtomicAgreement
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=Agreement-Pattern.jpeg
|Caption=Agreement Pattern Example
}}
}}

File:Agreement-Pattern.jpeg

2022-08-24T12:56:50Z

MarkFox:

Pattern:Mereology Pattern

2022-08-24T12:54:10Z

MarkFox: Created page with "{{Pattern Definition |Description=Notions of parthood are ubiquitous. While sometimes conflated, there are clear distinctions which can be made between different types of part..."

{{Pattern Definition
|Description=Notions of parthood are ubiquitous. While sometimes conflated, there are clear distinctions which can be made between different types of parthood. The mereology pattern focuses on identifying these differences and making them explicit. The distinction between types of parthood may be best explained with the use of examples. An item may be contained in a car, but that does not make it a component of a car. For example, there may be a need to describe passengers or cargo being contained in a vehicle, but this relation needs to be distinguished from the parts and components that make up a vehicle. Similarly, the front of a car is intuitively a part of the car, but not a component of the car. While components of a vehicle may be defined, different city zone systems (wards, postal codes) are not components, but proper parts of larger areas.
|Key Concepts and Classes=They key properties are formalized in Table 16. The Mereology pattern identifies the following different types of parthood: proper-part-of, component-of, and contained-in. A more detailed analysis, presented in Reference [19] reveals clear, ontological distinctions between each of these relations that may formalized clearly with a set of first-order logic axioms. The different properties may be described as follows:
— partOf: specifies a part-whole relationship between objects
— properPartOf: specifies a part-whole relationship between objects where an object cannot be part of itself
— componentOf: specifies a part-whole relationship between objects where the part is defined based on actual boundaries. The parts are often also defined according to distinct functions. For example, a trunk is a componentOf a car.
— immediateComponentOf: specifies a componentOf relationship where the if x immediateComponentOf y, then there does not exist a z where x immediateComponentOf z immediateComponentOf y.
— containedIn: specifies a relationship between objects where one is not part (i.e. it is physically distinct) but instead is physically enclosed by the other (partially or wholly). For example, a suitcase is containedIn the trunk of a car.
— immediateContainedIn: specifies a containedIn relationship where the if x immediateContainedIn y, then there does not exist a z where x immediateContainedIn z immediateContainedIn y.
The aforementioned analysis (presented in Reference [19]) also identifies the expressive limitations of OWL, which prevent a complete representation of this semantics, and discussed the various possible approximations. It is important to consider what should be captured, and what distinctions should be made in the introduction of properties, in contrast with what is actually expressible in the logic. Since the required semantics cannot be completely captured in OWL, some trade-off(s) is required for any partial specification, (e.g. OWL only allows the specification of transitivity for simple object properties).
The difficulty with such an approximation is that the resulting theory defines a semantics for something else entirely. Inherently, some semantics are omitted, which can potentially not be required for one application but can potentially be important for another. For example, if transitivity is a key aspect of some required reasoning, then perhaps a parthood relation would be defined as transitive, and some omissions would be made with respect to the formalization of other restrictions (e.g. cardinality) that should be applied to the parthood relation. Certainly, the use of approximations will be required in some cases, for example in order to support some desired reasoning problems. However, precisely which axiomatization is most suitable will vary between different usage scenarios. The Mereology Pattern therefore omits a detailed, partial axiomatization in favour of an under-axiomatized specification of the key relations, in order to avoid prescribing one trade-off over another. This leaves the commitment open-ended and variable to suit individual applications’ needs.
This ontology defines the general properties such that the commonality between domain-specific part-of relations may be captured, and more detailed semantics may be defined in extensions of the properties. This creates a means of indicating the intended semantics of a relation by identifying the type of parthood that it is intended to capture, while allowing for the specification of different partial approximations of the semantics (and possibly also specializations of this semantics), as required. For example, a notion of parthood arises in the description of a building and the units it is divided into. In this case, this relationship can be identified as a sort of hasComponent relation; a new property hasBuildingUnit can be identified then as a subPropertyOf hasComponent. The most suitable approximation of the component-of relation can then be defined for the hasBuildingUnit relation. The approximation chosen for one type of parthood relation does not constrain the choice of approximation for another.
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=Mereology Pattern.jpeg
|Caption=Mereology Pattern Example
}}
}}

File:Mereology Pattern.jpeg

2022-08-24T12:53:59Z

MarkFox:

Pattern:Resource Pattern

2022-08-24T12:51:52Z

MarkFox: Created page with "{{Pattern Definition |Description=Resources are an important aspect of activities; they often capture important preconditions and effects of activities. In the context of city..."

{{Pattern Definition
|Description=Resources are an important aspect of activities; they often capture important preconditions and effects of activities. In the context of city data, resources such as vehicles, income, and transit passes will impact travel behaviour. The representation of resources is also important for tasks related to asset management; for example, city infrastructure and its scheduled maintenance activities and failure rates are important factors for predicting the performance of various city services.
The Resource Pattern adopts the view presented in the TOronto Virtual Enterprise model[18] that whether or not an object is considered a resource is dependent on the role that it plays for a particular activity. In this sense, Resources are a class of Manifestations, as they are subject to change over time. For example, the value of the hasAvailableCapacity property, described in clause 6.10.2, changes over time as the resource is used/consumed. Each change can be represented with a different manifestation with a change in both the available capacity and the time interval over which it is valid.
An object may be classified as a different type of resource, dependent on its participation in an activity. The Resource Pattern reuses the Activity Pattern.
|Key Concepts and Classes=— Asset: The notion of an Asset is relevant as a more general type of Resource - anything that may be managed by a given organization. An Asset is a type of Manifestation as it may undergo changes over time. Assets have the following core property:
hasLocation: identifies the spatial Feature (as defined the in the Spatial Location Pattern) where the asset is located. The location of an Asset is a variant property.
— Resource: A Resource is a type of Asset that plays a role in some Activity. Various types (subclasses) of Resource may be defined as required. A Resource class may be used by or consumed by some Activity class; the specification of what Resource and the quantity used or consumed in an activity is defined by the UseState and/or ConsumeState that are part of a State definition that is linked to an Activity by an enablesActivity property. If some Resource is used by an Activity, then when the Activity occurs, there needs to be some Resource of that type that is (partially) not available. If a Resource is consumed by an Activity, then the Resource (partially) ceases to exist by the end of the occurrence. Resources have the following core properties:
hasCapacity: identifies the Quantity that specifies how much of the Resource exists, e.g. its volume, if it is liquid; how much it can hold, if it is an oven. This property may be invariant, depending on the nature of the resource.
hasAvailableCapacity: identifies the Quantity that specifies how much of the Resource is available for use at some point in time (i.e. when the particular manifestation exists).
capacityInUse: identifies the portion of capacity in use, by some Activity(s), at the time of the manifestation.
hasAllocation: specifies an Allocation for the Resource. This indicates a State and time Interval to which the Resource has been allocated.
participatesIn: identifies the Activity that the Resource is being used or consumed by.
For additional detail, a Resource may be classified according to more specific resource types. A Resource may either be a DivisibleResource or a NonDivisibleResource, but not both.
— DivisibleResource: may be divided for use or consumption between multiple Activities at any point in time.
— NonDivisibleResource: may only be used for a single Activity at once – even if it isn’t fully utilized.
— Allocation: An Allocation class specifies the planned assignment of a Resource to an Activity via a State. An Allocation is a Manifestation as itchange over time. It has the following properties:
forResource: specifies the Resource that is being allocated.
forState: specifies the State to which the Resource is allocated.
hasQuantity: the amount of the Resource allocated.
hasTime: specifies the time Interval at which the Resource is Allocated to the State.
— TerminalResourceState: The Resource pattern extends TerminalState (defined in the Activity pattern), specialized as TerminalResourceState with the following properties:
hasQuantity: specifies the Quantity (as defined in the City Units pattern) of the Resource that participates in the State, if applicable.
hasResource: specifies a Resource that participates in the State. This identifies the condition of the object that plays a resource role (i.e. is used, consumed, etc.) when the state’s status is active.
hasAllocation: specifies one or more Allocations that identify a Resource and what time it is allocated to the State.
Specializations of TerminalResourceStates are identified in order to distinguish the role of Resources as preconditions and effects more precisely:
— ConsumeState: Identifies a Resource and Quantity it consumes. The Quantity is removed from the Resource.
— ProduceState: Identifies a Resource and Quantity it produces.
— UseState: Identifies a Resource and Quantity it uses (without consuming).
— ReleaseState: Identifies a Resource and Quantity it releases (after using).
|Classes=Asset, Resource, DivisibleResource, NonDivisibleResource, Allocation, TerminalResourceState, ConsumeState, ProduceState, UseState, ReleaseState
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Recurring Event Pattern

2022-08-24T12:47:07Z

MarkFox:

{{Pattern Definition
|Description=A specification of recurring events, in particular those that are defined according to calendar dates (e.g. every Monday, every March), is required in order to capture information regarding hours of operation, road restrictions, restrictions on parking policies, and so on. A recurring event is a means of describing scenarios where some activity is scheduled to recur at some regular interval. It is important to note that recurring events such as scheduled transit trips and operating hours represent planned or usual occurrences. But exceptions to the planned recurrence can exist. For example, while a business can be open at some recurring intervals, it is possible that in the case of some exceptional circumstances (for example, a power failure) they are not open during the predefined days and times.
The recurring event pattern is a specification of the scheduled recurrence of an activity. The actual performance of the activity can be captured as an instance of an activity that is a subclass of manifestation. Hence, changes to the properties of the specific activity, as it is performed, can be captured as manifestations. For example, a store operation could have a data property representing total sales for the day, whose value increases throughout the day. Each change in value could be captured as a manifestation of the activity.
|Key Concepts and Classes=The key classes are formalized in Table 13. The Recurring Event Pattern adopts the following representation of recurring events: daily, weekly, and monthly recurring events (and their related properties) are defined, however the ontology may be extended with similar definitions of other type of recurring events, as required.
Note that despite the close relationship, a recurring event is distinct from an activity. An instance of a recurring event corresponds to a class of activities (e.g. all of the occurrences of a Tuesday, all of the occurrences of the weekly waste pickup), but it is not itself an activity. The intuition is that the occurrences of a recurring event are all the same type of activity. What defines a recurring event is a combination of the activity type (e.g. a transit trip from point A to point B or the provision of a service) and the frequency at which it recurs.
The pattern captures the associated activity type with the hasActivity property that relates recurring events to activities. Classes of recurring events may be captured by identifying their associated classes of Activities, while individual recurring events may be associated with one or more instances of an activity.
The Recurring Event pattern uses the Activity pattern, as the concept of an activity is central to the notion of a recurring event: the activities are the recurrences. It is important to note that while the concept of Activity defined in the Activity pattern is necessary for the definition of a RecurringEvent, it is not the case that the concept of RecurringEvents is required for the definition of an Activity. This allows for a simpler representation of events in cases where the notion of recurrence not be required.
Recurring events are also identified based on the regular interval at which they occur; this is captured using some combination of the hasTime, dayOfWeek, hasMonth, and dayOfMonth properties. Using these properties, the pattern supports definitions of specializations of the RecurringEvent class. In particular, subclasses for daily, weekly, monthly, and yearly recurring events are defined; other classes of recurring events may be defined similarly, as required. In addition, the properties startState and endState are used to identify fuzzy recurring events that occur due to certain circumstances, i.e., States, rather than at specific points in time.
Exceptions to recurring events may also be defined. For example, a business may normally operate on Monday-Friday, except for public holidays. Exceptions may also be defined on specific dates (e.g. June 23, 2018), for example due to construction or on special calendar days (e.g. holidays) with the ExceptionDay class. If applicable, exceptions may be defined for recurring events with the recursExcept property. Conversely, so-called exceptions may involve an additional, unusual occurrences. This is captured with the recursAddition property.
A RecurringEvent is defined to have the following properties:
— hasActivity: identifies the Activities that take place at the time and location.
— associatedLocation: identifies the locations (Features) where the event occurs.
— hasSubRecurringEvent: identifies the sub-recurring events that comprise the RecurringEvent. As with an Activity, a RecurringEvent may be decomposed/decomposed into simpler/more complex RecurringEvents to support varying levels of granularity.
— startTime: specifies the start time of the RecurringEvent's activity using xsd:time format.
— endTime: specifies the end time of the RecurringEvent’s activity using xsd:time format.
— schema:dayOfWeek: specifies the day of the week on which a Weekly RecurringEvent occurs.
— hasMonth: specifies the month on which which a YearlyRecurringEvent occurs.
— dayOfMonth: specifies the day of the month on which a MonthlyRecurringEvent occurs.
— beginsRecurringTime: defines a time to initiate the RecurringEvent.
— endsRecurringTime: defines a time to terminate the RecurringEvent .
— beginsRecurringState: defines a State that is required to be true in order to initiate the RecurringEvent.
— endsRecurringState: defines a State that is required to be true in order terminate the RecurringEvent.
— recursExcept: defines the exceptions for the RecurringEvent, i.e. conditions when it does not occur. This can specify a time, day of the week, or specific dates.
— recursAddition: defines a condition when the RecurringEvent should be added to. This can specify a time, day of the week, or specific dates.
An ExceptionDay specifies a day or days that recursExcept and recursAddition use to specify unique days that do not recur on the same day each year, for example, holidays. It has the following properties:
— hasName: the name of the exception day, e.g. Labour Day.
— time:hasTIme: specifies the year/month/day on which the exception occurs.
A DailyRecurringEvent occurs every day. It has a maximum of one associated time, the start time. Typically, a daily recurring event will occur at the same time every day, but there is potentially no commitment to a recurring start time for the event, in which case no start time is specified. A DailyEvent does not necessarily have a recurring end time (this would require a constant duration), therefore this is not part of the definition (although it is possible to specify).
A WeeklyRecurringEvent recurs regularly on the same day of the week, as specified by the schema:dayOfWeek property.
A MonthlyRecurringEvent recurs regularly on the same day of each month, as specified by the dayOfMonth data property. Note that there is often ambiguity regarding the semantics of a monthly recurring event: in this formalization, a MonthlyRecurringEvent is any event that recurs regularly on the same day of each month; other interpretations sometimes consider events that recur on the same day of week, or first or last day, in which case the day of month will vary. Such a representation is not included in this ontology, but could be captured in an extension.
A YearlyRecurringEvent recurs regularly on the same day of the same month, as specified by the hasMonth and dayOfMonth properties. As with MonthlyRecurringEvent, there can be ambiguity regarding the semantics of a yearly recurring event. However, this formalization captures only the notion of an event that recurs on the same day of the same month (e.g. a birthday).
Figures 12 and 13 illustrate how the Recurring Event Pattern could be used to define the concept of a scheduled bus trip. In this example, the scheduled bus trip “sched_bus_trip” recurs daily at 8:00 am so all occurrences of the event (i.e. activities “bustrip1_123”, “bustrip1_321”) should occur at 8:00 am on their respective dates.
|Classes=DailyRecurringEvent, ExceptionDay, MonthlyRecurringEvent, RecurringEvent, WeeklyRecurringEvent, YearlyRecurringEvent
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=RecurrentEvent-Pattern.jpg
|Caption=Recurring Event Pattern Example
}}
}}

File:RecurrentEvent-Pattern.jpg

2022-08-24T12:46:49Z

MarkFox:

Pattern:Recurring Event Pattern

2022-08-24T12:44:47Z

MarkFox: Created page with "{{Pattern Definition |Description=A specification of recurring events, in particular those that are defined according to calendar dates (e.g. every Monday, every March), is re..."

{{Pattern Definition
|Description=A specification of recurring events, in particular those that are defined according to calendar dates (e.g. every Monday, every March), is required in order to capture information regarding hours of operation, road restrictions, restrictions on parking policies, and so on. A recurring event is a means of describing scenarios where some activity is scheduled to recur at some regular interval. It is important to note that recurring events such as scheduled transit trips and operating hours represent planned or usual occurrences. But exceptions to the planned recurrence can exist. For example, while a business can be open at some recurring intervals, it is possible that in the case of some exceptional circumstances (for example, a power failure) they are not open during the predefined days and times.
The recurring event pattern is a specification of the scheduled recurrence of an activity. The actual performance of the activity can be captured as an instance of an activity that is a subclass of manifestation. Hence, changes to the properties of the specific activity, as it is performed, can be captured as manifestations. For example, a store operation could have a data property representing total sales for the day, whose value increases throughout the day. Each change in value could be captured as a manifestation of the activity.
|Key Concepts and Classes=The key classes are formalized in Table 13. The Recurring Event Pattern adopts the following representation of recurring events: daily, weekly, and monthly recurring events (and their related properties) are defined, however the ontology may be extended with similar definitions of other type of recurring events, as required.
Note that despite the close relationship, a recurring event is distinct from an activity. An instance of a recurring event corresponds to a class of activities (e.g. all of the occurrences of a Tuesday, all of the occurrences of the weekly waste pickup), but it is not itself an activity. The intuition is that the occurrences of a recurring event are all the same type of activity. What defines a recurring event is a combination of the activity type (e.g. a transit trip from point A to point B or the provision of a service) and the frequency at which it recurs.
The pattern captures the associated activity type with the hasActivity property that relates recurring events to activities. Classes of recurring events may be captured by identifying their associated classes of Activities, while individual recurring events may be associated with one or more instances of an activity.
The Recurring Event pattern uses the Activity pattern, as the concept of an activity is central to the notion of a recurring event: the activities are the recurrences. It is important to note that while the concept of Activity defined in the Activity pattern is necessary for the definition of a RecurringEvent, it is not the case that the concept of RecurringEvents is required for the definition of an Activity. This allows for a simpler representation of events in cases where the notion of recurrence not be required.
Recurring events are also identified based on the regular interval at which they occur; this is captured using some combination of the hasTime, dayOfWeek, hasMonth, and dayOfMonth properties. Using these properties, the pattern supports definitions of specializations of the RecurringEvent class. In particular, subclasses for daily, weekly, monthly, and yearly recurring events are defined; other classes of recurring events may be defined similarly, as required. In addition, the properties startState and endState are used to identify fuzzy recurring events that occur due to certain circumstances, i.e., States, rather than at specific points in time.
Exceptions to recurring events may also be defined. For example, a business may normally operate on Monday-Friday, except for public holidays. Exceptions may also be defined on specific dates (e.g. June 23, 2018), for example due to construction or on special calendar days (e.g. holidays) with the ExceptionDay class. If applicable, exceptions may be defined for recurring events with the recursExcept property. Conversely, so-called exceptions may involve an additional, unusual occurrences. This is captured with the recursAddition property.
A RecurringEvent is defined to have the following properties:
— hasActivity: identifies the Activities that take place at the time and location.
— associatedLocation: identifies the locations (Features) where the event occurs.
— hasSubRecurringEvent: identifies the sub-recurring events that comprise the RecurringEvent. As with an Activity, a RecurringEvent may be decomposed/decomposed into simpler/more complex RecurringEvents to support varying levels of granularity.
— startTime: specifies the start time of the RecurringEvent's activity using xsd:time format.
— endTime: specifies the end time of the RecurringEvent’s activity using xsd:time format.
— schema:dayOfWeek: specifies the day of the week on which a Weekly RecurringEvent occurs.
— hasMonth: specifies the month on which which a YearlyRecurringEvent occurs.
— dayOfMonth: specifies the day of the month on which a MonthlyRecurringEvent occurs.
— beginsRecurringTime: defines a time to initiate the RecurringEvent.
— endsRecurringTime: defines a time to terminate the RecurringEvent .
— beginsRecurringState: defines a State that is required to be true in order to initiate the RecurringEvent.
— endsRecurringState: defines a State that is required to be true in order terminate the RecurringEvent.
— recursExcept: defines the exceptions for the RecurringEvent, i.e. conditions when it does not occur. This can specify a time, day of the week, or specific dates.
— recursAddition: defines a condition when the RecurringEvent should be added to. This can specify a time, day of the week, or specific dates.
An ExceptionDay specifies a day or days that recursExcept and recursAddition use to specify unique days that do not recur on the same day each year, for example, holidays. It has the following properties:
— hasName: the name of the exception day, e.g. Labour Day.
— time:hasTIme: specifies the year/month/day on which the exception occurs.
A DailyRecurringEvent occurs every day. It has a maximum of one associated time, the start time. Typically, a daily recurring event will occur at the same time every day, but there is potentially no commitment to a recurring start time for the event, in which case no start time is specified. A DailyEvent does not necessarily have a recurring end time (this would require a constant duration), therefore this is not part of the definition (although it is possible to specify).
A WeeklyRecurringEvent recurs regularly on the same day of the week, as specified by the schema:dayOfWeek property.
A MonthlyRecurringEvent recurs regularly on the same day of each month, as specified by the dayOfMonth data property. Note that there is often ambiguity regarding the semantics of a monthly recurring event: in this formalization, a MonthlyRecurringEvent is any event that recurs regularly on the same day of each month; other interpretations sometimes consider events that recur on the same day of week, or first or last day, in which case the day of month will vary. Such a representation is not included in this ontology, but could be captured in an extension.
A YearlyRecurringEvent recurs regularly on the same day of the same month, as specified by the hasMonth and dayOfMonth properties. As with MonthlyRecurringEvent, there can be ambiguity regarding the semantics of a yearly recurring event. However, this formalization captures only the notion of an event that recurs on the same day of the same month (e.g. a birthday).
Figures 12 and 13 illustrate how the Recurring Event Pattern could be used to define the concept of a scheduled bus trip. In this example, the scheduled bus trip “sched_bus_trip” recurs daily at 8:00 am so all occurrences of the event (i.e. activities “bustrip1_123”, “bustrip1_321”) should occur at 8:00 am on their respective dates.
|Classes=RecurringEvent, DailyRecurringEvent, WeeklyRecurringEvent, MonthlyRecurringEvent, YearlyRecurringEvent, ExceptionDay
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Activity Pattern

2022-08-24T12:40:33Z

MarkFox:

{{Pattern Definition
|Description=The concept of activities arises in many cases in city data: there are trip activities that contribute to the demand on a transportation system, and the routine activities that motivate these trips; there are educational and recreational activities offered by various city services. In the most general sense, activities are things that happen; events that occur (scheduled or not) or actions that are performed by some agent. Activities may be described by the time and location of their occurrence, their preconditions and effects, as well through the identification of any objects that are somehow involved.
There are many OWL ontologies that in some way address the concept of activities. However, most are lacking with respect to the basic representation requirements. The Activity Pattern adopts the Activity Specification design pattern that was presented in Reference [13] as a solution to address these limitations. The representation of activity specifications is based on the activity clusters introduced by Fox, Sathi, and colleagues.[14],[15].
A precursor to the TOronto Virtual Enterprise[16] and Process Specification Language[17] activity ontologies, an activity cluster provides a basic structure for representing activity specifications. Illustrated in Figure 10, it consists of an activity connected to an enabling and caused state, each of which may be a state tree that defines complex states via decomposition into conjunctions and disjunctions of states.

In this approach an activity is interpreted as a class of occurrences, in contrast with other approaches where activities are separate entities that are related to occurrences via an "occurrence of" relation. This decision was motivated by several pragmatic factors: in many cases it is sufficient to capture information regarding individual activities (i.e. occurrences or events). These activities may be categorized via different subclasses of “Activity”, but there is no need to associate them with a single activity type entity, unless it is wished to characterize the activity type itself. The capability for this more complex formalization is supported, if necessary, by the Recurring Event Pattern (see 6.9). Dividing these representations into two separate ontologies allows users of the ISO/IEC 5087 series the discretion to only include what is needed. In addition, much of the semantics that relate activity types and occurrences is not expressible in OWL. The Activity Ontology works within the limitations of OWL to capture the concepts of activities, their composition, preconditions and effects, and ordering.
|Key Concepts and Classes=— Activity: An Activity describes something that occurs in the domain. It has the following set of core properties:
hasSubactivity: identifies a more granular Activity into which the Activity may be decomposed.
hasStatus: identifies an ActivityStatus. This specifies the status of the Activity at some point or interval in time. For example, the Activity may be “scheduled, “executing” or “completed”.
hasPrecondition: identifies a State that must be realized in order for the Activity to occur.
hasEffect: identifies a State that is realized once the Activity has occurred.
occursAt: identifies a time Interval over which the Activity occurs.
hasLocation: identifies a location (a spatial Feature) where the Activity occurs.
scheduledFor: identifies the time Interval that an Activity was scheduled to be performed/occur at.
occursBefore: identifies an Activity that the Activity occurred before.
An Activity may also be described with the following, supplemental properties:
enabledByState: identifies a State that in some (indirect) way enabled the Activity to occur. An Activity is enabled by a State if the State is a precondition for the Activity or if the State is a precondition of some subactivity of the Activity. The enabledByState property is a generalization (super-property) of the hasPrecondition property.
causesState: identifies a State that in some (indirect) way was caused by the occurrence of the Activity. An Activity is caused by a State if the State is an effect of the Activity or if the State is an effect of some subactivity of the Activity. The causes property is a generalization (super-property) of the hasEffect property.
occursDirectlyBefore: identifies an Activity that occurred immediately prior to the Activity. The occursDirectlyBefore property is a sub-property of the occursBefore property.
beginOf: identifies the time Instant at which the Activity occurs.
endOf: identifies the time Instant at which the Activity ends.
— State: A State specifies some snapshot of objects in the domain as they exist at some point in time. States have the following core set of properties:
hasStatus: identifies the StateStatus at some point or interval in time. For example, the State may be “unsatisfied, “satisfied” or “completed”.
achievedAt: identifies the time Interval or Instant during which the State was satisfied.
scheduledFor: identifies a time Interval during which the State is scheduled to be realized.
effectOf: identifies an Activity that the State was realized by.
preconditionOf: identifies an Activity that requires the State to be realized in order to occur.
A State may also be described with the following, supplemental properties:
enablesActivity: identifies an Activity that in some (indirect) way was enabled by the State. The enables property is the inverse of the enabledBy property and is a generalization (super-property) of the preconditionOf property.
causedByActivity: identifies an Activity that in some (indirect) way caused the State to be realized. The causedBy property is the inverse of the causes property and is a generalization (super-property) of the effectOf property.
— TerminalState: A State may be either non-terminal or terminal. A TerminalState has no sub-states.
— ManifestationState: A specialization of TerminalState, the ManifestationState specifies a Manifestation class that an individual must satisfy in order for the ManifestationState to be true.
satisfiedBy: specifies the Manifestation that is to be satisfied (i.e., realized).
— NonTerminalState: a NonTerminalState has child States, which may be TerminalStates, or further define some other complex state types. A State cannot be both non-terminal and terminal. NonTerminalStates have the following core properties:
hasDecomp: identifies two or more States into which the State may be immediately decomposed, i.e. its direct children.
NonTerminalState has the following supplemental properties:
hasSubState: identifies a State into which the complex state decomposes, at any level (i.e. its child state, grandchild state, etc.). The hasSubState property is transitive and a super-property of the hasDecomp property.
— ConjunctiveState: a ConjunctiveState is a type of NonTerminalState that is defined by the conjunction of its child States.
— DisjunctiveState: a DisjunctiveState is a type of NonTerminalState that is defined by the disjunction of its child States. A State cannot be both conjunctive and disjunctive. Conjunctive and disjunctive States, which do have substates, are achieved at some time if their decomposition of States is achieved.
|Classes=Activity, ConjunctiveState, DisjunctiveState, ManifestationState, NonTerminalState, State, TerminalState
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=Activity Pattern.jpg
|Caption=Activity Pattern Example
}}
}}

File:Activity Pattern.jpg

2022-08-24T12:40:07Z

MarkFox:

Pattern:Activity Pattern

2022-08-24T12:38:34Z

MarkFox: Created page with "{{Pattern Definition |Description=The concept of activities arises in many cases in city data: there are trip activities that contribute to the demand on a transportation syst..."

{{Pattern Definition
|Description=The concept of activities arises in many cases in city data: there are trip activities that contribute to the demand on a transportation system, and the routine activities that motivate these trips; there are educational and recreational activities offered by various city services. In the most general sense, activities are things that happen; events that occur (scheduled or not) or actions that are performed by some agent. Activities may be described by the time and location of their occurrence, their preconditions and effects, as well through the identification of any objects that are somehow involved.
There are many OWL ontologies that in some way address the concept of activities. However, most are lacking with respect to the basic representation requirements. The Activity Pattern adopts the Activity Specification design pattern that was presented in Reference [13] as a solution to address these limitations. The representation of activity specifications is based on the activity clusters introduced by Fox, Sathi, and colleagues.[14],[15].
A precursor to the TOronto Virtual Enterprise[16] and Process Specification Language[17] activity ontologies, an activity cluster provides a basic structure for representing activity specifications. Illustrated in Figure 10, it consists of an activity connected to an enabling and caused state, each of which may be a state tree that defines complex states via decomposition into conjunctions and disjunctions of states.

In this approach an activity is interpreted as a class of occurrences, in contrast with other approaches where activities are separate entities that are related to occurrences via an "occurrence of" relation. This decision was motivated by several pragmatic factors: in many cases it is sufficient to capture information regarding individual activities (i.e. occurrences or events). These activities may be categorized via different subclasses of “Activity”, but there is no need to associate them with a single activity type entity, unless it is wished to characterize the activity type itself. The capability for this more complex formalization is supported, if necessary, by the Recurring Event Pattern (see 6.9). Dividing these representations into two separate ontologies allows users of the ISO/IEC 5087 series the discretion to only include what is needed. In addition, much of the semantics that relate activity types and occurrences is not expressible in OWL. The Activity Ontology works within the limitations of OWL to capture the concepts of activities, their composition, preconditions and effects, and ordering.
|Key Concepts and Classes=— Activity: An Activity describes something that occurs in the domain. It has the following set of core properties:
hasSubactivity: identifies a more granular Activity into which the Activity may be decomposed.
hasStatus: identifies an ActivityStatus. This specifies the status of the Activity at some point or interval in time. For example, the Activity may be “scheduled, “executing” or “completed”.
hasPrecondition: identifies a State that must be realized in order for the Activity to occur.
hasEffect: identifies a State that is realized once the Activity has occurred.
occursAt: identifies a time Interval over which the Activity occurs.
hasLocation: identifies a location (a spatial Feature) where the Activity occurs.
scheduledFor: identifies the time Interval that an Activity was scheduled to be performed/occur at.
occursBefore: identifies an Activity that the Activity occurred before.
An Activity may also be described with the following, supplemental properties:
enabledByState: identifies a State that in some (indirect) way enabled the Activity to occur. An Activity is enabled by a State if the State is a precondition for the Activity or if the State is a precondition of some subactivity of the Activity. The enabledByState property is a generalization (super-property) of the hasPrecondition property.
causesState: identifies a State that in some (indirect) way was caused by the occurrence of the Activity. An Activity is caused by a State if the State is an effect of the Activity or if the State is an effect of some subactivity of the Activity. The causes property is a generalization (super-property) of the hasEffect property.
occursDirectlyBefore: identifies an Activity that occurred immediately prior to the Activity. The occursDirectlyBefore property is a sub-property of the occursBefore property.
beginOf: identifies the time Instant at which the Activity occurs.
endOf: identifies the time Instant at which the Activity ends.
— State: A State specifies some snapshot of objects in the domain as they exist at some point in time. States have the following core set of properties:
hasStatus: identifies the StateStatus at some point or interval in time. For example, the State may be “unsatisfied, “satisfied” or “completed”.
achievedAt: identifies the time Interval or Instant during which the State was satisfied.
scheduledFor: identifies a time Interval during which the State is scheduled to be realized.
effectOf: identifies an Activity that the State was realized by.
preconditionOf: identifies an Activity that requires the State to be realized in order to occur.
A State may also be described with the following, supplemental properties:
enablesActivity: identifies an Activity that in some (indirect) way was enabled by the State. The enables property is the inverse of the enabledBy property and is a generalization (super-property) of the preconditionOf property.
causedByActivity: identifies an Activity that in some (indirect) way caused the State to be realized. The causedBy property is the inverse of the causes property and is a generalization (super-property) of the effectOf property.
— TerminalState: A State may be either non-terminal or terminal. A TerminalState has no sub-states.
— ManifestationState: A specialization of TerminalState, the ManifestationState specifies a Manifestation class that an individual must satisfy in order for the ManifestationState to be true.
satisfiedBy: specifies the Manifestation that is to be satisfied (i.e., realized).
— NonTerminalState: a NonTerminalState has child States, which may be TerminalStates, or further define some other complex state types. A State cannot be both non-terminal and terminal. NonTerminalStates have the following core properties:
hasDecomp: identifies two or more States into which the State may be immediately decomposed, i.e. its direct children.
NonTerminalState has the following supplemental properties:
hasSubState: identifies a State into which the complex state decomposes, at any level (i.e. its child state, grandchild state, etc.). The hasSubState property is transitive and a super-property of the hasDecomp property.
— ConjunctiveState: a ConjunctiveState is a type of NonTerminalState that is defined by the conjunction of its child States.
— DisjunctiveState: a DisjunctiveState is a type of NonTerminalState that is defined by the disjunction of its child States. A State cannot be both conjunctive and disjunctive. Conjunctive and disjunctive States, which do have substates, are achieved at some time if their decomposition of States is achieved.
|Classes=Activity, State, TerminalState, ManifestationState, NonTerminalState, ConjunctiveState, DisjunctiveState
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Organization Pattern

2022-08-24T10:46:10Z

MarkFox: Created page with "{{Pattern Definition |Description=The representation of organization structure information shall conform to the ontology specified in the W3C Recommendation “The Organizatio..."

{{Pattern Definition
|Description=The representation of organization structure information shall conform to the ontology specified in the W3C Recommendation “The Organization Ontology”. It is included in its entirety with the prefix ‘org’.
In the W3C Organization ontology, an Organization may act as an agent and is comprised of a collection of people, organized with some structure, and with some common goal. In this document, an Organization is defined as a subclass of org:Organization with extensions/specializations relevant to this document.
|Key Concepts and Classes=— Organization: an Organization may act as an agent and is comprised of a collection of people, organized with some structure, and with some common goal. Properties included are:
org:hasMember: identifies an agent that is a member of the Organization.
org:hasSubOrganization: identifies a sub-Organization within the Organization.
org:hasUnit: indicates an OrganizationUnit which is part of the Organization.
org:hasPost: identifies a Post that exists in the Organization.
hasAsset: identifies an asset possessed by the Organization.
— OrganizationalUnit: An organization, such as a department, that is part of a larger Organization, but is recognized only in the context of the Organization. It is not regarded as a legal entity in its own right.
— Post: A Post is a position within the organization that may or may not be held by some agent. It is extended in this document to be a subclass of a Role. Properties included are:
org:postIn: links a Post to an Organization
org:heldBy: links a Post to an Agent
hasName: the name of the Post
|Classes=Organization, OrganizationalUnit, Post
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Agent Pattern

2022-08-24T10:44:07Z

MarkFox: Created page with "{{Pattern Definition |Description=An Agent is defined in the context of an Activity that it affects or is affected by, or their role within an Organization. An Agent can be a..."

{{Pattern Definition
|Description=An Agent is defined in the context of an Activity that it affects or is affected by, or their role within an Organization. An Agent can be a Person, Organization, Software or Mechanical device.
|Key Concepts and Classes=The key class in this pattern is formalized in Table 8.
— Agent: An Agent affects, is affected by, or performs some Activity(s). Examples of an Agent include persons and organizations. An Agent has the following core properties:
hasName: an identifier for the Agent;
resourceOf: identifies what State the agent may be a resource of;
performs: identifies activities that the Agent performs.
|Classes=Agent
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Pattern:Change Pattern

2022-08-24T10:42:37Z

MarkFox: Created page with "{{Pattern Definition |Description=Many of the concepts identified in the urban system ontologies are subject to change. For example, a Vehicle will have one location at one ti..."

{{Pattern Definition
|Description=Many of the concepts identified in the urban system ontologies are subject to change. For example, a Vehicle will have one location at one time, and another location at a later time; it can have only one passenger at one time, and four passengers at a later time. Similarly, many attributes of Persons, Households and even Transportation Networks are subject to change.

Change over time plays a role in many domains and is by no means a new research topic. In fact, several approaches for capturing change in OWL have been proposed.[10], [11] Despite these solutions, it has been found that Semantic Web practitioners currently lack clear and precise methods for how to apply these approaches to capture change at a domain level, whether reusing a temporal ontology or developing an ontology from scratch. The Change Pattern serves as a clear guide to support a consistent approach to representing change over time.
|Key Concepts and Classes=The key classes and properties are formalized in Table 6 and Table 7, respectively. An approach to representing changing properties, or "fluents", that leverages the 4-dimensionalist perspective was proposed in Reference [10]. A similar approach is adopted in this document, based on the design pattern presented by Reference [12], requiring the representation of objects that are subject to change as subclasses of the Manifestation class. Manifestations may be interpreted as “snapshots” of an object at some point in time. This enables the representation of changing values of properties of an object, without losing information about its past values/relationships. The properties of the class can then be identified as properties that are (and are not) subject to change, in order to distinguish between the static and dynamic aspects of a particular entity.
The Manifestation class is defined using the following properties:
— existsAt: identifies the TemporalEntity that reflects the time Instant of Interval during which the snapshot of the object holds (is valid).
— hasNextManifestation: identifies the immediate successor Manifestation (i.e. the subsequent snapshot of the object).
— hasPreviousManifestation: identifies the immediate prior Manifestation (i.e. the prior snapshot of the object).
— hasFirstManifestation: identifies the First Manifestation that is related to a particular Manifestation (i.e., for some snapshot of an object, it identifies the first such snapshot of the object).
The class FirstManifestation denotes the first manifestation of an individual. No prior manifestations (in time) exist for the individual. It is a subclassOf Manifestation and contains the following additional properties:
— precedesManifestation: identifies all subsequent Manifestations that follow a FirstManifestation. In other words, the FirstManifestation is related to each and every subsequent manifestation via the precedesManifestation.
— hasLatestManifestation: identifies the most recent Manifestation that is related to a particular FirstManifestation (i.e., for some snapshot of an object, it identifies the most recent snapshot of the object).
|Classes=Manifestation, FirstManifestation
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=Change-Pattern.jpg
}}
}}

File:Change-Pattern.jpg

2022-08-24T10:42:31Z

MarkFox:

Pattern:Time Pattern

2022-08-24T10:38:18Z

MarkFox: Created page with "{{Pattern Definition |Description=In order to define an ontology pattern for time, it is necessary to identify the objects of interest, i.e. which things will be described. In..."

{{Pattern Definition
|Description=In order to define an ontology pattern for time, it is necessary to identify the objects of interest, i.e. which things will be described. In general, three approaches to a representation of time can be identified: point-based, interval-based, and mixed. In a point-based representation, the objects of interest are timepoints. The passing of time is described as an ordering over time points, and periods of time can be represented as a series of timepoints. In an interval-based representation the objects of interest are time intervals, whereas the mixed representation includes both timepoints and time intervals. Key to all of these representations is that there is an ordering that holds over these time objects. It is important to be able to describe whether one time object is before another; in the case of time intervals it is also important to be able to describe other relationships, such as whether one interval is contained in or overlaps with another.
The representation of time information shall conform to the ontology specified in the W3C Candidate Recommendation “Time Ontology in OWL”. It is included in its entirety with the prefix ‘time’.
|Key Concepts and Classes=In this pattern, a subset of the W3C Time Ontology is reproduced:
— Temporal Entity: represents a generic time object – either an Instant or an Interval. Core properties are:
before: specifies a Temporal Entity before which the Temporal Entity exists;
after: specifies a Temporal Entity after which the Temporal Entity exists;
hasBeginning: specifies an Instant that identifies the beginning of the Temporal Entity;
hasEnd: specifies an Instant that identifies the end of the Temporal Entity;
hasXSDDuration: specifies the duration of a Temporal Entity in the xsd:duration format.
— Instant: represents an instant in time (i.e. a moment; a temporal entity without any duration). Core properties are:
inXSDDateTimeStamp: specifies the date and time that can be used to identify the time instance, in the xsd:dateTimeStamp format.
— Interval: represents an interval in time (i.e. a temporal entity with some duration). Core properties are:
inside: specifies an Instant that exists “inside” (during) the Interval.
|Classes=TemporalEntity, Instant, Interval
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=Time-Pattern.jpeg
|Caption=Time Pattern Example
}}
}}

File:Time-Pattern.jpeg

2022-08-24T10:38:14Z

MarkFox:

Pattern:Location Pattern

2022-08-24T10:34:59Z

MarkFox: Created page with "{{Pattern Definition |Description=The ontology for representing location information shall conform to the vocabulary specified in OGC 11-052r4 (GeoSPARQL). To capture generic..."

{{Pattern Definition
|Description=The ontology for representing location information shall conform to the vocabulary specified in OGC 11-052r4 (GeoSPARQL). To capture generic spatial features requires concepts of location, but also concepts of geometry in order to describe shapes that are more complex than a single point in space. In addition, there is a need to be able to describe the spatial relationship between various features (e.g. containment, overlap). The GeoSPARQL Ontology is used in the Location Pattern to achieve this. It is included in its entirety with the prefix ‘geo’.
|Key Concepts and Classes=The key classes and properties are formalized in Table 3 and Table 4, respectively. In this subclause, a subset of the GeoSPARQL Ontology is replicated and specialized:
— Feature: represents some area in space. Features are distinguished by their geometric shape as well as their geographic location. Features may also be related to other Features via mereotopological relations such as containment and contact. Core properties are:
hasGeometry: specifies the shape that defines the location of the Feature in order to capture quantitative spatial information.
— Geometry: represents a shape. Various types (subclasses) of Geometry are defined in the GeoSPARQL Ontology including the classes: Point, Polygon, and Curve. Core properties are:
asWKT: specifies the well-known text encoding of a given geometry. The default reference system for the coordinate values is assumed to be WGS84. GeoSPARQL supports the identification of alternate reference systems, captured as IRIs and concatenated with the coordinates.
In addition, the pattern specifies the following generic properties to support the reference of locations by other classes:
— hasLocation: captures the relationship between objects and the Features they occupy.
— associatedLocation: introduced to capture the association of a given object with a particular location. For example, a train station can occupy a fairly large spatial location but be associated with a particular point.
|Classes=Feature, Geometry
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=Location-Pattern.jpeg
|Caption=Location Pattern Example
}}
}}

File:Location-Pattern.jpeg

2022-08-24T10:34:20Z

MarkFox:

Pattern:Person Pattern

2022-07-17T14:36:14Z

MarkFox: Created page with "{{Pattern Definition |Description=Persons are a key category in Smart City Models. It is the combination of decisions of persons in the population that result in changes to tr..."

{{Pattern Definition
|Description=Persons are a key category in Smart City Models. It is the combination of decisions of persons in the population that result in changes to travel behaviour. For example, consider a person's decision to change places of employment. Among other things, this change will likely impact their daily travel behaviour. The Person Pattern enables the representation of persons and their attributes of interest. Factors such as a person's age, income, and place of residence are defined as properties of a person. The Change Pattern is used to specify which attributes may change over time (e.g. income), and which attributes are constant (e.g. date of birth).
|Key Concepts and Classes=The key classes and properties are formalized in Table 8 and Table 9, respectively. Person has the following properties:
• hasPersonID: links zero or more to instances of PersonID. Can be a driver’s license, passport, etc.
• hasName: links to zero or more instances of PersonName – a person can have multiple names.
• hasAddress: links to zero or more Address for the Person.
• hasPhoneNumber: links to zero or more PhoneNumbers for the Person.
• hasEmail: specifies zero or more email addresses as xsd:strings.
• cityresident:citizenOf: links to instances of Citizenship that specify the country they are/were a citizen of, and the time period.
• schema:birthdate: A time:Instant when the person was born.
• schema:birthplace: An address for where the person was born.
• schema:deathDate: A time:Instant when the person died.
• schema:deathplace: An address for where the person died.
• schema:parent: links to zero or more Persons who are their parent. Note that we define the parent relation as the legal relation as opposed to biological. This property may be specialized and restricted, for example hasBiologicalMother: exactly 1 Person.
• schema:spouse: links to zero or more Persons who are their spouse.
• schema:children: links to zero or more Persons who are their children.
• hasSex: A Person has exactly 1 sex, and sex may be one of only male or female. The definition of sex is distinct from that of a person’s gender: “Sex refers to sex assigned at birth. Sex is typically assigned based on a person's reproductive system and other physical characteristics.”
• hasGender: A Person may also have an associated Gender. The value of this may or may not differ from a person’s sex at birth. Precisely how Gender is defined and instantiated varies based upon context and so may be defined by the user of this standard as appropriate.
• hasIncome: specifies the annual income for ther person.
• hasSkill: identifies the Skills the Person has.
• hasEducation: identifies the education the Person has.
Note the Skill and Education classes are not defined and are left to the application to define.
PersonName represents the parts of a person’s name:
• schema:givenName: a string that is the given or first name of the Person.
• schema:additionalName: a string that is the middle or additional names of the Person.
• schema:familyName: as single string that is the family or last name of the Person.
PersonID represent a unique identifier for the Person issued by an Organization. It has the following properties
• schema:identifier: a string that encodes the unique id of the person.
• hasIDType: specifies the type of ID, including passport an driversLicense.
• photoID: A Boolean that specifies whether the ID contains a photo.
• time:hasTime: defines a time interval during which the ID is valid.
• schema:issuedBy: an Organiztaion that issued the id.
|Classes=Person,PersonID,Sex
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Building Pattern

2022-07-17T14:30:51Z

{{Pattern Definition
|Description=The Building pattern defines the concepts to capture information about individual buildings, thus describing land use from a different perspective and at a finer level of granularity than typical land use classifications. The Infrastructure Pattern is reused here, as Buildings and Building Units are defined as types of (subclasses) Infrastructure Elements. The Building pattern also reuses the Spatial Location pattern in order to capture the location of a building. While we expect the address of a building to remain constant its exact location can change over time, as in the case of a remodeling or extension. The possibility is supported by the Building pattern, which also reuses the Change pattern and captures the location as a variant property. Other attributes of a building are also captured, such as the type of building, units contained in a building, their monetary value, and so on. The Mereology pattern is used to capture the disaggregate parts of a building, and the Units of Measure pattern is required to capture attributes required for land value considerations, such as sale prices and square footage.
|Key Concepts and Classes=The key classes and properties are formalized in Table 4 and Table 5, respectively. A Building is a structure with some location in the urban system. The location of the Building in space may change (e.g. due to construction). – this may be described in terms of both actual (e.g. 2D and 3D space) location occupied by the building and associated locations (e.g. a point coordinate). There are different types (subclasses) of buildings, such as House, Apartment Building, Office Building, and so on. A Building has a market value.
A Building contains one or many units. A Building has some height, some footprint area, and some floor area. The floor area is often greater than the footprint area as it accounts for the area of each floor of the building. However, floor area excludes unoccupied areas such as basements.
A BuildingUnit has a size (square footage, number of rooms). A Building or BuildingUnit may contain some Facility(s), e.g. kitchen, bath, or air conditioning. Note that this is distinct from the notion of including amenities that are not a physical part of the Building (or BuildingUnit), but which may be part of the Tenure. A BuildingUnit has an address. A BuildingUnit has a value and may have some rental fee.
Different types (subclasses) of Building may be defined as required. It is recommended to avoid confusing type of building structure with building use. For example, a “Detached House” is a type of building whereas an “Office” is not. A Building also requires some degree of permanence; a “Duplex” or a “Garage” may be defined as types of buildings, whereas a tent may not. Also note that a Building refers only to the structure, not the surrounding area; an airport terminal is a building, an aircraft hangar is a building, but the entire airport complex is not.
A Building (or class of buildings) may be described as having some associated use and/or function. The values of a building’s use or function properties may be populated according to one or more existing classification systems. In this way it is also possible to extend the pattern with various subclasses of Building, as required for a given application.
|Classes=Building,BuildingUnit,Facility
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}

Household

2022-07-05T19:28:55Z

MarkFox:

{{Pattern Definition
|Description=The behaviour of a household can be represented by the collective activities of its members. The Household pattern supports the representation of Households, Families, and Dwelling Units - all of which are distinct, though closely related concepts.
|Key Concepts and Classes=The definition of a Household, requires the following key classes and properties:
• Household: A Household occupies a particular Dwelling, according to some tenure type. It is defined by this location, so that if the members move (even collectively), the new residence constitutes a new Household.
Note that a Household, and likely many other classes may have different definitions in different contexts/applications. To address this, specializations of the class may be introduced as extensions.
• Dwelling Unit: A Dwelling Unit is occupied by a Household. A Dwelling Unit has a market value. A Dwelling Unit has some Location.
• Tenure: Arrangement under which the occupant has the right to live in the dwelling unit.
|Classes=Household
|Definition Status=Pending Approval
}}
{{Supplementary Figures}}
{{Class Definition
|Subclass Of=Manifestation
|Description=A Household occupies a particular Dwelling, according to some tenure type. It is defined by this location, so that if the members move (even collectively), the new residence constitutes a new Household.
Note that a Household, and likely many other classes may have different definitions in different contexts/applications. To address this we may be required to introduce specializations of the class (e.g. ILUTE_Household, TTS_Household) in future extensions.
|Definition Status=Pending Approval
}}
{{Annotation Specification}}
{{Manchester Specification
|Manchester Row={{Manchester Row
|Property=HouseholdOccupies
|Restriction=exactly 1
|Value=DwellingUnit
}}{{Manchester Row
|Property=Org:hasMember
|Restriction=only
|Value=Person
}}
}}

City Service

2022-07-05T19:19:19Z

{{Pattern Definition
|Description=Cities provide a variety of services to residents and businesses, including health and social services. The city service pattern, is based on the Canadian Government Reference Model (CGRM), depicted in Figure 3. It identifies the following concepts as a basis for understanding the services that governments (Wiseman, 2015):
• Programs are major city initiatives that address the needs of their constituents (citizens, clients). They are a mandate to achieve Outcomes by delivering Services. For example, ending homelessness. “For the citizens and clients of government, programs are abstract, whereas services are real. They represent the point of interaction between governments and their clients.” (Wiseman, 2015)
• Services deliver outputs to clients that contribute to program outcomes. For example, providing shelters for the homeless.
• The processes are activities that deliver services. For example, homeless person registration, bed allocation, etc.
• Resources are used in carrying out processes. For example, shelter space, beds, and personnel.
|Key Concepts and Classes=A Program defines a set of services that focus on a shared set of Outcomes. For example, a “poverty reduction program” can be made up of a set of Services such as mobiles services that provides food and clothing to those that live on the street, and a training service that provides basic skills for those living on the street. A Program has a set of Stakeholders that can contribute or benefit. The following are the Program properties:
• hasService: Identifies the Services that make up the Program.
• hasOutcome: Identifies the Outcomes that the program is trying to achieve.
• hasContributingStakeholder: Identifies the stakeholders that contribute to the Program.
• hasBeneficialStakeholder: Identifies the stakeholders that benefit from the Program.
• hasInput: Identifies the Inputs to the Program.
• hasOutput: Identifies the Outputs of the Program.
A Program is composed of one or more Services. As described in the Program description, a poverty reduction program can have many services with each service comprised of different activities, Inputs, Outputs and Outcomes. The following are the Service properties:
• activity:hasSubActivity: Identifies the Activities that make that comprise the Service.
• hasInput: Identifies the Inputs to the Service.
• hasOutput: Identifies the Outputs of the Service.
• hasOutcome: Identifies the Outcomes that are specific to the Service.
• hasContributingStakeholder: Identifies the stakeholders that contribute to the Service.
• hasBeneficialStakeholder: Identifies the stakeholders that benefit from the Service.
Outcome’s “are what stakeholders experience as a result of a city Programs and/or Services. They can be positive or negative, intended or unintended.” Outcome contains the following properties:
• hasBeneficialStakeholder: Identifies the Stakeholder affected.
• hasIndicator: Identifies the set of Indicators the organization assigns to the Outcome.
• schema:description: A general description of the Outcome as a string.
• fromPerspectiveOf: Identifies the Stakeholder who is determining the importance of the Impact.
• hasImportance: Specifies how important the Impact is (high, medium, low).
• intendedImpact: Identifies the intended direction of the change.
Stakeholder is a person or organization that either contributes to or benefits from a Program and/or Service. It has the following properties:
• schema:name (title): A title for the stakeholder as a string.
• schema:description: A general description of the stakeholder as a string.
• hasCatchmentArea: Specifies the regional span of the stakeholders.
• perform: Links to the activities performed by the stakeholder.
Input defines the resources and the stakeholders that contribute them that are input to an Activity:
• forActivity: The Program or Service or Activity this is an input for.
• hasContributingStakeholder: The Stakeholders that contribute the resources as input.
• hasResource: Specifies the input Resource.
• hasPlannedAmount: Specifies the amount of the input Resource
• hasActualAmount: Specifies actual amount of input Resource used.
• i72:for_time_interval: Specifies the time interval over which the input is used.
• sch:name: Name for the Input.
• sch:description: Description for the Input.
Output is a quantitative summary of an activity. For example, if the activity is ‘we provide training’ and the output is ‘we trained 50 people to NVQ level 3’. Or a production output could produce 100 meals for the homeless. Basic to these outputs is “what” has been produced and the quantity.
• forActivity: Identifies the Activity or Service that produces the Output.
• i72:value: Identifies that amount that is produced.
• hasResource: Identifies the Resource that is produced such as a skill, or a type of Meal.
• usedByIndicator: Identifies the Indicators that use this Output in determining the value of the Indicator.
|Classes=Input, Outcome, Output, Program, Service, Stakeholder
|Definition Status=Pending Approval
}}
{{Supplementary Figures
|Figure Row={{Figure Row
|Figure=City Service Pattern.jpeg,
|Caption=City Service Pattern
}}
}}

File:City Service Pattern.jpeg

2022-07-05T19:18:12Z

MarkFox:

File:CityResident.png

2020-08-20T14:00:22Z

MarkFox: