Ontologies for Smart Cities

LD4SC Summer School 7th -‐ 12th June, Cercedilla, Spain


Ontologies for Smart Ci?es

Oscar Corcho, María Poveda Villalón, Asunción Gómez Pérez, Filip Radulovic, Raúl García Castro

UPM



What is an ontology?

We may also call them “vocabularies”, “shared informa?on models”

or “shared data structures”


Ontologies •  What is an Ontology

–  “An ontology is a formal, explicit specifica9on of a shared conceptualiza9on”. [Studer, Benjamins, Fensel. Knowledge Engineering: Principles and Methods. Data and Knowledge Engineering. 25 (1998) 161-‐197]

•  Components •  Types:

–  Lightweight/heavyweight –  Applica?on/Domain/General

•  What are they for –  Describe a domain –  Data integra?on –  Reasoning –  …

•  Languages: –  OWL Web Ontology Language, RDF Schema

Ontology

Instances

Knowledge Level

Data Level

ConceptsTaxonomies

RelationsAttributesAxioms

Instances of concepts Instances of relationsInstances of attributes


Mo?va?on

4

Create terms (if needed)

Put them all together

4

“Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch. hep://lod-‐cloud.net/”

My Data Set

My namespace

Vocabulary describing my data

Generate RDF

Publish my DataSet

Reuse terms from LOD cloud

ºC

kWh

mt

F

K m3

Developing Ontologies for Representing Data about Key Performance Indicators – María Poveda Villalón



How to develop an ontology?


What is Ontological Engineering?

It refers to the set of activities that concern:

•  the ontology development process,

•  the ontology life cycle,

•  the methods and methodologies for building ontologies,

•  the tools and tool suites

•  and the languages that support them


Ontology development

[1] Suárez-‐Figueroa, M.C. PhD Thesis: NeOn Methodology for Building Ontology Networks: SpecificaAon, Scheduling and Reuse. Spain. June 2010.

Activity definition taken from [1]

6. Ontologyimplementation

5. Ontology selection

1. Requirements definition

Can you represent all your data?

7. Ontology evaluation

2. Terms extraction

3. Ontology conceptualization

4. Ontology search

6.2 Ontology completion

3.1 Initial model drafting

3.2 Detailed model definition

6.1 Ontology integration

Focus of each activity

Existing tools to carry out the activity

Tips, alternatives and references

7


1. Requirements defini?on Ontology Requirements: refers to the activity of collecting the requirements that the ontology should fulfil (for example, reasons to build the ontology, identification of target groups and intended uses). (NeOn)






2. Terms extraction


4. Ontology search





8

Proposed references: -  NeOn Guidelines for non functional

requirements. -  Competency Questions technique [1]

Tools: mind map, text editor, etc

[1] Gruninger, M., Fox, M. S. The role of competency quesAons in enterprise engineering. In Proceedings of the IFIP WG5.7 Workshop on Benchmarking -‐ Theory and Prac?ce, Trondheim, Norway, 1994.


Ontology development – LCC example






2. Terms extraction


4. Ontology search





LCC example (Data from Leeds City Council energy consump?on)

Non func?onal requirements specified: •  The ontology will try to adopt concepts and design

paeerns in other ontologies where possible •  The ontology should be implemented in OWL 2 DL

9

Func?onal requirements (Competency Ques9ons): •  What was the average electricity consump?on in

2014 by district in Leeds?


2. Terms extrac?on Ontology term extraction to extract a glossary of terms that may be developed.

Tools for terminology extraction: •  Identify nouns, verbs, etc.

•  Tools: Freeling for free text






2. Terms extraction


4. Ontology search





Focus: •  Extract terminology from Competency Questions (NeOn) •  Extract terminology directly from the data

•  Expert advise || Done by experts

10

Complete the list with synonyms








2. Terms extraction


4. Ontology search





Site place

Address

PostCode

Electricity Consumption, u?liza?on

years

time

11

What was the average electricity consump?on in 2014 by district in Leeds?


3. Ontology conceptualiza?on Ontology conceptualization refers to the activity of organizing and structuring the information (data, knowledge, etc.), obtained during the acquisition process, into meaningful models at the knowledge level and according to the ontology requirements specification document. (NeOn)






2. Terms extraction


4. Ontology search




6.1 Ontology integration Drawing tools, including paper and pencil

Focus drafting (optional): •  Identify main domains and top concept •  Establish relations between concepts and domains

Focus detail model: •  Establish hierarchies •  Establish specific relationships among defined

