Foundations; information modeling

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): • http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools • Concept, topic, subject maps!! (try searching) • http://cmap.ihmc.us

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 • 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. The first Global Change Information System use case

9. A conceptual model of the 1st use case 9

10. A Conceptual model of the use case Logical model, i.e. Classes and properties from the use case 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 11

12. Example use case 1b • 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. The first Global Change Information System use case

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 indexconstruction, 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: • http://tw.rpi.edu/web/InformationModels

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.