You are on page 1of 64

IS707: Applications of Intelligent

Technologies

Spring 2022

1
Today’s Agenda
Mini-quiz (10 mins)
No mini-quiz next week
Project Presentation & Final Report(next Thursday)
Semantic Web
Paper presentations
 The Semantic Web: Use of Semantic Technologies to Inform Progress
Toward Zero-Carbon Economy
 Semantic Web: Modeling and Analysis of User Behavior in Online
Communities
Today’s Agenda
Mini-quiz (10 mins)
No mini-quiz next week
Project Presentation & Final Report(next Thursday)
Semantic Web
Paper presentations
 The Semantic Web: Use of Semantic Technologies to Inform Progress
Toward Zero-Carbon Economy⋆
 Semantic Web: Modeling and Analysis of User Behavior in Online
Communities
Project Presentation
Will be on Blackboard Collaborate course room
Presentation Format
Presentation time (total 13 mins for each team)
◦ Presentation: 10 mins (including demo)
◦ Q&A: 3 mins
◦ You may have multiple presenters in each team (all should be
involved), but only one person will flip the slides (I will make the
person a presenter)
◦ Send the slides to me 30 mins before the class so that I can uploaded
them to Blackboard Collaborate ahead of time (to make sure the
transition is smooth)
Project Presentation (cont.)
Main Evaluation Criteria
◦ Content organization and flow of the presentation
◦ Clarity of the explanation (explaining the motivation,
methods, results and main takeaways)
◦ Quality of the slides (e.g., density of the slides and
multimedia use)
◦ Time Management (e.g., finish presentations in ~10
mins, please rehearse)
◦ Q&A quality (able to answer questions from students &
instructor)
Project Final Report
Length:  minimum 1500 words , only word/pdf files acceptable
Suggested outline
  Abstract    
  Introduction
      Problem statement:  what problem do you want to solve
      Motivation: why the problem is important to solve
      Main challenges: why the problem is none-trivial 
 Existing/related work: what has been done before
 Proposed solution:
 system overview/architecture
 method description
 dataset description (if applicable)
 implementation details (e.g., parameter settings, train/eval. data split)
 Evaluation: how do we know your solution is good?
 Baselines (what is the performance of prior solutions)
 Evaluation measures
 Evaluation results
 Summary of work/limitations/main takeaways
Project Final Report: Evaluation Criteria
Importance of the chosen topic/problem
Why people should care

Complexity/difficulty of the chosen topic/problem


Soundness of the proposed solution/method
Soundness of the evaluation
Quality of the results
Quality of writing (in terms of both clarity and
grammaticality)
Today’s Agenda
Mini-quiz (10 mins)
No mini-quiz next week
Project Presentation & Final Report(next Thursday)
Semantic Web
Paper presentations
 The Semantic Web: Use of Semantic Technologies to Inform Progress
Toward Zero-Carbon Economy⋆
 Semantic Web: Modeling and Analysis of User Behavior in Online
Communities
The Current Web

Distributed hypertext/hypermedia
Information accessed via keyword-based
search and browse
Browser renders information for human
consumption
What is the Problem?
• Markup language (e.g.,
html) consists of:
– rendering information
(e.g., font size and
colour)
– Hyper-links to related
content
• Web content is accessible
to humans, but not
(easily) to computers
– Text, images and videos …
What is the Semantic Web?
Was “invented” by Tim Berners-Lee (amongst others), a
physicist working at CERN
His vision of the Semantic Web:

“… a set of connected applications … forming a


consistent logical web of data …”

“… an extension of the current web in which


information is given well-defined meaning,
better enabling computers and people to work
in cooperation …”
Vision of the Semantic Web
Design of technologies that support machine
facilitated global knowledge exchange.
Provide the enabling infrastructure for
application data integration on the web.
Focused on machine consumption
Vision of the Semantic Web
In the depicted scenario,
Lucy's agent tracks down a
physical therapy clinic for
her mother that meets a
combination of criteria and
has open appointment
times that mesh with her
and her brother Pete's
schedules. Ontologies that
define the meaning of
semantic data play a key
role in enabling the agent
to understand what is on
the Semantic Web, interact
with sites and employ
other automated services.
How does Semantic Web Achieve the
Goal?

Essence
Bring structure to the meaningful content of
web pages
to create machine-processible information –
realize the real power of the Web
Use structured collection of information
and sets of inference rules to conduct
automated reasoning
Enabling Technologies
Ontology
Knowledge Representation Language
Query Language
Ontology
Defines the kinds of things that exist in the
application domain/world
Explicit specification of a conceptualization
(Gruber 1993):
Formal  machine consumable
Explicit  facilitate knowledge extraction and reasoning
Shared conceptualization  facilitate system-system
communication/integration
An ontology should:
Capture a shared understanding of a domain of interest
Provide a formal and machine manipulable model
Benefits of Ontology
Shared vocabulary (for humans and
autonomous agents)
Shared common understanding of the
structure of information
Reuse of domain/world knowledge
to avoid “re-inventing the wheel”
Benefits of Ontology (cont.)
Assumptions become explicit enabling
Explaining assumptions
Support for evolving systems where time and
situations change necessitating re-evaluation of
assumptions
Support for interoperation with other (potentially
legacy) systems
Separation of types of knowledge:
Declarative knowledge vs procedural knowledge
Background (unchanging) knowledge from changing
information
A Simple Ontology Example

