Difference between revisions of "Main Page"
Megankatsumi (talk | contribs) |
Megankatsumi (talk | contribs) |
||
(46 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | <h1> Welcome to the City Data Model Collaboration Wiki | + | <h1> Welcome to the City Data Model Collaboration Wiki</h1> |
− | + | == Introduction == | |
− | + | This website is intended to foster international collaboration between stakeholders and related standards groups on a common [[City_Data_Model_Project_Collaboratory_Wiki:About|City Data Model]]. The results of this effort will feed into the various city data standards development projects being undertaken by various Standards Development Organizations. | |
− | |||
− | |||
− | |||
− | |||
+ | A common data model enables city software applications to share information, plan, coordinate, and execute city tasks, and support decision making within and across city services, by providing a precise, unambiguous representation of information and knowledge commonly shared across city services. This requires a clear understanding of the terms used in defining the data, as well as how they relate to one another. Beyond syntactic integration (e.g. common data types and protocols), this requires semantic integration: a consistent, shared understanding of the meaning of information. | ||
− | == | + | The City Data Model is stratified into three levels of abstraction (pictured below). The Foundation Level covers very general concepts such as Time, Location, and Activity. The City Level covers concepts that are general to cities and span all services such as Households, Services, Residents. The Service Level spans concepts commonly associated with a particular service but still shared with other services, such as Vehicles and Transportation network. |
− | + | [[File:City data levels.png|thumb|center|The three levels of the city data model: foundational concepts, city-level concepts, and service-level concepts.]] | |
+ | |||
+ | The goal of this wiki is to develop a global consensus regarding the classes, properties, and definitions that should be included in a City Data Model. This website will serve as a means of establishing this consensus through open communication and collaboration. It facilitates the sharing of suggestions, comments, and critiques. The mechanisms for these contributions are described in the sections below. | ||
+ | |||
+ | === Beta Disclaimer === | ||
+ | Please note that this is a beta version of the City Data Model Collaboratory website. The website is still undergoing testing and evaluation. Should you encounter any bugs, glitches, lack of functionality or other problems on the website, please let us know immediately so we can rectify these accordingly. Your help in this regard is greatly appreciated. | ||
== Getting started == | == Getting started == | ||
Want to contribute? Log-in or create an account! | Want to contribute? Log-in or create an account! | ||
+ | Anyone with an account can comment on proposed or existing terms, and even propose their own. | ||
− | + | '''To do:''' Add material on use cases. | |
− | + | ||
− | + | Users can propose new terms or new definitions for existing [[:Category:Class|classes]], [[:Category:ObjectProperty|object properties]], or [[:Category:DataProperty|data properties]]. | |
+ | |||
+ | '''Note:''' The following descriptions focus on the meaning of the different types of terms in the context of the OWL, RDF and UML languages. While there are strong similarities between the term types, there are differences in the expressive abilities of the referenced languages. As a result, it will not always be possible to completely translate a term definition from one language to another. | ||
+ | * A '''Class''' is a term that is used to describe some grouping of things. Classes may be related to other classes via a notion of inheritance (subclass). | ||
+ | **OWL: Classes correspond to Classes as defined in OWL2. <q>In general classes are used to group individuals that have something in common in order to refer to them. Hence, classes essentially represent sets of individuals. In modelling, classes are often used to denote the set of objects comprised by a concept of human thinking, like the concept person or the concept woman.</q> --[https://www.w3.org/TR/owl2-primer/#Classes.2C_Properties.2C_and_Individuals_.E2.80.93_And_Basic_Modeling_With_Them| Owl2 Primer] | ||
+ | **RDF: Classes are similar to the [https://www.w3.org/TR/rdf-schema/| RDF Schema] classes that are used to group [https://www.w3.org/TR/rdf-schema/#ch_resource| resources]. Distinct from RDF, we do not consider other Classes or Properties to be members of a Class. | ||
+ | **UML: Classes correspond to UML Classes, i.e. classes in the object-oriented programming sense. Classes are objects in a system that have some predefined set of attributes and behaviour. They may also be represented with UML Class diagrams. | ||
+ | * An '''ObjectProperty''' is a term that is used to describe the relationship between instances. | ||
+ | **OWL: Object Properties correspond to Object Properties in [https://www.w3.org/TR/owl2-primer/#Object_Properties| OWL2]. | ||
+ | **RDF: Object Properties correspond to a restricted set of RDF Properties that only relate instances that are members of some Class(es) of things (i.e. they do not relate instances of Classes to [https://www.w3.org/TR/rdf-schema/#ch_literal| literal values]). | ||
+ | **UML: Object Properties correspond to the instance-level relationships (uni-directional associations) that are identified in UML Class diagrams. | ||
+ | * A '''DataProperty''' is a term that is used to describe the relationship between an instance and some data value. | ||
+ | **OWL: Data Properties correspond to Data Properties defined in [https://www.w3.org/TR/owl2-primer/#Datatypes| OWL2]. | ||
+ | **RDF: Data Properties correspond to a restricted set of RDF Properties that relates instances of some Class of thing to a [https://www.w3.org/TR/rdf-schema/#ch_literal| literal value], (e.g. some string or integer). | ||
+ | **UML: Data Properties correspond to the attributes of some Class. | ||
== How it works == | == How it works == | ||
− | Anyone can propose a new term. Once a term has been proposed, it becomes open for the specification of [[definitions]] from the community. The administrators will review all proposed definitions and identify the [[ | + | The City Data Model Collaboratory supports the following tasks: |
+ | * '''Browse and review existing content:''' Listings of proposed terms: [[:Category:Class|classes]], [[:Category:ObjectProperty|object properties]], and [[:Category:DataProperty|data properties]] are compiled on separate pages that are accessible via the Navigation menu. Each term has its own page that contains standard content such as a description of the term, definitions, and use cases. | ||
+ | * '''Comment on existing content and suggest changes or revisions:''' At the bottom of each term page, a comments section allows users to communicate with the page authors and other members of the community. | ||
+ | * '''Propose additions:''' there are two ways to propose a new term. If an appropriate term exists in the class or property listings, you can propose a new subclass or sub-property on the appropriate page. If no such term exists, you can propose a new term. ''Authors are advised to '''protect''' (see below) any pages they create to prevent other users from editing page content directly.'' Instead, comments are encouraged via the associated Discussion pages. | ||
+ | ** [[Form:Generic_Class|Propose a new class]]. | ||
+ | ** Propose a new definition for an existing class. This option is available on each class page. | ||
+ | ** [[Form:Generic_Object_Property|Propose a new object property]] (a relationship between two classes). | ||
+ | ** Propose a new definition for an existing object property. This option is available on each object property page. | ||
+ | ** [[Form:Generic_Data_Property|Propose a new data property]]. | ||
+ | ** Propose a new definition for an existing data property. This option is available on each data property page. | ||
+ | * '''Protect created content:''' Once you've created a page, it is recommended that you protect it. That way only you and the administrators will have the ability to edit the page content directly. Each page that you have created will have a "protect" option, along with an "edit" and "edit with form" option that you can use to revise the content. | ||
+ | * [[Special:ListUsers/administrator|Contact an administrator]] if you need to follow-up on the status of a term. | ||
+ | |||
+ | == The Review Process == | ||
+ | Anyone can propose a new term. Once a term has been proposed, it becomes open for the specification of [[definitions]] from the community. The administrators will review all proposed definitions and identify the [[minimum viable definition]] for the term. The term and resulting set of definitions will then be published as approved in the City Data Model. | ||
Here's a high-level overview of the process that we follow when a new term is proposed for the City Data Model: | Here's a high-level overview of the process that we follow when a new term is proposed for the City Data Model: | ||
Line 38: | Line 69: | ||
if (Term is captured by an existing class or property?) then (yes) | if (Term is captured by an existing class or property?) then (yes) | ||
− | : | + | :Indicate redundancy in comments; |
− | if ( | + | if (Community in agreement?) then (Yes) |
:Close proposal | :Close proposal | ||
− | Term status=" | + | Term status="Closed"; |
stop | stop | ||
else(No) | else(No) | ||
Line 52: | Line 83: | ||
endif; | endif; | ||
:Term status="Pending Approval"; | :Term status="Pending Approval"; | ||
− | while (Discussion | + | while (Discussion settled?) is (No) |
:Community proposes definitions; | :Community proposes definitions; | ||
endwhile(Yes) | endwhile(Yes) | ||
− | :Admin specify | + | :Admin specify minimum viable definition; |
:Term status="Approved"; | :Term status="Approved"; | ||
:Publication of final version of term page (change protected), | :Publication of final version of term page (change protected), | ||
− | including | + | including minimum viable definition and specialized definitions; |
stop | stop | ||
Line 104: | Line 135: | ||
</uml> | </uml> | ||
− | <b>Note:</b> | + | <b>Note:</b> These diagrams were drawn using [http://plantuml.com PlantUML]. PlantUML is a handy tool that allows you to create UML (and non-UML) diagrams using simple text descriptions. It's supported by this Wiki to help you contribute more effectively. |
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 16:44, 1 June 2020
Welcome to the City Data Model Collaboration Wiki
Introduction
This website is intended to foster international collaboration between stakeholders and related standards groups on a common City Data Model. The results of this effort will feed into the various city data standards development projects being undertaken by various Standards Development Organizations.
A common data model enables city software applications to share information, plan, coordinate, and execute city tasks, and support decision making within and across city services, by providing a precise, unambiguous representation of information and knowledge commonly shared across city services. This requires a clear understanding of the terms used in defining the data, as well as how they relate to one another. Beyond syntactic integration (e.g. common data types and protocols), this requires semantic integration: a consistent, shared understanding of the meaning of information.
The City Data Model is stratified into three levels of abstraction (pictured below). The Foundation Level covers very general concepts such as Time, Location, and Activity. The City Level covers concepts that are general to cities and span all services such as Households, Services, Residents. The Service Level spans concepts commonly associated with a particular service but still shared with other services, such as Vehicles and Transportation network.
The goal of this wiki is to develop a global consensus regarding the classes, properties, and definitions that should be included in a City Data Model. This website will serve as a means of establishing this consensus through open communication and collaboration. It facilitates the sharing of suggestions, comments, and critiques. The mechanisms for these contributions are described in the sections below.
Beta Disclaimer
Please note that this is a beta version of the City Data Model Collaboratory website. The website is still undergoing testing and evaluation. Should you encounter any bugs, glitches, lack of functionality or other problems on the website, please let us know immediately so we can rectify these accordingly. Your help in this regard is greatly appreciated.
Getting started
Want to contribute? Log-in or create an account! Anyone with an account can comment on proposed or existing terms, and even propose their own.
To do: Add material on use cases.
Users can propose new terms or new definitions for existing classes, object properties, or data properties.
Note: The following descriptions focus on the meaning of the different types of terms in the context of the OWL, RDF and UML languages. While there are strong similarities between the term types, there are differences in the expressive abilities of the referenced languages. As a result, it will not always be possible to completely translate a term definition from one language to another.
- A Class is a term that is used to describe some grouping of things. Classes may be related to other classes via a notion of inheritance (subclass).
- OWL: Classes correspond to Classes as defined in OWL2.
In general classes are used to group individuals that have something in common in order to refer to them. Hence, classes essentially represent sets of individuals. In modelling, classes are often used to denote the set of objects comprised by a concept of human thinking, like the concept person or the concept woman.
--Owl2 Primer - RDF: Classes are similar to the RDF Schema classes that are used to group resources. Distinct from RDF, we do not consider other Classes or Properties to be members of a Class.
- UML: Classes correspond to UML Classes, i.e. classes in the object-oriented programming sense. Classes are objects in a system that have some predefined set of attributes and behaviour. They may also be represented with UML Class diagrams.
- OWL: Classes correspond to Classes as defined in OWL2.
- An ObjectProperty is a term that is used to describe the relationship between instances.
- OWL: Object Properties correspond to Object Properties in OWL2.
- RDF: Object Properties correspond to a restricted set of RDF Properties that only relate instances that are members of some Class(es) of things (i.e. they do not relate instances of Classes to literal values).
- UML: Object Properties correspond to the instance-level relationships (uni-directional associations) that are identified in UML Class diagrams.
- A DataProperty is a term that is used to describe the relationship between an instance and some data value.
- OWL: Data Properties correspond to Data Properties defined in OWL2.
- RDF: Data Properties correspond to a restricted set of RDF Properties that relates instances of some Class of thing to a literal value, (e.g. some string or integer).
- UML: Data Properties correspond to the attributes of some Class.
How it works
The City Data Model Collaboratory supports the following tasks:
- Browse and review existing content: Listings of proposed terms: classes, object properties, and data properties are compiled on separate pages that are accessible via the Navigation menu. Each term has its own page that contains standard content such as a description of the term, definitions, and use cases.
- Comment on existing content and suggest changes or revisions: At the bottom of each term page, a comments section allows users to communicate with the page authors and other members of the community.
- Propose additions: there are two ways to propose a new term. If an appropriate term exists in the class or property listings, you can propose a new subclass or sub-property on the appropriate page. If no such term exists, you can propose a new term. Authors are advised to protect (see below) any pages they create to prevent other users from editing page content directly. Instead, comments are encouraged via the associated Discussion pages.
- Propose a new class.
- Propose a new definition for an existing class. This option is available on each class page.
- Propose a new object property (a relationship between two classes).
- Propose a new definition for an existing object property. This option is available on each object property page.
- Propose a new data property.
- Propose a new definition for an existing data property. This option is available on each data property page.
- Protect created content: Once you've created a page, it is recommended that you protect it. That way only you and the administrators will have the ability to edit the page content directly. Each page that you have created will have a "protect" option, along with an "edit" and "edit with form" option that you can use to revise the content.
- Contact an administrator if you need to follow-up on the status of a term.
The Review Process
Anyone can propose a new term. Once a term has been proposed, it becomes open for the specification of definitions from the community. The administrators will review all proposed definitions and identify the minimum viable definition for the term. The term and resulting set of definitions will then be published as approved in the City Data Model.
Here's a high-level overview of the process that we follow when a new term is proposed for the City Data Model:
<uml> @startuml title Proposing a New Term for the CDM
start
- Specify the name of the new class or property;
- Provide a natural language description of new term;
- New term page created
Term status="Proposed";
- Community review;
if (Term is captured by an existing class or property?) then (yes)
:Indicate redundancy in comments; if (Community in agreement?) then (Yes) :Close proposal Term status="Closed"; stop else(No) while (undecided) is (Yes) :Discuss; :Editorial review; endwhile(No); endif; else(No) endif; :Term status="Pending Approval"; while (Discussion settled?) is (No) :Community proposes definitions; endwhile(Yes) :Admin specify minimum viable definition; :Term status="Approved"; :Publication of final version of term page (change protected), including minimum viable definition and specialized definitions;
stop
@enduml </uml>
<uml> @startuml title Submitting a definition for a proposed term
start
- Navigate to proposed term page;
- Select "Add Definition";
- Specify description of specialized term
What distinguishes this definition of the term?;
- Specify use case(s)
Why is this specialized definition needed?;
- Specify specialized definition in UML and DL
If DL is not sufficient, supplement with SWRL or SHACL;
- Publish for review
Specialized definition status="Pending Approval";
- Community reviews proposal;
- Users suggest revisions/additions to definition (properties, constraints), use cases;
if (Owner accommodates suggestions?) then (Yes)
:Comment resolved;
else(No)
:Comment left unresolved;
endif;
- Editorial review;
:Editorial comments to author; :Author revisions; :Final review; :Specialized definition status="Approved" (change protected);
stop
@enduml </uml>
Note: These diagrams were drawn using PlantUML. PlantUML is a handy tool that allows you to create UML (and non-UML) diagrams using simple text descriptions. It's supported by this Wiki to help you contribute more effectively.