Skip to content

Latest commit

 

History

History
123 lines (84 loc) · 8.56 KB

MIRO Evaluation.md

File metadata and controls

123 lines (84 loc) · 8.56 KB

MIRO Evaluation for the SBEO: Smart Building Evacuation Ontology

We here report the documentation for the SBEO according to the guidelines available in [1].

A. Basics

  1. Ontology name (MUST) Smart Building Evacuation Ontology (SBEO), version 0.4.

  2. Ontology owner (MUST) Qasim Khalid

  3. Ontology license (MUST) GNU General Public License v3.0

  4. Ontology URL (MUST) https://github.com/qasimkhalid/SBEO/blob/master/sbeo.owl

  5. Ontology repository (MUST) https://github.com/qasimkhalid/SBEO

  6. Methodological framework (MUST) The ontology defined the needed concepts to create a real-time context aware route recommendations during both everday use and emergency conditions by introducing the namespaces sbeo, and connecting them to well-known ontologies like SEAS, FOAF, SOSA and OLO.

B. Motivation

  1. Need (MUST) Real-time context-aware route recommendation system in indoor envrionments during emergencies especially for groups; families having kids or people with impairments, is still an unexplored field that at the moment lacks of semantic representation.

  2. Competition (MUST) There are some ontolgies such as, ONALIN [2], ONTONAV [3], INO and UNO [4], that described the context-aware route recommendation, but all of them have not described the concepts to represent the groups as well as none of them is available on internet.

  3. Target audience (MUST) As the proposed ontology is verstile in nature, therefore the individuals who design the applications where safety and equanimity of people are important such as emergency management, emergency response, recommendation of routes, context awareness, hazard detection, management of groups of people, and so forth, can use this ontology.

C. Scope, requirements, development community

  1. Scope and coverage (MUST) This ontology that couples the information about any building with its occupants such that it can be used in many useful ways. For example, indoor localization of people, detection of any hazard, a recommendation of normal routes such as shopping or stadium seating routes, or safe and feasible emergency evacuation routes or both of them all together. The ontology covers the concepts related to the geometry of building, devices and components of the building, route graphs correspondent to the building topology, users’ characteristics and preferences, situational awareness of both building (hazard detection, status of routes in terms of availability and occupancy) and users (tracking, management of groups, status in terms of fitness), and emergency evacuation.

  2. Development community (MUST)

  • Centre for Intelligent Information Technologies (CETINIA) of Universidad Rey Juan Carlos, Spain.
  • Centre d’Enseignement de Recherche et d’Innovation (CERI) Sciences et Technologie du Num´erique, IMT Nord Europe, France.
  1. Communication (MUST) Issues on Github.

D. Knowledge acquisition

  1. Knowledge acquisition method (MUST) Analysis of the available literature on Semantic Web, ontologies and IoT. In particular, how to represent persons with different physical characteristics, buildings, routes, context, devices and their components. Competency questions on the relevant domain.

  2. Source knowledge location (SHOULD) Competency Questions

  3. Content Selection (SHOULD) It includes the semantics of persons along with their physical characteristics and routes preferences, groups, building structure, routes, activities and events.

E. Ontology content

  1. Knowledge representation language (MUST) OWL 2 generated by Protégé v5.5.0; however, the ontology is at this stage only descriptive, and it uses a reduced subset of OWL 2 capabilities, being the Description Logic SHOIQ(D) [5-6].

  2. Development environment (OPTIONAL) Protégé v5.5.0.

  3. Ontology metrics (SHOULD) Number of classes: 191; number of object properties: 52; number of data properties: 31; number of individuals: 33.

  4. Incorporation of other ontologies (MUST) SEAS, SOSA, OLO, FOAF.

  5. Entity naming convention (MUST) Entities follows the CamelCase notation. Both datatype and object properties are named as verb senses with mixedCase notation.

  6. Identifier generation policy (MUST) Identifiers of the instances must be generated by the application.

  7. Identity metadata policy (MUST) All entities have an rdfs:comment and rdfs:label natural language explanation.

  8. Upper ontology (MUST) There is no upper ontology used in the development of this ontology. But we have reused various concepts from different exisiting ontologies. See point E.4.

  9. Ontology relationships (MUST) 52 object properties; 33 datatype properties.

1488 axioms included (of which 475 logical axioms, 320 declaration axioms, 267 SubClassOf, 5 Equivalent Classes, 2 Hidden GCI, 3 Inverse Object Properties, 3 Functional Object Properties, 2 Inverse Functional Object Property, 3 Transitive Object Properties , 5 Symmetric Object Properties, 52 Object Property Domain and 51 Object Property Range, 1 Disjoint Data Property, 14 Functional Data Property, 31 Data Property Domain and 24 Data Property Range, and 693 Annotation Assertions).

  1. Deferencable URI (OPTIONAL)
  2. Axiom pattern (MUST) It is possible to use deferencable URIs, but no assumption on this is made in the ontology.

F. Managing change

  1. Sustainability plan (MUST) Some research projects are being prepared to leverage the ontology.

  2. Entity deprecation strategy (MUST) Deprecated classes will be labelled as obsolete with a proper annotation property.

  3. Versioning policy (MUST) The SBEO adopts sequence-based identifiers for its versions with a major number and a minor number, separated by a dot. A novel release featuring only small changes will cause a switch of the minor number, while relevant and/or structural changes affects also the major number.

G. Quality assurance

  1. Testing (MUST) Tests have been made by checking competency questions and formal requirements in the presentation paper. Once published, it will be available here.

  2. Evaluation (MUST) Metrics, and discussions over SBEO evaluation have been discussed in the description document.

  3. Examples of use (MUST) At the moment, there is only one theoretical example of usage in the description document.

  4. Institutional endorsement (OPTIONAL) None

  5. Evidence of use (MUST) The ontology is used in development of Context-AwaRe Emergency Evacuation (CAREE) software. The details can be found here. Moreover, we also plan to use it in forthcoming projects.

References

[1] Matentzoglu, N., Malone, J., Mungall, C., & Stevens, R. (2018). MIRO: guidelines for minimum information for the reporting of an ontology. Journal of biomedical semantics, 9(1), 6.

[2] Dudas, P.M., Ghafourian, M. and Karimi, H.A., 2009, May. ONALIN: Ontology and algorithm for indoor routing. In 2009 Tenth International Conference on Mobile Data Management: Systems, Services and Middleware (pp. 720-725). IEEE.

[3] Anagnostopoulos, C., Tsetsos, V. and Kikiras, P., 2005. OntoNav: A semantic indoor navigation system. In 1st Workshop on Semantics in Mobile Environments (SME05), Ayia.

[4] Kikiras, P., Tsetsos, V. and Hadjiefthymiades, S., 2006, August. Ontology-based user modeling for pedestrian navigation systems. In ECAI 2006 Workshop on Ubiquitous User Modeling (UbiqUM), Riva del Garda, Italy (pp. 1-6).

[5] Horrocks, I., Patel-Schneider, P.F. and Van Harmelen, F., 2003. From SHIQ and RDF to OWL: The making of a web ontology language. Journal of Web Semantics, 1(1), pp.7-26.

[6] Tsarkov, D. and Horrocks, I., 2006, August. FaCT++ description logic reasoner: System description. In International joint conference on automated reasoning (pp. 292-297). Springer, Berlin, Heidelberg.