Instance of
Calendar Meeting with
Cindy
Event

Has Has
Day
Day-of-week Second
Month Date Time Minute
Quarter Hour
Year
An Ontology Example with Concept
Hierarchy: E-Commerce
Service

Shipping Purchase

AirShipping BoatShipping BuyTicket BuyBook

TruckShipping

AcmeTruckShipping BuyAirTicket CongoBuyBook

BuyConcertTicket AmazonBuyBook
Ontology Development
Define concepts in the domain (classes)
Identify subclass/superclass relationships
(thereby defining a class hierarchy).
Identify attributes/properties /slots
Restrict attribute/property values
Define instances
Define interrelationships between
instances
Determine the scope of the domain
22

Example: Developing a Wine Ontology


Main vocabulary:
wine, grape, winery, location,
wine color, wine body, wine flavor, sugar
content
white wine, red wine, Bordeaux wine
food, seafood, fish, meat, vegetables, cheese
23

Define Classes and the Class Hierarchy


A class is a concept in the domain
a class of wines
a class of wines from a particular region (burgundies)

A class is a collection of elements with some


similar properties
A class contains necessary conditions for
membership (made from a wine grape, alcohol
content > xx percent)
Instances of classes
A particular bottle of wine in your wine cellar
24

Class Inheritance
Classes are organized into a subclass-superclass
(or generalization-specialization) hierarchy
True subclass relationships are the basis of the
formal IS-A hierarchy
Classes are “is-a” related if an instance of the
subclass is an instance of the superclass

Subclasses of a class are comprised of a subset of


the superset
25

SubClass Example
RedWine is a subclass of Wine
Every red wine is a wine or every instance of a
red wine (like Marietta Old Vines Red) is an
instance of wine

NapaValleyWine is a subclass of
CaliforniaWine
Every wine from Napa valley is a wine from
California
26

Develop the Class Hierarchy


Different modes of development
top-down - define the most general concepts
first and then specialize them
bottom-up - define the most specific concepts
and then organize them in more general
classes
combination (typical – breadth at the top
level and depth along a few branches to test
design)
27

Wine Concept Hierarchy


Top
level

Middle
level

Bottom
level
Define Properties/Attribute/Slot of
Classes
A part of the class definition describing the
properties of members of a class

E.g., each wine will have


color
sugar content
Flavor
Body …
29

Properties
Different types of properties
“intrinsic” properties: flavor and color of wine
“extrinsic” properties: name and price of wine
parts: ingredients in a dish
relations to other objects: producer of wine
(winery)
Data and object properties
simple (datatype) contain primitive values
(strings, numbers)
complex properties: contain other objects (e.g., a
winery instance)
30

Example Properties for the Class Wine


31

Property and Class Inheritance

A subclass inherits all the properties from the


superclass
If a wine has a name and flavor, a red wine also
has a name and flavor
If a class has multiple super classes, it inherits
properties from all of them
Port is both a dessert wine and a red wine. It
inherits “sugar content: sweet” from the dessert
wine and “color:red” from red wine
32

Property Constraints

Property constraints describe or limit the


set of possible values for a property
the name of a wine is a string
the wine producer is an instance of Winery
a winery has exactly one location
33

Example: Wine Properties and


restrictions
34

Property Restrictions: Cardinality


Slot cardinality – the number of values a slot can
or must have
Minimum cardinality
Minimum cardinality 1 means that the slot must have a
value (required)
Minimum cardinality 0 means that the slot value is
optional
Maximum cardinality
Maximum cardinality 1 means that the slot can have at
most one value (single-valued slot)
Maximum cardinality N means that the slot can have
up to N values. When N is greater than 1 it is a
multiple-valued slot
35

Value Type
Property value type – what values can the
property has
String: a string of characters (“Château
Lafite”)
Number: an integer or a float (15, 4.5)
Boolean: a true/false flag
Enumerated type: a list of allowed values (red,
white, rose)
Object type – a class defined in an ontology.
E.g., Winery is the value restriction on the
hasMaker property on the class Wine
36

Property Example
37

Properties and Class Inheritance


A subclass inherits all the properties from
the superclass
A subclass can add constraints to “narrow”
the list of allowed values
Make the cardinality range smaller
Replace a class in the range with a subclass
hasMaker
Wine Winery

is-a is-a
French hasMaker French
wine winery
38

Create Instances
Create an instance of a class
The class becomes a parent of (or type of) the instance
Any superclass of a class is an ancestor (or type) of the
instance

Assign property values for the instance frame


Property values should conform to the constraints such
as value type, cardinality restrictions, etc.
39

