Asset Categorization Asawin Rajakrom. Course Syllabus This course describes how the power...
Preview:
Citation preview
- Slide 1
- Asset Categorization Asawin Rajakrom
- Slide 2
- 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
- Slide 4
- Asset Categorization Categorization Principle &
Terminologies
- Slide 5
- 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:
- Slide 115
- RDF Syntax Example RDF Presentation Paul Miller
p.miller@ukoln.ac.uk
- Slide 116
- 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
- Slide 185
- Knowledge Acquisition Techniques (1) Interviewing Work
observation Commentary Protocol analysis Laddering Concept sorting
Repertory grid
- Slide 186
- 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
- Slide 223
- Monitoring: inference structure
- Slide 224
- Monitoring: method control receive(new-finding);
select(new-finding -> parameter) specify(parameter -> norm);
compare(norm + finding -> difference); classify(difference +
historical-data -> discrepancy); historical-data := finding add
historical-data;
- Slide 225
- 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)
- Slide 251
- Scheduling: typical domain schema
- Slide 252 creative steps exception: chip modeling">
- 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