elements, rules, axioms, etc.

12

Do not try to define everything. You might change your mind during the implementation.








2. Terms extraction


4. Ontology search





Council(site(

Consump.on(related(to(council(site(

Time(

has(.me(period(

Council(site

Has(address(

Address

Has(value(

Observa4on

Value

SensorOutput

Observa4on(result(

About(council(

Council(site(

Consump4on(

In(city(

City

District

Is(in(district(

Place

Is(a(

13


4. Ontology search Ontology search refers to the activity of finding candidate ontologies or ontology modules to be reused (NeOn).






2. Terms extraction


4. Ontology search





Search tools: •  General purpose:

•  LOV: http://lov.okfn.org •  Google, Swoogle, Watson •  Others: ODP Portal http://ontologydesignpatterns.org

•  Domain base: •  Smart cities: http://smartcity.linkeddata.es/

Focus: •  Terms already used in LOD •  Save time and resources •  Increase interoperability

Use domain terms and synonyms

Do not spend too much time trying to find terms

for everything. You might need to create them.

14








2. Terms extraction


4. Ontology search





15


5. Ontology selec?on Ontology Selection refers to the activity of choosing the most suitable ontologies or ontology modules among those available in an ontology repository or library, for a concrete domain of interest and associated tasks. (NeOn)

Evaluation tools: •  OOPS! – OntOlogy pitfalls scanner [1]

http://oops.linkeddata.es/ •  Triple checker http://graphite.ecs.soton.ac.uk/checker/

(already included in OOPS!) •  Vapour http://validator.linkeddata.org/vapour (to be included

in OOPS!) Also it should be considered:

•  Modelling issues (OOPS!, reasoners, manually review, etc.) •  Domain coverage (based on the data to be represented) •  Used in Linked Data (LOD2Stats, Sindice, etc)

Focus: •  Assessment by Linked Data principles •  Modelling issues •  Domain coverage: data driven

[1] Poveda-‐Villalón, M., Gómez-‐Pérez, A., & Suárez-‐Figueroa, M. C. (2014). Oops!(ontology pitall scanner!): An on-‐line tool for ontology evalua?on. InternaAonal Journal on SemanAc Web and InformaAon Systems (IJSWIS), 10(2), 7-‐34.






2. Terms extraction


4. Ontology search





Further reference: NeOn Guidelines

16








2. Terms extraction


4. Ontology search





•  Domain coverage •  Schema.org for public places and provides some

addi?onal terms and proper?es that can be used(e.g., PostalAddress and City)

•  Also widely-‐known and accepted vocabulary à interoperability

•  Closer seman9cs •  ero:FinalEnergy class from the Energy Resource and

the ssn:Property class from the SSN ontology in order to represent specific indicator for which the consump?on is related to

17


6. Ontology implementa?on. Integra?on

Ontology Integration. It refers to the activity of including one ontology in another ontology. (NeOn)

Tools: •  Ontology editors: Protégé, NeOn Toolkit, etc.

•  Plug-ins: Ontology Module Extraction and Partition •  Text editors for manual approach

Focus: •  How much information should I reuse? •  How to reuse the elements or vocabs?

•  Should I import another ontology? •  Should I reference other ontology element URIs?

•  ... replicating manually the URI? •  ... merging ontologies?

•  How to link them?

Techniques: •  Import the ontology as a whole •  Reuse some parts of the ontology (or ontology module) •  Reuse statements






2. Terms extraction


4. Ontology search





18


6. Ontology implementa?on. Extension Ontology Enrichment It refers to the activity of extending an ontology with new conceptual structures (e.g., concepts, roles and axioms). (NeOn)

Focus: •  How should I create terms according to ontological foundations

and Linked Data principles?

Ontology development: •  Ontology Development 101: A Guide to Creating Your First

Ontology [1] •  Ontology Engineering Patterns http://www.w3.org/2001/sw/

BestPractices/ •  Extracting ontology conceptualization, formalization

techniques from existing methodologies Recommendation

•  Link to existing entities •  Provide human readable documentation •  Keep the semantics of the reused elements

[1] Natalya F. Noy and Deborah L. McGuinness. Ontology Development 101: A Guide to CreaAng Your First Ontology’. Stanford Knowledge Systems Laboratory Technical Report KSL-‐01-‐05 and Stanford Medical Informa?cs Technical Report SMI-‐2001-‐0880, March 2001.

Tools: •  Ontology editors: Protégé, NeOn Toolkit, etc.






2. Terms extraction


4. Ontology search





19


time:Interval

schema:City

ssn:Observation

ssn:observationSamplingTime

ssn:SensorOutput

ssn:ObservationValue

ssn:hasValue

ssn:FeatureOfInterest

ssn:featureOfInterest

lcc:hasQuantityValue :: xsd:decimal ssn:Property

ero:FinalEnergy

ssn:observedProperty

ssn:observationResult

LegendClassdatatype property :: datatype

object property subclass of relation

schema:CivicStructurelcc:uprn :: xsd:Stringdc:title :: xsd:String

schema:PostalAddressschema:addressLocality :: xsd:Stringschema:addressRegion :: xsd:Stringschema:streetAddress :: xsd:Stringschema:postalCode :: xsd:String

schema:address

admingeo:District

admingeo:district

time:Instanttime:inXSDDateTime :: xsd:dateTime

time:hasBeginningtime:hasEnd

ero:EnergyConsumerFacility

ero:consumesEnergyType

om:Unit_of_measure

lcc:hasQuantityUnitOfMeasurement

SupplyOrStorageSite

OpenAirSite

AccomodationSite AdministrativeSite

OfficeSite

EducationalSite

SocialSite

OtherSite

CulturalSite

schema:containedIn

schema:Place

schema:AdministrativeAreaLeisureSite







2. Terms extraction


4. Ontology search





20


Ontology evalua?on Ontology Evaluation it refers to the activity of checking the technical quality of an ontology against a frame of reference. (NeOn)

Evaluation tools related to Linked Data principles: •  OOPS! – OntOlogy pitfalls scanner [1]

http://oops.linkeddata.es/ •  Triple checker http://graphite.ecs.soton.ac.uk/checker/

(already included in OOPS!) Evaluation tools/techniques other aspects:

•  Modelling issues (OOPS!, reasoners, manually review, etc.) •  Domain coverage (based on the data to be represented) •  Application based (queries) •  Syntax issues: validators

Focus: •  Assessment by Linked Data principles •  Modelling issues •  Domain coverage: data driven

[1] Poveda-‐Villalón, M., Gómez-‐Pérez, A., & Suárez-‐Figueroa, M. C. (2014). Oops!(ontology pitall scanner!): An on-‐line tool for ontology evalua?on. InternaAonal Journal on SemanAc Web and InformaAon Systems (IJSWIS), 10(2), 7-‐34.






2. Terms extraction


4. Ontology search





21



Minor, mostly lack of

annotations in reused

terms.






2. Terms extraction


4. Ontology search





22

hep://oops.linkeddata.es/



OWL

Web Ontology Language


Approaches for building ontologies UML

Frames & Logic

Subclass of Mammal …

Subclass of

Birds

Subclass of

Subclass of Subclass of

Design time

Dog Cat

Description logic

Mammal ….

….

dog Birds

Cat

Automatic Classification

E/R Model


Lassila and McGuiness Classifica?on (I)

Catalog/ID

Thessauri “narrower term”

relation Formal

is-a Frames

(properties)

General Logical

constraints

Terms/ glossary

Informal is-a

Formal instance

Value Restrs.

Disjointness, Inverse, part-

Of ...

Lassila O, McGuiness D. The Role of Frame-Based Representation on the Semantic Web. Technical Report. Knowledge Systems Laboratory. Stanford University. KSL-01-02. 2001.


Lassila and McGuiness Classifica?on (II) Catalog/ID Thesaurus Glossary Informal is-a

Informal is-a

Types of relationships

Thesaurus

Catalog/ID

Informal is-a


Lassila and McGuiness Classifica?on (III) Formal is-a Frames (properties) General

Logical constraints

Formal instance Value Restrs.

Disjointness, Inverse, part-

Of ... Formal is-a with

properties (define-relation connects (?edge ?source ?target) "This relation links a source and a target by an edge. The source and destination are considered as spatial points. The relation has the following properties: symmetry and irreflexivity." :def (and (SpatialPoint ?source) (SpatialPoint ?target) (Edge ?edge)) :axiom-def ((=> (connects ?edge ?source ?target) (connects ?edge ?target ?source)) ;symmetry (=> (connects ?edge ?source ?target) (not (or (part-of ?source ?target) ;irreflexivity (part-of ?target ?source))))))

General Logical

constraints

(define-class AmericanAirlinesFlight (?X) :def (Flight ?X) :axiom-def (Disjoint-Decomposition AmericanAirlinesFlight (Setof AA7462 AA2010 AA0488))) (define-class Location (?X) :axiom-def (Partition Location (Setof EuropeanLocation NorthAmericanLocation SouthAmericanLocation AsianLocation AfricanLocation AustralianLocation AntarcticLocation)))

Disjointness

(define-class Travel (?travel) "A journey from place to place" :axiom-def (and (Superclass-Of Travel Flight) (Template-Facet-Value Cardinality arrivalDate Travel 1) (Template-Facet-Value Cardinality departureDate Travel 1) (Template-Facet-Value Maximum-Cardinality singleFare Travel 1)) :def (and (arrivalDate ?travel Date) (departureDate ?travel Date) (singleFare ?travel Number) (companyName ?travel String)))

Value Restrs.


OWL and Description Logics

•  Automatic classification, done by the inference engine, at run-time

Living Being Invertebrate

Vertebrate

Dog

Plant

Cat

Automatic Classification

Subclass of

Living Being

Vertebrate Invertebrate

Subclass of

Plant

Subclass of

Subclass of Subclass of

Design time

Dog Cat


What is Description Logic?

•  A family of logic-based Knowledge Representation formalisms –  Descendants of semantic networks and KL-ONE –  Describe domain in terms of concepts (classes), roles (relationships) and

individuals •  Specific languages characterised by the constructors and axioms used to assert

knowledge about classes, roles and individuals. •  Example: ALC (the least expressive language in DL that is propositionally closed)

–  Constructors: boolean (and, or, not) –  Role restrictions

•  Distinguished by: –  Formal semantics (model theoretic) –  Decidable fragments of FOL –  Provision of sound, complete and optimised inference services


Structure of DL Ontologies

•  A DL ontology can be divided into two parts: –  Tbox (Terminological KB): a set of axioms that describe the structure of

a domain : •  Doctor ⊆ Person •  Person ⊆ Man ∪ Woman •  HappyFather ⊆ Man ∩ ∀hasDescendant.(Doctor ∪ ∀hasDescendant.Doctor)

–  Abox (Assertional KB): a set of axioms that describe a specific situation : •  John ∈ HappyFather •  hasDescendant (John, Mary)

– Other terms that have been used: •  RBox •  EBox (extensional box)


DL constructors

≥3 hasChild, ≤1 hasMother {Colombia, Argen?na, México, ...} à MercoSur countries hasChild-‐ (hasParent) ≤2 hasChild.Female, ≥1 hasParent.Male Other:

Concrete datatypes: hasAge.(<21) Transi?ve roles: hasChild* (descendant) Role composi?on: hasParent o hasBrother (uncle)


Most common constructors in class definitions

•  Intersection: C1 ∩ ... ∩ Cn Human ∩ Male •  Union: C1 ∪ ... ∪ Cn Doctor ∪ Lawyer •  Negation: ¬C ¬Male •  Nominals: {x1} ∪ ... ∪ {xn} {john} ∪ ... ∪ {mary} •  Universal restriction: ∀P.C ∀hasChild.Doctor •  Existential restriction: ∃P.C ∃hasChild.Lawyer •  Maximum cardinality: ≤nP ≤3hasChild •  Minimum cardinality: ≥nP ≥1hasChild •  Specific Value: ∃P.{x} ∃hasColleague.{Matthew}

•  Nesting of constructors can be arbitrarily complex –  Person ∩ ∀hasChild.(Doctor ∪ ∃hasChild.Doctor)

•  Lots of redundancy –  A∪B is equivalent to ¬(¬ A ∩ ¬B) –  ∃P.C is equivalent to ¬∀P. ¬C


Most common axioms •  Classes

–  Subclass C1 ⊆ C2 Human ⊆ Animal ∩ Biped –  Equivalence C1 ≡ C2 Man ≡ Human ∩ Male –  Disjointness C1 ∩ C2 ⊆ ⊥ Male ∩ Female ⊆ ⊥

•  Properties/roles –  Subproperty P1 ⊆ P2 hasDaughter ⊆ hasChild –  Equivalence P1 ≡ P2 cost ≡ price –  Inverse P1 ≡ P2- hasChild ≡ hasParent-

–  Transitive P+ ⊆ P ancestor+ ⊆ ancestor –  Functional Τ ⊆ ≤1P T ⊆ ≤1hasMother –  InverseFunctional Τ ⊆ ≤1P- T ⊆ ≤1hasPassportID-

•  Individuals –  Equivalence {x1} ≡ {x2} {oeg:OscarCorcho} ≡ {img:Oscar} –  Different {x1} ≡ ¬{x2} {john} ≡ ¬{peter}

•  Most axioms are reducible to inclusion (∪) –  C ≡ D iff both C ⊆ D and D ⊆ C –  C disjoint D iff C ⊆ ¬D


Description Logics

Understand the meaning of universal and existential restrictions - Decide which is the set that we are defining with different expressions, taking into account Open and Close World Assumptions


Do we understand these constructors?

•  ∃hasColleague.Lecturer •  ∀hasColleague.Lecturer •  ∃hasColleague.{Oscar}

Oscar

Lecturer

hasColleague

hasColleague hasColleague

hasColleague

hasColleague

hasColleague

hasColleague hasColleague


Formalisation. Some basic DL modelling guidelines

•  X must be Y, X is an Y that... à X ⊆ Y •  X is exactly Y, X is the Y that... à X ≡ Y •  X is not Y (not the same as X is whatever it is not Y) à X ⊆ ¬Y •  X and Y are disjoint à X ∩ Y ⊆ ⊥ •  X is Y or Z à X ⊆Y∪Z •  X is Y for which property P has

only instances of Z as values à X ⊆ Y ∩ (∀P.Z) •  X is Y for which property P has at

least an instance of Z as a value à X ⊆ Y ∩ (∃P.Z) •  X is Y for which property P has at

most 2 values à X ⊆ Y∩ (≤ 2.P) •  Individual X is a Y à X∈Y


Exercise. Formalize in DL, and then in OWL DL

1. Concept defini?ons: –  Neighbourhoods and city districts are two different types of city territorial

divisions –  Social ac?vi?es are always run in one or several community centers. –  A sport ac?vity is a city ac?vity that is run only in sport centers. –  A city district has at least a community center, and every community center

belongs to a district. –  Neighbourhoods are parts of a city, but there are other parts of a city that are

not neighbourhoods. –  An empty ac?vity is a social ac?vity that is run in a community center that does

not belong to any district. 2. Individuals:

–  Waterloo is a district. –  Nozng Hill is a neighbourhood and has a sport center “XX”. –  Elephant and Castle


Inference. Basic Inference Tasks •  Subsumption – check knowledge is correct (captures intuitions)

–  Does C subsume D w.r.t. ontology O? (in every model I of O, CI ⊆ DI ) •  Equivalence – check knowledge is minimally redundant (no unintended

synonyms) –  Is C equivalent to D w.r.t. O? (in every model I of O, CI = DI )

•  Consistency – check knowledge is meaningful (classes can have instances) –  Is C satisfiable w.r.t. O? (there exists some model I of O s.t. CI ≠ ∅ )

•  Instantiation and querying –  Is x an instance of C w.r.t. O? (in every model I of O, xI ∈ CI ) –  Is (x,y) an instance of R w.r.t. O? (in every model I of O, (xI,yI) ∈ RI )

•  All reducible to KB satisfiability or concept satisfiability w.r.t. a KB •  Can be decided using tableaux reasoners


What are we going to do?

Specification

Modelling

Generation Publication

Exploitation

Linking

39

For the week


Preparing the hands-‐on

•  Goal: to create hand-‐on groups •  Sign up for a dataset

– Sheet with datasets are available in the main room (with sofas)

•  Restric?ons for crea?ng groups –  3-‐4 members –  At least 1 computer scien?st

•  If your group does not meet the restric?on you need to join another group

40


Final presenta?on

•  Friday: group projects presenta?ons •  5 slides per group •  Summarize the work you have done during the week – Par?cipa?on of all members – Work quality – Presenta?on – Fun – …

•  Prize for the best group! 41



Task 1 1.  Extract requirements

•  Competency ques?ons •  Data analysis

2.  Vocabulary conceptualiza?on 3.  Start with the implementa?on (Protégé)

For today


Hands-‐on task 1 -‐ Deliverables

•  An document lis?ng – The competency ques?ons – List of terms and rela?onships – Conceptualiza?on (drawing)

•  OWL file with ontology implementa?on

43 43


DATA LEVEL

MODEL LEVEL

Nota?on

Concept A Concept B

Concept A1

Concept A2 <<subClassOf>>

aeribute:: datatype

rela?onship

Rela?on between two individuals à object property or just “rela?onship” Rela?on between one individual and one value à aeribute

Instance 1 <<type>>

Instance 2 rela?onship

Value^^datatype aeribute

<<type>>

Science

Ontologies for Smart Cities