Creating an Instance: Example


Design Considerations: Expanding
the Ontology
Breadth-oriented
Identify all/most of the top level classes, properties
needed at the top level, and constraints at the top level
before go deeper

Depth Oriented
Pick an important branch and go down it, identifying
specific subclasses, sub-sub-classes, etc. and the
appropriate properties.

Typical ontology design is a combination of both

40
Design Considerations: Defining
41

Classes and a Class Hierarchy

Make sure the is-a hierarchy is formal


i.e., is every instance of a subclass an
instance of the superclass
There is no single best correct class
hierarchy but there are some rules of thumb
42

Design Considerations: Class


Hierarchy Transitivity
The is-a relationship is
transitive:
B is a subclass of A
C is a subclass of B
C is a subclass of A
43

Design Considerations: Multiple


Inheritance
A class can have more than one superclass
The subclass inherits slots and restrictions
from all the parents
Different systems may resolve conflicts
differently
44

Design Considerations: Avoiding


Class Cycles

Class cycles are rarely


desirable
Classes A, B, and C have
equivalent sets of instances
By many definitions, A, B, and
C are thus equivalent
45

Design Considerations: Disjoint


Classes
Classes are disjoint if they cannot have common
instances
Disjoint classes cannot have any common
subclasses either
E.g., if winery and wine are disjoint, then there is
no instance that is both a winery and a wine.
Similarly, there is no class that is both a subclass
of winery and simultaneously a subclass of wine
46

Design Considerations: Levels of


hierarchy
If a class has only one child,
there may be a modeling
problem. This is often a sign
that the definition is
incomplete
If the only Red Burgundy we
have is Côtes d’Or, why
introduce the subhierarchy?
Design Considerations: Creating Levels 47

and Subclasses
If a class has a large number
of subclasses, it may be
useful to define intermediate
subclasses
E.g., in the domain of wines,
there are natural groupings
around wine color
However, if no natural
classification exists, the long
list may be more natural
48

One example
hierarchy
of wines
49

Design Considerations: When to


introduce new subclasses?

New subclasses of a class usually have


Additional properties
Additional property restrictions
Participate in different relationships
50

Design Considerations: A new


class or a property value?

Do concepts with different property values


become restrictions for different properties?
A class of an instance should not change often
Design Considerations: A Class
Or An Instance

 Individual instances are the most specific objects in an ontology

 If concepts form a natural hierarchy, represent them as classes

 If they will have instances below them, represent them as classes 51


Design Considerations: Inverse
Properties

hasMaker and
Produces are
inverse
properties
Design Considerations: Inverse
Properties (cont.)
Inverse properties contain redundant
information, but
 Allow acquisition of the information in either direction
 Enable additional verification
 Allow presentation of information in both directions

The actual implementation differs from


system to system
 Are both values stored?
 When are the inverse values filled in?
Design Considerations: Ontology
Inconsistency
 An inconsistent ontology means one part of the ontology
does not agree with another
 In logic: from P and not(P) can derive anything

 Inconsistency is a dangerous thing for AI systems

 Can easily happen, especially in large


distributed/collaborative ontology development
environment
 Consistency checking is important
Ontology Inconsistency: a Simple
Example
X is an instance of both classes A and B
A and B are disjoint

This is an indication of an error in the ontology


Ontology Inconsistency May be
Caused by Ontology Merge
Is-a
Consistency Check via Logic Reasoning
Mapping an ontology language to a
known logical formalism
E.g., a description logic, which is a subset of
predicate logic
Using automated reasoners that already
exist for those formalisms
 Description logic reasoners such as FaCT and
RACER
58

Ontology Tools
In order to use an ontology-based
solution, you must have:
A language
Editing environment
A way to update (evolution environment)
A way to reason with the information
(reasoner)
A way to check the consistency
Ontology Tools (Protege)

protege.stanford.edu
Ontology Reuse

 Why reuse other ontologies?


to interoperate with other ontologies
to leverage other people’s ontology building
work
to use previously validated and/or
authoritative source ontologies
to interact with applications and/or tools that
use other ontologies
61

Reuse Starting Points


Ontology Libraries/Registries
DAML ontology library (www.daml.org/ontologies)
Ontolingua ontology library (
www.ksl.stanford.edu/software/ontolingua/)
 SchemaWeb - http://www.schemaweb.info/ new
evolving collection

Upper ontologies
Cyc (www.cyc.com)
Today’s Agenda
Mini-quiz (10 mins)
No mini-quiz next week
Project Presentation & Final Report(next Thursday)
Semantic Web
Paper presentations
 The Semantic Web: Use of Semantic Technologies to Inform Progress
Toward Zero-Carbon Economy⋆
 Semantic Web: Modeling and Analysis of User Behavior in Online
Communities
Acknowledgement
Some of the slides were originally from the
presentations by

Lina Zhou
Ian Horrocks
Luigi Ceccaroni
Deborah L. McGuinness
Owen Conlan
Athanasios Staikopoulos
See you next week!

You might also like