1. Foundations; information modeling
Peter Fox
Xinformatics – ITEC, CSCI, ERTH 4400/6400
Module 6a, March 8, 2016

2. Contents Review of any reading Information modeling Assignment 4
Next module
Information Architecture

3. Semiotic model

4. How to “know” what to model?

5. Meta-modeling -> Mindmaps

6. Some tools
For use case development – simple graphics tools, e.g. graffle
Mindmaps, e.g. Freemind
For modeling (esp. UML if you like it):
Concept, topic, subject maps!! (try searching)

7. Information Models – 3 levels (ANSI)
Conceptual models, sometimes called domain models, are typically used to explore domain concepts and often created
as part of initial requirements envisioning efforts as they are used to explore the high-level static business or science or medical or …. structures and concepts
Followed by logical and physical models

8. Example use case 1 The first Global Change Information System use case
Title: Visit data center website of dataset used to generate a report figure
Actor and system: A reader of the National Climate Assessment
Flow of interactions: A reader wishes to identify the source of the data used to produce a particular figure in the NCA. A reference to the paper in which the image contained in this figure was originally published appears in the figure caption. Clicking that reference displays a page of metadata information about the paper, including links to the datasets used in that paper. Pursuing each of those links presents a page of metadata information about the dataset, including a link back to the agency/data center web page describing the dataset in more detail and making the actual data available for order or download.

9. A conceptual model of the 1st use case
Ontology engineering differs from database schema modeling in that ontologies do not pertain to specific use cases
Using “gcis:Publication” instead of “gcis:Paper” in the result of the first use case reflects the former aspect. For the latter, we developed and analyzed more use cases to enrich the ontology 9

10. A Conceptual model of the use case
Logical model, i.e. Classes and properties from the use case
Ontology engineering differs from database schema modeling in that ontologies do not pertain to specific use cases
Using “gcis:Publication” instead of “gcis:Paper” in the result of the first use case reflects the former aspect. For the latter, we developed and analyzed more use cases to enrich the ontology 10

11. An intuitive concept map of the use case
From a conceptual model to a logical model (ontology):
A defined class or property should be meaningful and robust enough to meet the requirements of various use cases
An ontology can be extended by adding classes and properties recognized from new use cases via iteration
Classes and properties recognized from the use case
Ontology engineering differs from database schema modeling in that ontologies do not pertain to specific use cases
Using “gcis:Publication” instead of “gcis:Paper” in the result of the first use case reflects the former aspect. For the latter, we developed and analyzed more use cases to enrich the ontology 11

12. Example use case 1b
The first Global Change Information System use case
Title: Find data used to generate a report figure
Actor and system: A reader of the National Climate Assessment
Flow of interactions: A reader wishes to identify the source of the data used to produce a particular figure in the NCA. A reference to the paper in which the image contained in this figure was originally published appears in the figure caption. Clicking that reference displays a page of metadata information about the paper, including links to the datasets used in that paper. Pursuing each of those links presents a page of metadata information about the dataset, including a link back to the agency/data center web page describing the dataset in more detail and making the actual data available for order or download.

13. A Conceptual model of the use case
Logical model, i.e. Classes and properties from the use case 13

14. Logical models
A logical entity-relationship model is provable in the mathematics of data science.
Given the current predominance of relational databases, logical models generally conform to relational theory.
Thus a logical model contains only fully normalized entities.
Some of these may represent logical domains rather than potential physical tables.

15. Other use cases
Identify roles of people in the generation of a chapter in the 3rd US National Climate Assessment
Provide provenance (who, what, when, where, why, how) tracing of NASA contributions to Figure 1.2 in 3rd US National Climate Assessment
Etc.

16. Information models - bad
It's very easy to tell when an information system you're trying to navigate has no underlying Information Model. Tell-tale characteristics:
You can't tell how to get from the home page to the information you're looking for.
You click on a promising link and are unpleasantly surprised at what turns up.
You keep drilling down into the information layer after layer until you realize you're getting farther away from your goal rather than closer.
Every time you try to start over from the home page, you end up in the same wrong place.
You scroll through a long alphabetic list of all the articles ever written on a particular subject with only the title to guide you.

17. Information models – good
Oddly enough, you generally don't notice a well-conceived Information Model because it simply doesn't get in your way….
On the main page, you notice promising links right away.
Two or three clicks get you to exactly what you wanted.
The information seems designed just for you because someone has anticipated your needs.
You can read a little or ask for more - the cross-references are in the right places.
Right away you feel that you're on familiar ground - similar types of information start looking the same.

18. Physical models
A physical model is a single logical model instantiated in a specific information system (e.g., relational database schema, RDF/XML document, etc.) in a specific installation.
The physical model specifies implementation details which may be features of a particular product or version, as well as configuration choices for that instance.

19. Physical models
E.g. for a database, these could include index construction, alternate key declarations, modes of referential integrity (declarative or procedural), constraints, views, and physical storage objects such as tablespaces.
E.g. for RDF/XML, this would include namespaces, declarative relations, etc.

20. Object oriented design
Object-oriented modeling is a formal way of representing something in the real world (draws from traditional set theory and classification theory). Some basics to keep in mind in object-oriented modeling are that:
Instances are things.
Properties are attributes.
Relationships are pairs of attributes.
Classes are types of things.
Subclasses are subtypes of things.

21. Object model
Class: a means of grouping all the objects which share the same set of attributes and methods.
an object must belong to only one class as an instance of that class (instance-of relationship).
a class is similar to an abstract data type.
Class hierarchy and inheritance: derive a new class (subclass) from an existing class (superclass)
subclass inherits all the attributes and methods of the existing class and may have additional attributes and methods
single inheritance (class hierarchy) vs. multiple inheritance (class lattice).

22. Core object models consist of:
object and object identifier: any real world entity is uniformly modeled as an object (associated with a unique id: used to pinpoint an object to retrieve).
attributes and methods: every object has a state (the set of values for the attributes of the object) and a behavior (the set of methods - program code - which operate on the state of the object).
the state and behavior encapsulated in an object are accessed or invoked from outside the object.

23. For example for relational DBs
Feature Conceptual Logical Physical
Entity Names ✓ ✓  
Entity Relationships ✓ ✓  
Attributes   ✓  
Primary Keys   ✓ ✓
Foreign Keys   ✓ ✓
Table Names     ✓
Column Names     ✓
Column Data Types     ✓

24. Information Modeling
Conceptual
Logical
Physical

25. More examples at:

26. Steps in modeling Identify objects (entity) and their types
Identify attributes
Apply naming conventions
Identify relationships
Apply model patterns (if known)
Assign relationships
Normalize to reduce redundancy (this is called refactoring in software engineering)

27. Exercise!

28. Not just an isolated set of models
Most important for handling errors, evolution, extension, restriction, … and where do we do that?
To the physical model? NO
To the logical model? MAYBE
To the conceptual model? YES IF POSSIBLE
You will see why in the next module

29. Not just an isolated set of models
They relate to and/ or integrate with other information models:
General rule – integrate at the highest level you can (i.e. more abstract -> conceptual)
Remember the cognitive aspects! Truth <intersect> Belief ~ Knowledge
Less detail is easier to understand

30. Questions?
Information Modeling and relation to semiotics?

31. Assignments
Assignment 4: Construction an information model and preliminary information architecture/ discussion of design issues of <your> use case from Assignment 1/ 2.
Due on Mar 29th
Project Assignment will be available ~ Mar 22nd.