Course Syllabus This course describes how the power
distribution network assets are modeled and categorized into
classes and draw a relationships among those classes. The class
attribute represents a network data that will be used for inducing
asset conditions, costs, probability of network failure as well as
social and environment factors that influence the asset investment
decision. The modeling approach bases on the prominent a Common
Information Model (CIM) modeling method that used for representing
real-world objects and information entities exchanged within the
value chain of the electric power industry. Underpinning the CIM
knowledge representation are several methods and methodologies such
as UML, XML, and RDF. The course provides all necessary background
of these technologies. In addition, engineering disciplines such as
knowledge engineering and ontological engineering which emphasizes
the knowledge acquisition and ontology development are also
explicated. Combining them all together, attendees will equip
themselves with all necessary knowledge to model not just power
distribution system assets but all the other area of knowledge
modeling.
Slide 3
Course Outline Categorization principle & terminologies
Unified modeling language eXtensible markup language Resource
description framework Common information model knowledge
engineering Ontological development Power distribution network
asset categorization
Categorization Overview The basic cognitive process of
arranging into classes or categories The process in which ideas and
objects are recognized, differentiated and understood.
Categorization implies that objects are grouped into categories,
usually for some specific purpose. Ideally, a category illuminates
a relationship between the subjects and objects of knowledge The
function of category systems and asserts that the task of category
systems is to provide maximum information with the least cognitive
effort The structure of the information so provided and asserts
that the perceived world comes as structured information rather
than as arbitrary or unpredictable attributes
Slide 6
Controlled Vocabulary Way of describing a concept under a
single word or phrase May vary in its definition and usage when use
in different domain An established list of standardized terms used
for both indexing and retrieval of information The list of terms
should be controlled by and be available from a controlled
vocabulary registration authority in order to make a it
unambiguous, non-redundant
Slide 7
Controlled Vocabulary At a minimum, the following two rules
should be enforced to make true in practice: If the same term is
commonly used to mean different concepts in different contexts,
then its name is explicitly qualified to resolve this ambiguity. If
multiple terms are used to mean the same thing, one of the terms is
identified as the preferred term in the controlled vocabulary and
the other terms are listed as synonyms or aliases.
Slide 8
Classification Systematic arrangement in groups or categories
according to established criteria Act or process of putting people
or things into a group or class Establishing the correct class (or
category) for an object where an object needs to be characterized
in terms of class to which it belongs
Slide 9
Classification Classification is an approach to systematically
arranging objects into categories according to established
criteria. Objects are the physical and conceptual things we find in
the universe around us: Hardware, software, documents, animals,
human beings, and even concepts. Classification allows to us manage
things easily by grouping them into certain category under specific
criteria and then manipulate against established condition.
Slide 10
Taxonomy An orderly classification of plants and animals
according to their presumed natural relationships A hierarchy
created according to data internal to the items in that hierarchy
An orderly classification of objects into hierarchical structure
using a parent-child relationships Using parent-child relationships
in taxonomy: e.g., whole part, genus species, type instance, or
class subclass. Differ from classification in the sense that it
classifies in a structure according to some relation between the
entities and that a classification uses more arbitrary (or
external) grounds
Slide 11
Taxonomy
Slide 12
Ontology A branch of metaphysics concerned with the nature and
relations of being A system of concepts used as building blocks of
an information processing system Consists of concepts, hierarchical
(is-a) organization of them, relations among them, in addition to
is-a and part-of, axioms to formalize the definitions and
relations. An explicit specification of a conceptualization
Slide 13
Ontology Taxonomy and ontology are often interchangeably used,
however they are fundamentally different. Taxonomy classifies
objects in a domain in hierarchical structure give exact names for
everything in a specified domain show which things are parts of
other things Ontology offers more by expressing meaningful content
within a specified domain of interest. Has strict, formal rules (a
"grammar") about those relationships that let us make meaningful,
precise statements about our entities/relationships A formal
ontology is hence a controlled vocabulary expressed in an ontology
representation language
Slide 14
Meta-model Data about data Facilitate the understanding,
characteristics, and management usage of data An explicit model of
the constructs and rules needed to build specific models within a
domain of interest A valid meta-model is an ontology, but not all
ontologies are modeled explicitly as meta-models Schema is
Metadata
Slide 15
Power Distribution System Asset Categorization Provide all key
attributes of network assets, either concrete or abstract,
operational stresses and external environments for determining
asset conditions and failure probability Provide all key attributes
to deduce asset costs Provide all associated social and environment
factors that influence decision of asset investment This
information is modeled into classes and attributes as well as class
relationships using the common information model (CIM)
specification
Slide 16
UML Unified Modeling Language
Slide 17
Origins of UML Evolution of object-oriented technology:-
Develop and start using OOP language Use of OOAD in business
process modeling, requirement analysis and software systems design
UML was designed to bring together the best features of a number of
analysis and design technologies and notations to produce and
industrial standard.
Slide 18
Emergence of UML
Slide 19
What is UML? UML is a visual language that originally applied
in developing software systems. Now is extended for using in other
area like knowledge modeling. It is a specification language. it
has a set of elements and a set of rules that determine how it can
be used. Most of UML elements are graphical: lines, rectangles,
ovals and other shapes, and many of these graphical elements are
labelled with words that provides additional information.
Slide 20
Why use UML? The needs of modeling: Modeling can be as
straightforward as drawing a flowchart listing the steps carried
out in business process. Readability brings clarityease of
understanding. This involves knowing what a system is made up of,
how it behaves, and so forth. Reusability is the byproduct of
making a system readable. After a system has been modeled to make
it easy to understand, we tend to identify similarities or
redundancy, be they in terms of functionality, features, or
structure. The underline is standardization.
Slide 21
UML Concepts UML is used to: Show main functions and boundaries
in a system using use cases and actors. Illustrate use case
realizations using interaction diagrams. Represent a static
structure of a system using class diagrams. Modelling object
behaviour using state diagrams. Show implementation of the physical
architecture using component and deployment diagrams. Enhance the
functionality using stereotypes.
Slide 22
UML Diagrams and Elements Use case diagrams Static structural
diagrams Class, object Interaction diagrams Sequence, collaboration
State diagrams Activity diagrams Implementation diagrams Packages,
Components, Deployment
Slide 23
Use Cases Diagram Use cases diagrams describes the behavior of
the target system from an external point of view. Use cases
describe "the meat" of the actual requirements. Use cases: A use
case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
Actors: An actor is a person, organization, or external system that
plays a role in one or more interactions with your system. Actors
are drawn as stick figures. Associations: Associations between
actors and use cases are indicated by solid lines. An association
exists whenever an actor is involved with an interaction described
by a use case
Slide 24
Use Cases Diagram
Slide 25
Class Diagram Class diagrams show the classes of the system,
their inter-relationships, and the operations and attributes of the
classes Explore domain concepts in the form of a domain model.
Analyze requirements in the form of a conceptual/analysis model
Depict the detailed design of object- oriented or object-based
software
Slide 26
Class Diagram Person Class name Attributes OperationsPerson -
TaxIDNo : String - Name : String + Income : double + TaxPaid :
Boolean + calcTax() + calcTaxBal() attribute name : type operation
name(parameter : type) : result type
Slide 27
Object Diagram Object diagrams (instance diagrams), are useful
for exploring real world examples of objects and the relationships
between them. It shows instances instead of classes. They are
useful for explaining small pieces with complicated relationships,
especially recursive relationships.
Slide 28
Class and Objects London : City Name = London Country = UK >
City Name : String = default setName (s : String = deault)
setPopulation(p : integer = default) Population : integer = default
Population =2,324,320 New York : City Name = New York Country = USA
Population =5,734,012 Sydney : City Name = Sydney Country =
Australia Population =3,536,000 Country : String = default
Slide 29
Sequence Diagram Sequence diagrams models the collaboration of
objects based on a time sequence. It shows how the objects interact
with others in a particular scenario of a use case.
Slide 30
Sequence Diagram
Slide 31
Collaboration Diagram Collaboration (Communication) diagrams
used to model the dynamic behavior of the use case. When compare to
Sequence Diagram, the Communication Diagram is more focused on
showing the collaboration of objects rather than the time
sequence.
Slide 32
Collaboration Diagram
Slide 33
State Diagram State diagrams can show the different states of
an entity also how an entity responds to various events by changing
from one state to another. The history of an entity can best be
modeled by a finite state diagram.
Slide 34
State Diagram
Slide 35
Activity Diagram Activity diagrams helps to describe the flow
of control of the target system, such as the exploring complex
business rules and operations, describing the use case also the
business process. It is object-oriented equivalent of flow charts
and data-flow diagrams (DFDs).
Slide 36
Activity Diagram
Slide 37
Packages Diagram Package diagrams simplify complex class
diagrams, it can group classes into packages. A package is a
collection of logically related UML elements. Packages are depicted
as file folders and can be used on any of the UML diagrams.
Slide 38
Packages Diagram
Slide 39
Components Diagram Component diagrams shows the dependencies
among software components, including the classifiers that specify
them (for example implementation classes) and the artifacts that
implement them; such as source code files, binary code files,
executable files, scripts and tables.
Slide 40
Components Diagram
Slide 41
Deployment Diagram Deployment diagram depicts a static view of
the run-time configuration of hardware nodes and the software
components that run on those nodes. Deployment diagrams show the
hardware for your system, the software that is installed on that
hardware, and the middleware used to connect the disparate machines
to one another.
Slide 42
Deployment Diagram
Slide 43
UML Class Diagrams and Relationships How would you draw a
family tree? The steps you would take would be: Identify the main
members of the family Determine how they are related to each other
Identify the characteristics of each family member Find relations
among family members Decide the inheritance of personal traits and
characters
Slide 44
UML Class Diagrams and Relationships By definition, a class
diagram is a diagram showing a collection of classes and
interfaces, along with the collaborations and relationships among
classes and interfaces. A class diagram consists of a group of
classes and interfaces reflecting important entities of the
business domain of the system being modeled, and the relationships
between these classes and interfaces. A class diagram is a
pictorial representation of the detailed system design.
Slide 45
Elements of a Class Diagram NameAttributes Methods
Slide 46
UML Class Relationships RelationSymbolDescription Association
When two classes are connected to each other in any way, an
association relation is established. For example: A "student
studies in a college" association can be shown as:
Slide 47
UML Class Relationships RelationSymbolDescription Multiplicity
An example of this kind of association is many students belonging
to the same college. Hence, the relation shows a star sign near the
student class (one to many, many to many, and so forth kind of
relations).
Slide 48
UML Class Relationships RelationSymbolDescription Directed
Association Association between classes is bi-directional by
default. You can define the flow of the association by using a
directed association. The arrowhead identifies the
container-contained relationship.
Slide 49
UML Class Relationships RelationSymbolDescription Reflexive
Association No separate symbol. An example of this kind of relation
is when a class has a variety of responsibilities. For example, an
employee of a college can be a professor, a housekeeper, or an
administrative assistant.
Slide 50
UML Class Relationships RelationSymbolDescription Aggregation
When two classes are When a class is formed as a collection of
other classes, it is called an aggregation relationship between
these classes. It is also called a "has a" relationship.
Slide 51
UML Class Relationships RelationSymbolDescription Composition
Composition is a variation of the aggregation relationship.
Composition connotes that a strong life cycle is associated between
the classes.
Slide 52
UML Class Relationships RelationSymbolDescription Inheritance/
Generalization Also called an "is a" relationship, because the
child class is a type of the parent class. Generalization is the
basic type of relationship used to define reusable elements in the
class diagram. Literally, the child classes "inherit" the common
functionality defined in the parent class.
Slide 53
UML Class Relationships RelationSymbolDescription Realization
In a realization relationship, one entity (normally an interface)
defines a set of functionalities as a contract and the other entity
(normally a class) "realizes" the contract by implementing the
functionality defined in the contract..
Slide 54
Other Terms for Annotations of Class Diagrams Responsibility of
a class: It is the statement defining what the class is expected to
provide. Stereotypes: It is an extension of the existing UML
elements; it allows you to define new elements modeled on the
existing UML elements. Only one stereotype per element in a system
is allowed. Vocabulary: The scope of a system is defined as its
vocabulary. Analysis class: It is a kind of a stereotype. Boundary
class: This is the first type of an analysis class. In a system
consisting of a boundary class, the users interact with the system
through the boundary classes. Control class: This is the second
type of an analysis class. A control class typically does not
perform any business functions, but only redirects to the
appropriate business function class depending on the function
requested by the boundary class or the user. Entity class: This is
the third type of an analysis class. An entity class consists of
all the business logic and interactions with databases.
Slide 55
Put Them Together
Slide 56
XML eXtensible Markup Language
Slide 57
Evolution SGML (Standard Generalized Markup Language) ISO
Standard, 1986, for data storage & exchange Metalanguage for
defining languages (through DTDs) A famous SGML language: HTML!!
Separation of content and display Used in U.S. gvt. &
contractors, large manufacturing companies, technical info.
Publishers,... SGML reference is 600 pages long XML (eXtensible
Markup Language) W3C (World Wide Web Consortium) --
http://www.w3.org/XML/) recommendation in 1998 Simple subset (80/20
rule) of SGML: ASCII of the Web, Semantic Web. XML specification is
26 pages long
Slide 58
Evolution Canonical XML normalization, equivalence testing of
XML documents SML (Simple Markup Language) Reduce to the max: No
Attributes / No Processing Instructions (PI) / No DTD / No
non-character entity- references / No CDATA marked sections /
Support for only UTF-8 character encoding / No optional features
XML Schema XML Schema definition language Back to complex: Part I
(Structures), Part II (Data Types), Part III aehm 0 (Primer)
Slide 59
What is XML? XML is a universal format for structured documents
and data. Can be understood using any (archaic CP/M) editor Can be
parsed easily Contains its own structure (=parse tree) in the data
Allows separation of marked-up content from presentation (style
sheets) As a self-describing format good for archival into the past
- not bad for archival into the future XML uses a Document Type
Definition (DTD) or an XML Schema to describe the data XML with a
DTD or XML Schema is designed to be self-descriptive
Slide 60
Simple XML Example Tom Jane Reminder Meeting at 9.00 AM
Slide 61
Why Is XML Important? Plain Text Easy to edit Useful for
storing small amounts of data Possible to efficiently store large
amounts of XML data through an XML front end to a database Data
Identification Tell you what kind of data you have Can be used in
different ways by different applications
Slide 62
Why Is XML Important? Stylability Inherently style-free
XSL---Extensible Stylesheet Language Different XSL formats can then
be used to display the same data in different ways Inline
Reusabiliy Can be composed from separate entities Modularize your
documents without resorting to links
Slide 63
Why Is XML Important? Linkability -- XLink and XPointer Simple
unidirectional hyperlinks Two-way links Multiple-target links
Expanding links Easily Processed Regular and consistent notation
Vendor-neutral standard Hierarchical Faster to access Easier to
rearrange
Slide 64
XML Building Blocks Element Delimited by angle brackets
Identify the nature of the content they surround General format:
Empty element: Attribute Name-value pairs that occur inside
start-tags after element name, like:
Slide 65
XML Building blocks--Prolog The part of an XML document that
precedes the XML data Includes A declaration: version [, encoding,
standalone] An optional DTD (Document Type Definition )
Example
Slide 66
XML Syntax All XML elements must have a closing tag XML tags
are case sensitive All XML elements must be properly nested All XML
documents must have a root tag Attribute values must always be
quoted With XML, white space is preserved With XML, a new line is
always stored as LF Comments in XML:
Slide 67
XML is Based on Markup Y.Papakonstantinou S. Abiteboul H.
Garcia-Molina Object Fusion in Mediator Systems VLDB 96 Markup
indicates structure and semantics Decoupled from presentation
Slide 68
XML Elements XML Elements are Extensible XML documents can be
extended to carry more information XML Elements have Relationships
Elements are related as parents and children Elements have Content
Elements can have different content types: element content, mixed
content, simple content, or empty content and attributes XML
elements must follow the naming rules
Slide 69
XML as Labeled Ordered Trees Yannis Serge... Object Fusion...
bibliography paper authors author... title fullpaper YannisSerge
Object Fusion... paper semistructured data labeled trees/graphs can
also represent relational and object-oriented data
Slide 70
Elements and their Content element element name Character
content Element Content Empty Element Y.Papakonstantinou S.
Abiteboul H. Garcia-Molina Object Fusion in Mediator Systems VLDB
96
Slide 71
XML Attributes Located in the start tag of elements Provide
additional information about elements Often provide information
that is not a part of data Must be enclosed in quotes Should I use
an element or an attribute? metadata (data about data) should be
stored as attributes, and that data itself should be stored as
elements
Slide 72
Element Attributes Attribute name Attribute Value
Y.Papakonstantinou S. Abiteboul H. Garcia-Molina Object Fusion in
Mediator Systems VLDB 96
Slide 73
XML Validation "Well Formed" XML document correct XML syntax
"Valid" XML document well formed Conforms to the rules of a DTD
(Document Type Definition) XML DTD defines the legal building
blocks of an XML document Can be inline in XML or as an external
reference XML Schema an XML based alternative to DTD, more powerful
Support namespace and data types
Slide 74
Displaying XML XML documents do not carry information about how
to display the data We can add display information to XML with CSS
(Cascading Style Sheets) XSL (eXtensible Stylesheet Language) -- -
preferred
Slide 75
XML Specification XML Document Type Definitions (DTDs): define
the structure of "allowed" documents (i.e., valid written a DTD)
database schema improve query formulation, execution,... XML Schema
defines structure and data types allows developers to build their
own libraries of interchanged data types XML Namespaces identify
your vocabulary
Slide 76
Document Type Definitions (DTD) Define and Constrain Element
Names & Structure Element Type Declaration Attribute List
Declaration
Slide 77
Document Type Definitions (DTD) Character content Authors
followed by optional fullpaper, followed by title, followed by
booktitle Sequence of 1 or more author Sequence of 0 or more
paper
Slide 78
Document Type Definitions (DTD) Y.Papakonstantinou Object
Fusion in Mediator Systems Object Identity Attribute CDATA
(character data) Yannis info IDREF intradocument reference
Reference to external ENTITY
Slide 79
XML Namespaces Namespace is a mapping between an element prefix
and a URI cars is the prefix in this example, URIs are not a
pointer to information about the Namespace. They are just unique
identifiers. You cannot resolve XML namespace URIs.
Slide 80
XML Namespaces An XML document may reference more than one
schema A Namespace specifies which schema defines a given tag XML,
like Java, uses qualified names This helps to avoid collisions
between names Java: myObject.myVariable XML: myDTD:myTag Note that
XML uses a colon (:) rather than a dot (.) If an XML processor is
not namespace- aware, the colon is just part of the name
Slide 81
Namespaces and URIs A namespace is defined as a unique string
To guarantee uniqueness, typically a URI (Uniform Resource
Indicator) is used, because the author owns the domain It doesn't
have to be a real URI; it just has to be a unique string Example:
http://www.matuszek.org/ns There are two ways to use namespaces:
Declare a default namespace Associate a prefix with a namespace,
then use the prefix in the XML to refer to the namespace
Slide 82
Namespace Syntax In any start tag you can use the reserved
attribute name xmlns: This namespace will be used as the default
for all elements up to the corresponding end tag You can override
it with a specific prefix You can use almost this same form to
declare a prefix: Use this prefix on every tag and attribute you
want to use from this namespace, including end tags--it is not a
default prefix To Begin You can use the prefix in the start tag in
which it is defined:
Slide 83 "> "> " title="Namespaces and DTD Here is a
sample Namespace specification within a DTD. ">
Namespaces and DTD Here is a sample Namespace specification
within a DTD.
Slide 84
XML Schema People are dissatisfied with DTDs due to:- It's a
different syntax You write your XML (instance) document using one
syntax and the DTD using another syntax --> bad, inconsistent
Limited datatype capability DTDs support a very limited capability
for specifying datatypes. You can't, for example, express "I want
the element to hold an integer with a range of 0 to 12,000" Desire
a set of datatypes compatible with those found in databases DTD
supports 10 datatypes; XML Schemas supports 44+ datatypes
Slide 85
What is XML Schema? A grammar definition language Like DTDs but
better Uses XML syntax Defined by W3C Primary features Datatypes
e.g. integer, float, date, etc More powerful content models e.g.
namespace-aware, type derivation, etc A schema is a collection of:
type definitions simple type complex type (contains element or
attribute) element declarations
Slide 86
Schema Terminology Schema: a formal description for the
structure and allowed content of a set of data (esp. in databases)
XML Schema is often used for each of 1. XML Schema, the W3C Rec.
that defines 2. XML Schema Definition Language (XSDL), an XML-based
markup language for expressing... 3. schema documents, each of
which describes a schema (DTD) for a set of XML document
instances
Slide 87
Advantages of XSDL XML syntax schema documents easier to
manipulate by programs (than the special DTD syntax) Compatibility
with namespaces can validate documents using declarations from
multiple sources Content datatypes 44 built-in datatypes (including
primitive Java datatypes, datatypes of SQL, and XML attribute
types) mechanisms to derive user-defined datatypes
Slide 88
Slide 89
Advantages of XSDL Independence of element names and content
types; Compare with DTDs: 1-to-1 correspondence btw. element type
names and their content models CFGs: 1-to-1 correspondence btw.
nonterminals and their productions For example, could define titles
of people as Mr./Mrs./Ms. and titles of chapters as strings
Slide 90
Advantages of XSDL Support for schema documentation element
annotation with sub-elements documentation (for human readers) and
appInfo (for applications) Ability to specify uniqueness and keys
within selected parts of document for example, that titles of
chapters should be unique
Slide 91
Disadvantages of XSDL Complexity of XSDL (esp. of Rec. Part 1!)
> a long learning curve Possible immaturity of implementations
(?) W3C XML Schema Web site mentions a dozen of tools or processors
(http://www.w3.org/XML/Schema#Tools, March 2002) Open-source Apache
XML parsers (Xerces C++ 1.7.0 and Xerces Java 1.4.4) seem
reasonable implementations, but also document limitations/problems
in their XML Schema support
Slide 92
Highlights of XML Schemas XML Schemas are a tremendous
advancement over DTDs: Enhanced datatypes 44+ versus 10 Can create
your own datatypes Example: "This is a new type based on the string
type and elements of this type must follow this pattern: ddd-dddd,
where 'd' represents a digit". Written in the same syntax as
instance documents less syntax to remember Object-oriented'ish Can
extend or restrict a type (derive new type definitions on the basis
of old ones) Can express sets, i.e., can define the child elements
to occur in any order Can specify element content as being unique
(keys on content) and uniqueness within a region Can define
multiple elements with the same name but different content Can
define elements with nil content Can define substitutable elements
- e.g., the "Book" element is substitutable for the "Publication"
element.
Slide 93
Example: DTD note.dtd
Slide 94 Tove Jani Reminder Don't forget me this weekend!
note.xml"> Tove Jani Reminder Don't forget me this weekend!
note.xml"> Tove Jani Reminder Don't forget me this weekend!
note.xml" title="Example: XML DTD Tove Jani Reminder Don't forget
me this weekend! note.xml">
Example: XML DTD Tove Jani Reminder Don't forget me this
weekend! note.xml
Slide 95 note.xsd">
Example: XML Schema note.xsd
Slide 96 Tove Jani Reminder Don't forget me this weekend!
note.xml">
Example: XML XML Schema Tove Jani Reminder Don't forget me this
weekend! note.xml
Slide 97
RDF Resource Description Framework
Slide 98
Motivation for RDF RDF and Metadata Scenario 1: The library
Lookup system search properties include author, title, subject etc.
Scenario 2: The video store Lookup system search properties include
directors, actors, etc. The common thread: Metadata: information
about information
Slide 99
Motivation for RDF What about the Web? One big library, need
call number to get things without a search Has hardly any metadata,
HTML Yahoo Has metadata based lookup facility, uses human generated
subject categories and site labels Library example to illustrate
need for metadata
Slide 100
What is RDF? RDF stands for Resource Description Framework RDF
is a framework for describing resources on the web RDF provides a
model for data, and a syntax so that independent parties can
exchange and use it RDF is designed to be read and understood by
computers RDF is not designed for being displayed to people RDF is
written in XML RDF is a part of the W3C's Semantic Web Activity RDF
is a W3C Recommendation
Slide 101
What is RDF? Describe relationships and attributes of
(Internet) resources, i.e. advanced metadata Based on Directed
Labelled Graphs (DLG) and classical Information Analysis Also
represented in XML, N3, N-Triple Attributes and Relation types may
be defined by XML Namespaces, e.g. Dublin Core A general method to
decompose knowledge into small pieces with some rules about
semantics or meaning of those pieces Designed for knowledge, not
data, means RDF is particularly concerned with meaning
Slide 102
RDF and XML RDF is an implementation of XML Why not just use
XML? XML falls apart on the scalability design goal. There are two
problems: Order of elements important unnatural in metadata, also
expensive in practice Representation of XML documents in memory
trees difficult to manage when large XML unequalled as an exchange
format on the Web, but it doesnt provide a metadata framework
Slide 103
Uses of RDF Resource Discovery to provide better search engine
capabilities Cataloging for describing the content and content
relationships Intelligent software agents to facilitate knowledge
sharing exchange Content rating in describing collections of pages
that represent a single logical document
Slide 104
Uses of RDF Describing intellectual property rights Privacy
preferences expression of a user as well as the privacy polices of
a Web site Web of Trust RDF with digital signatures will be key to
building the Web of Trust for electronic commerce, collaboration,
and other applications.
Slide 105
RDF Components Formal data model Syntax for interchange of data
Schema Type system (schema model) Syntax for machine-understandable
schemas Query and profile protocols
Slide 106
RDF Data Model Imposes structural constraints on the expression
of application data models for consistent encoding, exchange and
processing of metadata Enables resource description communities to
define their own semantics Provides for structural
interoperability
Slide 107
RDF Data Model Directed labelled graphs Model elements
Statement: Resource (Subject) + Property (Predicate) + Value
(Object) Resource: anything that can be identified, identified by a
URI. Property: specific aspect, characteristic, attribute, or
relation used to describe a resource URI: verbose name for
Resource, can be http, urn, tag types Value
Slide 108
RDF Elements Subject source of relationship Always a resource
Predicate labeled arc Always a resource Object relationships
destination Resource or literal Subject and Predicates are
first-class objects Which means they can be used as subjects or
objects of other statements
Slide 109
RDF Model Primitives Resource Property Value Resource
Statement
Slide 110
RDF Model Resource Author Paul
Slide 111
RDF Syntax RDF Model defines a formal relationships among
resources, properties and values Syntax is required to... Store
instances of the model into files Communicate files from one
application to another W3C XML eXtensible Markup Language
http://www.w3.org/XML
Slide 112
RDF Model Example URI:R RDF Presentation Title Creator dc: Paul
Miller
Slide 113
RDF Syntax Example URI:R RDF Presentation Title Creator dc:
Paul Miller RDF Presentation Paul Miller
Slide 114
RDF Model Example Paul Miller URI:PAUL p.miller@ ukoln.ac.uk
Paul Miller UKOLN bib:Emailbib:Aff bib:Name URI:R URI:UKOLN RDF
Presentation Title Creator dc:
RDF Schema RDFS or RDF Schema is an extensible knowledge
representation language, providing basic elements for the
description of ontologies, otherwise called RDF vocabularies,
intended to structure RDF resources. The first version was
published by W3C in April 1998, and the final W3C recommendation
was released in February 2004. Main RDFS components are included in
the more expressive language OWL. RDFS is also written in XML.
Slide 117
RDF Schema RDF describes resources with classes, properties,
and values. In addition, RDF also need a way to define application
-specific classes and properties. Application-specific classes and
properties must be defined using extensions to RDF: RDF Schema RDF
Schema does not provide actual application- specific classes and
properties. Instead RDF Schema provides the framework to describe
application-specific classes and properties Classes in RDF Schema
is much like classes in object oriented programming languages. This
allows resources to be defined as instances of classes, and
subclasses of classes
Slide 118
RDF Schema Basic vocabulary to describe RDF vocabularies
Defines properties of the resources (e.g., title, author, subject,
etc) Defines kinds of resources being describes (books, Web pages,
people, etc) XML Schema gives specific constraints on the structure
of an XML document RDF Schema provides information about the
interpretation of the RDF statements
Slide 119
Class ResourceDatatype ContainerLiteralPropertyListStatement
AltBagSeqXMLLiteralContainerMembershipProperty RDFS / RDF
Classes
Slide 120
ElementDomainRangeDescription rdfs:domainPropertyClassThe
domain of the resource rdfs:rangePropertyClassThe range of the
resource rdfs:subPropertyOfProperty The property is a sub property
of a property rdfs:subClassOfClass The resource is a subclass of a
class rdfs:commentResourceLiteralThe human readable description of
the resource rdfs:labelResourceLiteralThe human readable label
(name) of the resource rdfs:isDefinedByResource The definition of
the resource rdfs:seeAlsoResource The additional information about
the resource rdfs:memberResource The member of the resource
rdf:firstListResource rdf:restList rdf:subjectStatementResourceThe
subject of the resource in an RDF Statement
rdf:predicateStatementResourceThe predicate of the resource in an
RDF Statement rdf:objectStatementResourceThe object of the resource
in an RDF Statement rdf:valueResource The property used for values
rdf:typeResourceClassThe resource is an instance of a class RDFS /
RDF Properties
Slide 121
ElementDomainRangeDescription rdf:about Defines the resource
being described rdf:Description Container for the description of a
resource rdf:resource Defines a resource to identify a property
rdf:datatype Defines the data type of an element rdf:ID Defines the
ID of an element rdf:li Defines a list rdf:_n Defines a node
rdf:nodeID Defines the ID of an element node rdf:parseType Defines
how an element should be parsed rdf:RDF The root of an RDF document
xml:base Defines the XML base xml:lang Defines the language of the
element content RDFS / RDF Attributes
Slide 122 Person Class Person Class
RDF ( corresponded to previous schema ) Programming XML in Java
John Punin Elizabeth Roberts George Lucas John Smith
Slide 125
CIM Common Information Model
Slide 126
CIM Motivation Deregulation of the power industry worldwide
requires utility companies share power system data: Energy
Management System- EMS Exchanging power systems data is always
problematic due to use of proprietary formats Needs of open
standard for representing power system components CIM defines a
common model for describing the components in power systems for use
in a common EMS
Slide 127
CIM Overview CIM is an information object-oriented model
representing real-world objects found in transmission and
distribution operation and management Enable integration of
applications/systems Provides a common model behind all messages
exchanged between systems Basis for defining information exchange
models CIM provides a comprehensive, logical view of EMS
information for: Transmission network analysis Generation control
SCADA Operator training simulation
Slide 128
CIM Overview Enable data access in a standard way Common
language to navigate and access complex data structures in any
database Provides a hierarchical view of data for browsing and
access with no knowledge of actual logical schema Inspiration for
logical data schemas (e.g., for an operational data store) Not tied
to a particular applications view of the world But permits same
model to be used by all applications to facilitate information
sharing between applications Also provides consistent view of the
world by operators regardless of which application user interface
they are using
Slide 129
CIM Overview A data model to enable data transfer or
integration in any domain where a common power system model is
needed Model includes Classes, their Attributes, and Relationships
to represent utility objects The Classes (Objects) are abstract and
may are used in a wide variety of applications Useful: As
Foundation for Logical Data Base Schema To Define Component
Interfaces Common Language for Data Exchange
Slide 130
Sample Power System Model
Slide 131
Role of CIM in Utility Enterprise Data preparation Provides
common set of semantics and data representation regardless of
source of data Improves data quality and enables data validation
Data exchange Provides common language and format Provides common
set of services for sharing data System integration Provides basis
for a standards-based integration framework Web services payloads
and Service Oriented Architecture (SOA) Enterprise Information
Management Part of overall Enterprise Information Model relating to
business processes/automation/management
Slide 132
Benefits of Using CIM Approach Data model driven solutions
leads to interoperability Provides common semantics for information
exchange between heterogeneous systems Used for CA to CA
communications NERC mandated use of CIM and RDF Schema version for
power system model exchange Provides for automatic generation of
message payloads in XML Ensures common language for all messages
defined Avoids proprietary message formats from vendors (based on
internal schemas) Eliminates work of creating DTD for each message
Alternative to EDI or CSV file formats
Slide 133
Benefits of Using CIM Approach Uses industry standard modeling
notation UML, XML, RDF Permits software tool use for: Defining and
maintaining data models Single point of maintenance for changes
Documenting data models Automatic generation of information
payloads Automatically generate IDL, Java, C code
Slide 134
CIM Related Standards EPRI CCAPI: The Electric Power Research
Institute (EPRI) proposed an integration framework called control
center application program interface for EMS data sharing IEC
61970-301: Common Information Model (CIM) base- A semantic model
describing the components of a power system at an electrical level
and the relationships between each component IEC 61970-501: Common
Information Model Resource Description Framework (CIM RDF) schema
IEC 61968-4: Interfaces for records and asset management IEC
61968-11: Extends the model to cover the other aspects of power
system software data exchange such as asset tracking, work
scheduling and customer billing
Slide 135
CIM Representation CIM is documented as a set of class diagrams
using the Unified Modeling Language (UML) UML specifies CIM in an
abstract manner that allows for open implementation: There is no
restriction to relational, object oriented or other modeling
technologies The UML is a Diagramming Tool for CIM
Slide 136
An Example of CIM in UML
Slide 137
CIM Packages CIM consists of a number of packages Needed to
make the model easier to design, understand and review Packages are
grouped to be handled as a single standard document CIM - Common
Information Model CIM Base in UML - IEC 61970 Part 301 CIM Energy
Scheduling, Reservations & Financial - IEC 61970 Part 302CIM
SCADA - IEC 61970 Part 303 CIS - Component Interface Specifications
GID - Generic Interface Definition CIM Model Exchange Format CIM
RDF Schema (UML->RDF) - IEC 61970 Part 501 CIM XML Model data
Exchange Format - IEC 61970 Part 552-4
Slide 138
CIM Base Part 301 CIM Base in UML Package used for the Project
Dashed lines indicate a dependency relationship between packages
Arrow points from the dependent package to the package on which it
has a dependency The Generation package is divided into two sub
packages: Production GenerationDynamics
Slide 139
Components of Part 301 Core This package contains the core
Naming, PowerSystemResource, EquipmentContainer, and
ConductingEquipment entities shared by all applications plus common
collections of those entities Not all applications require all the
Core entities This package does not depend on any other package,
but most of the other packages have associations and
generalizations that depend on it Topology This package is an
extension to the Core Package Specifies physical definition of how
equipment is connected together In addition it models Topology,
that is the logical definition of how equipment is connected via
closed switches The Topology definition is independent of the other
electrical characteristics
Slide 140
Components of Part 301 Wires The Wires package is an extension
to the Core and Topology packages Models information on the
electrical characteristics of Transmission and Distribution
networks This package is used by network applications such as State
Estimation, Load Flow and Optimal Power Flow Outage This package is
an extension to the Core and Wires packages Models information on
the current and planned network configuration
Slide 141
Components of Part 301 Protection This package is an extension
to the Core and Wires packages Models information for protection
equipment such as relays Meas Describes dynamic measurement data
exchanged between applications
Slide 142
Components of Part 301 LoadModel Provides models for the system
load as curves and associated curve data Used for Load Forecasting
and Load Management Production Provides models for various types of
generators Models production costing information which is used to
economically allocate demand among committed units and calculate
reserve quantities This information is used by Unit Commitment and
Economic Dispatch, Load Forecasting, Automatic Generation Control
applications.
Slide 143
Components of Part 301 Generation Dynamics Provides models for
prime movers This information is used by Unit Modeling for Dynamic
Training Simulator applications Domain Data dictionary of
quantities and units This package contains the definition of
datatypes, including units of measure and permissible values
Slide 144
Core Package
Slide 145
Topology Package
Slide 146
Wire Package
Slide 147
Outage Package
Slide 148
Protection Package
Slide 149
Meas Package
Slide 150
LoadModel Package
Slide 151
Production Package
Slide 152
GenerationDynamic Package
Slide 153
Domain Package
Slide 154
CIM XML A common model exchange format based on the CIM data
definition and XML was developed Proposed to NERC and subsequently
adopted by their Data Exchange Working Group (DEWG) All major
vendors of energy management systems have voiced their support for
the format CIM/XML is a language for expressing CIM models in XML
The NERC has adopted CIM/XML as the standard for exchanging models
between power transmission system operators The CIM/XML format is
also going through an IEC international standardization
process
Slide 155
CIM XML Resource Description Framework (RDF) defines a
mechanism for describing resources RDF is a general-purpose
language for representing information in the Web RDF integrates a
variety of applications using XML as an interchange syntax RDF
Schema is a standard which describes how to use CIM XML CIM/XML is
an RDF application, using RDF and RDF Schema to organize its XML
structures
Slide 156
CIM XML RDF Example The base class of the CIM is the
PowerSystemResource class Other more specialized classes such as
Substation, Switch, and Breaker are defined as subclasses CIM/XML
uses RDF as the language for exchanging specific system models
Slide 157
CIM XML RDF Example
Slide 158
Slide 159
Slide 160
Slide 161
Slide 162
KE knowledge engineering
Slide 163
What is Knowledge? Data: raw, simply exists, intercept by
sensory devices or organ Information: meaning that interpreted from
data Knowledge: collection of information, people use when solving
the problem Knowle dge Inform ation Data
Slide 164
Where Knowledge Resides? The problem with knowledge, however,
is that, unlike information, it typically doesn't reside on paper.
Instead, it lives inside people's heads.
Slide 165
Knowledge Management (1) A strategy, framework or system
designed to help organisations create, capture, analyse, apply, and
reuse knowledge to achieve competitive advantage. A key aspect is
that knowledge within an organisation is treated as a key asset. A
core aspect is "getting the right knowledge to the right people at
the right time in the right format".
Slide 166
Knowledge Management (2)
Slide 167
Socialization ExternalizationExternalization
InternalizationInternalization CombinationCombination Tacit
Knowledge Explicit Knowledge Tacit Knowledge totototo Type of
Knowledge totototo Knowledge Management (3) Nonaka SECI Model
Slide 168
Knowledge Engineering (1) A field within artificial
intelligence that develops knowledge-based systems Computer
programs that contain large amounts of knowledge, rules and
reasoning mechanisms to provide solutions to real- world problems
An expert system that designed to emulate the reasoning processes
of an expert practitioner
Slide 169
Knowledge Engineering (2) Key KE principles: Different types of
knowledge Different types of experts and expertise Different ways
of representing knowledge Different ways of using knowledge Right
approach and technique must be employed acquire validate and reuse
of Knowledge
Slide 170
Knowledge Engineering (3) Three types of experts Academic:
Theoretical understanding is prized. Their job is to explicate
clarify and teach others May be far from day-to-day problem solving
Practitioner: Engage constant day-to-day problem solving Implicit
Difficult for them to articulate Samurai: Pure performance expert
Equipped with theoretical knowledge and put them into real problem
solving Comfortable to articulate
Slide 171
Knowledge Engineering (4) Need a way to relates different type
of knowledge, experts, representation and task together to perform
a knowledge- oriented activity Not to interview experts about
knowledge they cannot articulate, represent it in a form no one
understand and eventually find they do not really need it Use
structured methods
Slide 172
Knowledge Roles
Slide 173
Classification of Knowledge Declarative and Procedural
Knowledge: Knowing what vs. knowing how Tacit and Explicit
Knowledge: Easy to articulate vs. hard to articulate Generic and
Specific Knowledge: Applying across many situations vs. applying
across a few situations
Slide 174
Knowledge Modeling A way of structuring projects, acquiring and
validating knowledge and storing knowledge for future use. Symbolic
character-based languages, such as logic Diagrammatic
representations, such as networks and ladders Tabular
representations, such as matrices Structured text, such as
hypertext
Slide 175
Knowledge Object Field of logic has also inspired important
knowledge types, notably concepts, attributes, values, rules and
relationships Concepts are the things (physical objects,
information, people, etc.) that constitute a domain. Each concept
is described by its relationships to other concepts in the domain
(e.g. in a hierarchy), and by its attributes and values. Instance
is an instantiated class. For example, "my car" is an instance of
the concept "car Attributes are the generic properties, qualities
or features belonging to a class of concepts, e.g. weight, cost,
age and ability. Values are the specific qualities of a concept
such as its actual weight or age. Values are associated with a
particular attribute and can be numerical (e.g. 120Kg, 6 years old)
or categorical (e.g. heavy, young) Rules are statements of the form
"IF... THEN...". Relationships represent the way knowledge objects
(such as concepts and tasks) are related to one another. Important
examples include is a to show classification, part of to show
composition,
Slide 176
Slide 177
Slide 178
Structured Modeling Techniques Relational database (RDB) Object
oriented database (OODB) eXtensible markup language (XML) Unified
modeling language (UML)
Slide 179
Uses of Knowledge Models Knowledge elicitation (from an expert)
Validation (with the same expert) Cross-validation (with another
expert) Knowledge publication Maintenance and updating of the
knowledge system or publication
Slide 180
Knowledge Acquisition (1) Generic process 1.Conduct an initial
interview with the expert to a)scope what knowledge should be
acquired, b)determine to what purpose the knowledge should be put,
c)gain some understanding of key terminology, and d)build a rapport
with the expert 2.Transcribe the initial interview and analyze the
resulting document (called a protocol) to produce a set of
questions that cover the essential issues across the domain and
that serve the goals of the knowledge acquisition exercise
Slide 181
Knowledge Acquisition (2) Generic process 3.Conduct a second
interview with the expert using the pre-prepared questions to
provide structure and focus. (This is called a semi-structured
interview.) 4.Transcribe the semi-structured interview and analyse
the resulting protocol, looking for knowledge types: concepts,
attributes, values, classes of concepts, relationships between
concepts, tasks and rules. 5.Represent these knowledge elements in
a number of formats, for example, hierarchies of classes
(taxonomies), hierarchies of constitutional elements, grids of
concepts and attributes, diagrams, and flow charts. In addition,
document, in a structured manner, anecdotes (war stories) and
explanations that the expert gives.
Slide 182
Knowledge Acquisition (3) Generic process 6.Use the resulting
representations and structured documentation with contrived
techniques to allow the expert to modify and expand on the
knowledge you have already captured. 7.Repeat the analysis,
representation-building and acquisition sessions until the expert
is happy that the goals of the project have been realised.
8.Validate the knowledge acquired with other experts, and make
modifications where necessary.
Slide 183
Knowledge Acquisition (4) Issues in Knowledge Acquisition: Most
knowledge is in the heads of experts Experts have vast amounts of
knowledge Experts have a lot of tacit knowledge They don't know all
that they know and use Tacit knowledge is hard (impossible) to
describe Experts are very busy and valuable people Each expert
doesn't know everything Knowledge has a "shelf life"
Slide 184
Knowledge Acquisition (5) Requirements for knowledge
acquisition: Take experts off the job for short time periods Allow
non-experts to understand the knowledge Focus on the essential
knowledge Can capture tacit knowledge Allow knowledge to be
collated from different experts Allow knowledge to be validated and
maintained
Interviewing (1) Common use for knowledge acquisition Range
from completely unstructured to formally planned, structured
interview Audio-visual recording is required
Slide 187
Interviewing (2) Probe Code Question templateEffect P1Why would
you do that?Converts an assertion into a rule P2How would you do
that?Generates lower-order rules P3When would you do that? Is
always the case? Reveals the generality of the rule and may
generate other rules P4What alternatives to are there? Generates
more rules P5What if it were not the case that ? Generates rules
for when current condition does not apply P6Can you tell me more
about ? Used to generate further dialogue if expert dries up
Slide 188
Interviewing (3) EX: I actually checked the port of the
computer KE:Why did you check the port? (P1) EX:If its been
lightning recently then its good to check the port, because
lightning tends to damage the ports. KE:Are there any alternatives
to that problem? (P4) EX:Yes, that ought to be prefaced by saying
that if it was several keys with odd effects, not necessarily all
of them, but two or more. KE:Why does it have to be more than two?
EX:Well, if it was only one or two keys doing funny things then the
thing to do is check theyre closing property, speed would affect
all keys, parity would affect about half the keys.
Slide 189
Interviewing (4) IFthere has been recent lightning THENcheck
port for damage IFthere are two or fewer malfunction keys THENcheck
the key contacts IFabout half the keyboard is malfunctioning
THENcheck the parity IFthe whole keyboard is malfunctioning
THENcheck the speed
Slide 190
Work observation Simply observing and making notes as the
expert performs their daily activities Videotaping task performance
can be useful especially if combined with retrospective reporting
techniques
Slide 191
Commentary Think aloud problem-solving Expert providing a
running commentary of their thought processes as they solve a
problem Experts protocol of task behaviour shown in video and asked
to provide a running commentary on what they were thinking and
doing
Slide 192
Protocol Analysis To identify of basic knowledge objects within
a protocol - transcript An interview transcript would be analyzed
by highlighting all the concepts that are relevant to the task
Categories of fundamental knowledge such as concepts, attributes,
values, tasks and relationships would be extracted For example, if
the transcript concerns the task of diagnosis, then such categories
as symptoms, hypotheses and diagnostic techniques would be used for
the analysis
Slide 193
Laddering Involve the creation, reviewing and modification of
hierarchical knowledge, often in the form of ladders, i.e. tree
diagrams See example See example
Slide 194
Knowledge intensive Task Hierarchy
Slide 195
Analytic versus synthetic tasks analytic tasks system
pre-exists it is typically not completely "known" input: some data
about the system, output: some characterization of the system
synthetic tasks system does not yet exist input: requirements about
system to be constructed output: constructed system
description
Slide 196
Structure of template description in catalog General
characterization typical features of a task Default method roles,
sub-functions, control structure, inference structure Typical
variations frequently occurring refinements/changes Typical
domain-knowledge schema assumptions about underlying domain-
knowledge structure
Slide 197
Classification establish correct class for an object object
should be available for inspection "natural" objects examples: rock
classification, apple classification terminology: object, class,
attribute, feature one of the simplest analytic tasks; many methods
other analytic tasks: sometimes reduced to classification problem
especially diagnosis
Slide 198
Classification: Pruning method generate all classes to which
the object may belong specify an object attribute obtain the value
of the attribute remove all classes that are inconsistent with this
value
Slide 199
Classification:inference structure
Slide 200
Classification: method control while new-solution
generate(object -> candidate) do candidate-classes := candidate
union candidate-classes; while new-solution
specify(candidate-classes -> attribute) and length
candidate-classes > 1 do obtain(attribute -> new-feature);
current-feature-set := new-feature union current-feature- set;
for-each candidate in candidate-classes do match(candidate +
current-feature-set -> truth-value); if truth-value = false;
then candidate-classes := candidate-classes subtract
candidate;
Slide 201
Classification: method variations Limited candidate generation
Different forms of attribute selection decision tree information
theory user control Hierarchical search through class
structure
Slide 202
Classification: domain schema
Slide 203
Rock classification
Slide 204
Nested classification
Slide 205
Rock classification prototype
Slide 206
Assessment find decision category for a case based on
domain-specific norms. typical domains: financial applications
(loan application), community service terminology: case, decision,
norms some similarities with monitoring differences: timing:
assessment is more static different output: decision versus
discrepancy
Slide 207
Assessment: abstract & match method Abstract the case data
Specify the norms applicable to the case e.g. rent-fits-income,
correct-household- size Select a single norm Compute a truth value
for the norm with respect to the case See whether this leads to a
decision Repeat norm selection and evaluation until a decision is
reached
Slide 208
Assessment:inference structure case abstracted case norms norm
value decision abstract select match specify evaluatenorm
Slide 209
Assessment: method control while new-solution
abstract(case-description -> abstracted-case) do
case-description := abstracted-case; end while
specify(abstracted-case -> norms); repeat select(norms ->
norm); evaluate(abstracted-case + norm -> norm-value);
evaluation-results := norm-value union evaluation- results; until
has-solution match(evaluation-results -> decision);
Slide 210
Assessment control: UML notation abstract specify norms select
norm match decision evaluate norm [more abstractions] [no more
abstractions] [match fails no decision] [match succeeds: decision
found]
Slide 211
Assessment: method variations norms might be case-specific cf.
housing application case abstraction may not be needed
knowledge-intensive norm selection random, heuristic, statistical
can be key to efficiency sometimes dictated by human expertise only
acceptable if done in a way understandable to experts
Slide 212
Assessment: domain schema
Slide 213
Claim handling forunemployment benefits
Slide 214
Decision rules for claim handling
Slide 215
Diagnosis find fault that causes system to malfunction example:
diagnosis of a copier terminology: complaint/symptom, hypothesis,
differential, finding(s)/evidence, fault nature of fault varies
state, chain, component should have some model of system behavior
default method: simple causal model sometimes reduced to
classification task direct associations between symptoms and faults
automation feasible in technical domains
Slide 216
Diagnosis: causal covering method Find candidate causes
(hypotheses) for the complaint using a causal network Select a
hypothesis Specify an observable for this hypothesis and obtain its
value Verify each hypothesis to see whether it is consistent with
the new finding Continue this process until a single hypothesis is
left or no more observables are available
Slide 217
Diagnosis:inference structure
Slide 218
Diagnosis: method control while new-solution cover(complaint
-> hypothesis) do differential := hypothesis add differential;
end while repeat select(differential -> hypothesis);
specify(hypothesis -> observable); obtain(observable ->
finding); evidence := finding add evidence; foreach hypothesis in
differential do verify(hypothesis + evidence -> result); if
result = false then differential := differential subtract
hypothesis until length differential =< 1 or no observables left
faults := hypothesis;
Slide 219
Diagnosis: method variations inclusion of abstractions
simulation methods see literature on model-based diagnosis library
of Benjamins
Slide 220
Diagnosis: domain schema
Slide 221 no explanation often: coupling monitoring and
diagnosis output monitoring is input diagnosis">
Monitoring analyze ongoing process to find out whether it
behaves according to expectations terminology: parameter, norm,
discrepancy, historical data main features: dynamic nature of the
system cyclic task execution output "just" discrepancy => no
explanation often: coupling monitoring and diagnosis output
monitoring is input diagnosis
Slide 222
Monitoring:data-driven method Starts when new findings are
received For a find a parameter and a norm value is specified
Comparison of the find with the norm generates a difference
description This difference is classified as a discrepancy using
data from previous monitoring cycles
Monitoring: method variations model-driven monitoring system
has the initiative typically executed at regular points in time
example: software project management classification function
treated as task in its won right apply classification method add
data abstraction inference
Slide 226
Prediction analytic task with some synthetic features analyses
current system behavior to construct description of a system state
at future point in time. example: weather forecasting often
sub-task in diagnosis also found in knowledge-intensive modules of
teaching systems e.g. for physics. inverse: retrodiction: big-bang
theory
Slide 227
Synthesis Given a set of requirements, construct a system
description that fulfills these requirements
Slide 228
Ideal synthesis method Operationalize requirements preferences
and constraints Generate all possible system structures Select
sub-set of valid system structures obey constraints Order valid
system structures based on preferences
Slide 229
Synthesis:inference structure
Slide 230
Design synthetic task system to be constructed is physical
artifact example: design of a car can include creative design of
components creative design is too hard a nut to crack for current
knowledge technology sub-type of design which excludes creative
design => configuration design
Slide 231
Configuration design given predefined components, find assembly
that satisfies requirements + obeys constraints example:
configuration of an elevator; or PC terminology: component,
parameter, constraint, preference, requirement (hard & soft)
form of design that is well suited for automation computationally
demanding
Slide 232
Elevator configuration: knowledge base reuse
Slide 233
Configuration:propose & revise method Simple basic loop:
Propose a design extension Verify the new design, If verification
fails, revise the design Specific domain-knowledge requirements
revise strategies Method can also be used for other synthetic tasks
assignment with backtracking skeletal planning
Slide 234
Configuration: method decomposition
Slide 235
Configuration: method control operationalize(requirements ->
hard-reqs + soft-reqs); specify(requirements ->
skeletal-design); while new-solution propose(skeletal-design +
design +soft-reqs -> extension) do design := extension union
design; verify(design + hard-reqs -> truth-value + violation);
if truth-value = false then critique(violation + design ->
action-list); repeatselect(action-list -> action); modify(design
+ action -> design); verify(design + hard-reqs -> truth-value
+ violation); until truth-value = true; end while
Slide 236
Configuration: method variations Perform verification plus
revision only when for all design elements a value has been
proposed. can have a large impact on the competence of the method
Avoid the use of fix knowledge Fixes are search heuristics to
navigate the potentially extensive space of alternative designs
alternative: chronological backtracking
Slide 237
Configuration: domain schema
Slide 238
Types of configuration may require different methods Parametric
design Assembly is largely fixed Emphasis on finding parameter
values that obey global constraints and adhere to preferences
Example: elevator design Layout Component parameters are fixed
Emphasis on constructing assembly (topological relations) Example:
mould configuration Literature: Motta (1999), Chandrasekaran
(1992)
Slide 239
Assignment create mapping between two sets of objects
allocation of offices to employees allocation of airplanes to gates
mapping has to satisfy requirements and be consistent with
constraints terminology subject, resource, allocation can be seen
as a degenerative form of configuration design
Slide 240
Assignment: method without backtracking Order subject
allocation to resources by selecting first a sub-set of subjects If
necessary: group the subjects into subject- groups for joint
resource assignment requires special type of constraints and
preferences Take an subject(-group) and assign a resource to it.
Repeat this process until all subjects have a resource
Slide 241
Assignment:inference structure
Slide 242
Assignment:method control while not empty subjects do
select-subset(subjects -> subject-set); while not empty
subject-set do group(subject-set -> subject-group);
assign(subject-group + resources + current- allocations ->
resource); current-allocations := union current-allocations;
subject-set := subject-set/subject-group; resources :=
resources/resource; end while subjects := subjects/subject-set; end
while
Slide 243
Assignment: method variations Existing allocations additional
input subject-specific constraints and preferences see synthesis
and configuration-design
Slide 244
Planning shares many features with design main difference:
"system" consists of activities plus time dependencies examples:
travel planning; planning of building activities automation only
feasible, if the basic plan elements are predefined consider use of
the general synthesis method (e.g therapy planning) or the
configuration- design method
Slide 245
Planning method
Slide 246
Scheduling Given a set of predefined jobs, each of which
consists of temporally sequenced activities called units, assign
all the units to resources at time slots production scheduling in
plant floors Terminology: job, unit, resource, schedule Often done
after planning (= specification of jobs) Take care: use of terms
planning and scheduling differs
Slide 247
Scheduling:temporal dispatching method Specify an initial
schedule Select a candidate unit to be assigned Select a target
resource for this unit Assign unit to the target resource Evaluate
the current schedule Modify the schedule, if needed
Slide 248
Scheduling: inference structure
Slide 249
Scheduling: method control specify(jobs -> schedule); while
new-solution select(schedule -> candidate-unit) do
select(candidate-unit + schedule -> target-resource);
assign(candidate-unit + target-resource -> schedule);
evaluate(schedule -> truth-value); if truth-value = false then
modify(schedule -> schedule); end while
Slide 250
Scheduling: method variations Constructive versus repair method
Refinement often necessary see scheduling literature catalog of
Hori (IBM Japan)
Modeling included for completeness "construction of an abstract
description of a system in order to explain or predict certain
system properties or phenomena" examples: construction of a
simulation model of nuclear accident knowledge modeling itself
seldom automated => creative steps exception: chip modeling
Slide 253
In applications: typical task combinations monitoring +
diagnosis Production process monitoring + assessment Nursing task
diagnosis + planning Troubleshooting devices classification +
planning Military applications
Slide 254
Example: apple-pest management
Slide 255
Comparison with O-O analysis Reuse of functional descriptions
is not common in O-O analysis notion of functional object But: see
work on design patterns strategy patterns templates are patterns of
knowledge- intensive tasks Only real leverage from reuse if the
patterns are limited to restricted task types
Slide 256
Ontology Engineering Ontology Development
Slide 257
What Is An Ontology? An ontology is an explicit description of
a domain: concepts properties and attributes of concepts
constraints on properties and attributes Individuals (often, but
not always) An ontology defines a common vocabulary a shared
understanding
Slide 258
Ontology Examples Taxonomies on the Web Yahoo! categories
Catalogs for on-line shopping Amazon.com product catalog
Domain-specific standard terminology Unified Medical Language
System (UMLS) UNSPSC - terminology for products and services Common
Information Model (CIM)- A semantic model describing the components
of a power system at an electrical level and the relationships
between each component
Slide 259
What Is Ontology Engineering? Defining terms in the domain and
relations among them Defining concepts in the domain (classes)
Arranging the concepts in a hierarchy (subclass-superclass
hierarchy) Defining which attributes and properties (slots) classes
can have and constraints on their values Defining individuals and
filling in slot values
Slide 260
Why Develop an Ontology? To share common understanding of the
structure of information among people among software agents To
enable reuse of domain knowledge to avoid re-inventing the wheel to
introduce standards to allow interoperability
Slide 261
Why Develop an Ontology? To make domain assumptions explicit
easier to change domain assumptions (consider a genetics knowledge
base) easier to understand and update legacy data To separate
domain knowledge from the operational knowledge re-use domain and
operational knowledge separately (e.g., configuration based on
constraints)
Slide 262
Backbone of Other systems Ontologies Software agents Problem-
solving methods Domain- independent applications Databases Declare
structure Knowledge bases Provide domain description
Slide 263
Ontology Development Process Determine the domain and scope of
the ontology Consider reusing existing ontologies Enumerate
important terms in the ontology Define the classes and the class
hierarchy Define the properties of classesslots Define the facets
of the slots Create instances Ontology Development 101: A Guide to
Creating Your First Ontology
Slide 264
Pizza Domain The special Provolone Onion Olive Oil DMRs
Contains Offers Made by
Slide 265
Competency Questions Which styles should I consider when
choosing a pizza? Is a Sicilian pizza a tomato or olive oil base?
Does tuna go well with pepperoni? What is the best choice of pizza
for a vegetarian? Which characteristics of a pizza affect its
appropriateness for a party? Does the flavor of an ingredient
change with the base? What were good toppings for a thick
crust?
Slide 266
Consider Reuse Why reuse other ontologies? to save the effort
to interact with the tools that use other ontologies to use
ontologies that have been validated through use in
applications
Slide 267
What to Reuse? Ontology libraries DAML ontology library
(www.daml.org/ontologies) Ontolingua ontology library
(www.ksl.stanford.edu/software/ontolingua/) Protg ontology library
(protege.stanford.edu/plugins.html) Upper ontologies IEEE Standard
Upper Ontology (suo.ieee.org) Cyc (www.cyc.com) General ontologies
DMOZ (www.dmoz.org) WordNet (www.cogsci.princeton.edu/~wn/)
Domain-specific ontologies UMLS Semantic Net GO (Gene Ontology)
(www.geneontology.org)www.geneontology.org CIM
Slide 268
Enumerate Important Terms What are the terms we need to talk
about? What are the properties of these terms? What do we want to
say about the terms?
Slide 269
Define Classes and the Class Hierarchy A class is a concept in
the domain a class of pizzas a class of pizza shops a class of
ingredients A class is a collection of elements with similar
properties Instances of classes the pizza you will have for
lunch
Slide 270
Class Inheritance Classes usually constitute a taxonomic
hierarchy (a subclass- superclass hierarchy) A class hierarchy is
usually an IS-A hierarchy: an instance of a subclass is an instance
of a superclass If you think of a class as a set of elements, a
subclass is a subset
Slide 271
Class Inheritance - Example Mushroom is a subclass of Topping
Every Mushroom is an Topping Green-pepper is a subclass of
Vegetable Every green-pepper is a vegetable Provolone is a subclass
of Cheese Every Provolone is a Cheese What should be the
specification? The Kind? The hunk-of?
Slide 272
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
define the more salient concepts first and then generalize and
specialize them
Slide 273
Documentation Classes (and slots) usually have documentation
Describing the class in natural language Listing domain assumptions
relevant to the class definition Listing synonyms Documenting
classes and slots is as important as documenting computer code
Slide 274
Define Properties of Classes Slots Slots in a class definition
describe attributes of instances of the class and relations to
other instances Each Pizza will have crust, sauce, and toppings.
Necessary conditions? Necessary and sufficient? Sufficient?
Slide 275
Properties (Slots) Types of properties intrinsic properties:
Crust, sauce, extrinsic properties: name, price, parts: ingredients
for a pizza relations to other objects: pizza store, customer,
Simple and complex properties simple properties (attributes):
contain primitive values (strings, numbers) complex properties:
contain (or point to) other objects (e.g., a pizza instance)
Slide 276
Slot and Class Inheritance A subclass inherits all the slots
from the superclass If a topping has a name and a cost, a cheese
also has a name and flavor If a class has multiple superclasses, it
inherits slots from all of them Use great care!!
Slide 277
Property Constraints Property constraints (facets) describe or
limit the set of possible values for a slot The name of a pizza is
a string The pizza producer is an instance of PizzaShop A PizzaShop
has exactly one location
Slide 278
Common Facets Slot cardinality the number of values a slot has
Slot value type the type of values a slot has Minimum and maximum
value a range of values for a numeric slot Default value the value
a slot has unless explicitly specified otherwise
Slide 279
Common Facets: Slot Cardinality Cardinality Cardinality N means
that the slot must have N values 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 greater
than 1 means that the slot can have more than one value
(multiple-valued slot)
Slide 280
Common Facets: Value Type String: a string of characters (The
Special) Number: an integer or a float (15, 4.5) Boolean: a
true/false flag Enumerated type: a list of allowed values (high,
medium, low) Complex type: an instance of another class Specify the
class to which the instances belong The Pizza class is the value
type for the slot produces at the PizzaShop class
Slide 281
Domain and Range of Slot Domain of a slot the class (or
classes) that have the slot More precisely: class (or classes)
instances of which can have the slot Range of a slot the class (or
classes) to which slot values belong
Slide 282
Facets and Class Inheritance A subclass inherits all the slots
from the superclass A subclass can override the facets to narrow
the list of allowed values Make the cardinality range smaller
Replace a class in the range with a subclass Pizza The Special
PizzaShop DMRs is-a producer
Slide 283
Create Instances Create an instance of a class The class
becomes a direct type of the instance Any superclass of the direct
type is a type of the instance Assign slot values for the instance
frame Slot values should conform to the facet constraints
Knowledge-acquisition tools often check that
Slide 284
Asset Categorization Power Distribution Network Asset
Categorization
Slide 285
Development Process Defining purpose, domain and scope
Performing competency questioning and informal describing of domain
knowledge Analyzing to capture concepts and properties Considering
of reuse of existing ontology, i.e. CIM, and mapping concepts into
CIM Modeling asset classes and relationships Verifying of
interchangeability, expressivity, reusability, extensibility and
integrateability
Slide 286
Purpose, Domain and Scope The purpose is to facilitate the
determination of risks, costs and socials factors associated with
the implementation of power distribution network The domain
encompass the medium voltage (MV) distribution feeder including
network components, network operation, and operational environment.
The scope is limited to capture information that aids determining
risks, costs and socials factors involved with distribution
feeder.
Slide 287
Elicitation of Domain Knowledge The competency questions are
formed and asked, and Then human experts are thus interviewed and
concerning documents are researched to elaborate informal
description about the domain, i.e. MV distribution feeder. ows some
of the domain informal description elicited from the experts.
Slide 288
Domain Informal Description: Example What is power distribution
network? It is a part of power system. It distributes electric
energy from main substation to distribution substations and
transformers. It situates in diverse landscapes and environments.
It runs along public road. It also runs through field and forest.
It can be overhead or underground construction or combination of
both. Overhead power line is placed above ground with appropriate
clearance from nearby structures and trees. Underground power line
is placed under ground with some kind of protection. Undergr