Presentation is loading. Please wait.

Presentation is loading. Please wait.

04/12/07Next Generation Info Models1 Information Models as a Basis for Ontologies Ed Barkmeyer, NIST Ontolog Forum, April, 2007.

Similar presentations

Presentation on theme: "04/12/07Next Generation Info Models1 Information Models as a Basis for Ontologies Ed Barkmeyer, NIST Ontolog Forum, April, 2007."— Presentation transcript:

1 04/12/07Next Generation Info Models1 Information Models as a Basis for Ontologies Ed Barkmeyer, NIST Ontolog Forum, April, 2007

2 04/12/07Next Generation Info Models2 Outline Overview of information modeling Features of information modeling Comparison to features of OWL Information modeling methodology Conclusions

3 04/12/07Next Generation Info Models3 History Linked record models (1968) –CODASYL standard (1974), Navigational Data Model (1980) E.F.Codd: Relational Algebra (1970) Peter Chen: Entity Attribute Relationship Models (1976) ISO TR 8002: 1984 the Conceptual schema and the information base 1980s information modeling technologies –IDEF1-X, SDM, NIAM/ORM, SSADM, EXPRESS, etc. 1990s object modeling technologies (UML) Frame-based logics (1975-1995) Description logics (1985-present): DAML, OWL

4 04/12/07Next Generation Info Models4 Differences in Nature Navigational and relational models –relate data to data –relational normal forms model functions of keys Information models –relate things (entities) to other things –relate things to information about them –use classifiers to collect properties Ontologies –relate things to things –relate things to information about them –use information to classify things

5 04/12/07Next Generation Info Models5 Differences in Purpose Data models –support software implementations of business processes –organize information for access –describe instances Information models –support sets of business processes –organize information for comprehension –support design of databases and messages –use classifications to describe instances Ontologies –support retrieval of information using inferencing –organize information for relevance –describe subjects and categories by classifications

6 04/12/07Next Generation Info Models6 Differences in Concept Information models –universe is things used by the business processes –classification/axioms are as used by the business business rules, not accepted scientific truth –distinguish conceptual schema = invariants, quantified assertions from the information base = current assertions about individual things Ontologies –universe is all things that may be encountered in a domain –classification/axioms are accepted truth in the domain –primarily quantified assertions with a few ground facts –distinguished from an information base for some practical uses

7 04/12/07Next Generation Info Models7 Common Ideas Universe is a set of things of interest Classification enables understanding of the universe Axioms (invariants, necessities) but with a different concept of truth Ground facts = axiomatic truths about instances conceptual schema is nearly monotonic current/transient facts restricted to the information base

8 04/12/07Next Generation Info Models8 Outline Overview of information modeling Features of information modeling Comparison to features of OWL Information modeling methodology Conclusions

9 04/12/07Next Generation Info Models9 Information Modeling: Classifiers Entity type classifies things in the universe –a template for capturing (current) information about things –a model of the state of a thing –identity is distinct from state –domain of properties Value type classifies information about things –instance is an information unit, a data element –can be a structure of component data elements –identity is state (state is invariant) –only range of properties (its properties proceed from its identity) Data type represents Value types –instance is a computational data value

10 04/12/07Next Generation Info Models10 Information modeling: Subtypes Subtype relationships among classifiers –S is a subtype (subclass) of E iff every s in class S is also an instance of E –multiple supertypes: S is a subtype of E 1,..., E n Exclusion relationships –if t is an instance of E then t is not an instance of D Covering relationships –E is covered by S 1,..., S n iff e in E implies there exists at least 1 k such that e is in S k –Mutually exclusive coverings are partitions –abstract type = a type that is covered by some set of subtypes

11 04/12/07Next Generation Info Models11 Information Modeling: Class definition Union (choice, select) types –Class E is the union of classes F and G and... E(x) == F(x) OR G(x) –Union types are abstract by construction Intersection –Class E is the intersection of classes F and G E(x) == F(x) AND G(x) Relative complement –if S is a subtype of E, C is the relative complement iff C = E – S

12 04/12/07Next Generation Info Models12 Classification Entity classes can represent roles or states of things –no notion of intrinsic properties –models contain intrinsic classifiers, e.g., maximal superclasses but languages dont identify them A thing can be an instance of multiple entity types –the entity types need not be explicitly related Default relationship among subtypes is overlaps –a thing can be instance of both A thing can change classification over time –thing is instance of class is just part of the state of thing Most of these concepts not supported by object models

13 04/12/07Next Generation Info Models13 Aside: Value Types Value type = conceptual classifier for information unit Categories –name (referencer, supports equal/unequal) enumerated lists codes/identifiers taken from registries strings intended to identify things –quantity includes numbers and values with dimensions –quantitative name (names that support quantitative operations) ordinal, date, time, time period, temperature, etc. –truth value –text (structured and unstructured) a body of information interpreted by a specific agent

14 04/12/07Next Generation Info Models14 Information Modeling: Properties Attributes (data type properties) –domain is entity, range is value Relationships (object properties, associations) –domain is entity, range is entity Inverse relationship –same relationship, nominal domain and range reversed –different reading (spelling of the relationship name) Multiplicity/cardinality of attributes and relationships –one entity can have the same property (type) 0, 1, n, unbounded times –distinguish set of the same property from property whose range is a set

15 04/12/07Next Generation Info Models15 Property domains Domain and range of a property must be a single class –Name of a property implicitly qualified by the domain Ad hoc supertypes (union type) may be created to be domain or range –enumerate the entity types constituting the domain, or –enumerate the entity types constituting the range, or –(rarely) enumerate the value types constituting the range Mutable and immutable properties –a property P(e, v) is mutable if the value v associated with a given e may change over time –P(e,v) is immutable if P(e,x) implies x=v over all time

16 04/12/07Next Generation Info Models16 Property Relationships Property implies property –(there exists v such that P(d,v)) implies (there exists x such that Q(d,x)) Property excludes property –(there exists v such that P(d,v)) implies NOT (there exists x such that Q(d,x)) Properties P 1,..., P n cover entity type –For every instance e of E there exists some i such that there exists v such that P i (e,v)

17 04/12/07Next Generation Info Models17 Relationship Relationships Relationship implies/subsets relationship (pairwise) –P(x,y) implies Q(x,y) –every pair (x,y) that satisfies P also satisfies Q Relationship excludes relationship (pairwise) –P(x,y) implies NOT Q(x,y) Relationship refines/subtypes relationship –property P is a specialization of property Q –every instance of P is an instance of Q –not just implication

18 04/12/07Next Generation Info Models18 Examples Property implies property –x is an officer of ship S implies there exists officer y such that x reports to y Property excludes property –x is employee of G implies NOT x is eligible for prize p Relationship implies/subsets relationship (pairwise) –x is an officer of ship S implies x has cabin on S Relationship excludes relationship (pairwise) –x is an officer of ship S implies NOT x is passenger on S Relationship refines/subtypes relationship –x is captain of ship S refines x is officer of ship S

19 04/12/07Next Generation Info Models19 Qualifying Properties Qualifying property –a property whose existence or value determines membership in a given subtype –existence: If there exists y such that Q(d,y) then d is an instance of S –value: If Q(d, red) then d is an instance of S –functional value: Let y = Q(d); if Greater(y, 1) then d is an instance of S –the domain (D) of property Q must be a supertype of S Q may be optional (cardinality 0.. ) on D

20 04/12/07Next Generation Info Models20 Derived Properties Derived Property: a property created by joining relationships –represented by a path through the semantic network Example: –vehicle and model are entity types –weight is a value type (a quantity) –attribute: model-has-gross-weight(model, weight) –relationship: vehicle-has-model(vehicle, model) –derived property: vehicle-has-gross-weight(vehicle, weight) = vehicle.vehicle-has-model[model].model-has-gross-weight[weight] = { (vehicle, weight) : (exists m) (and vehicle-has-model(vehicle,m) model-has-gross-weight(m,weight)) }

21 04/12/07Next Generation Info Models21 Information Modeling: Identifiers Identifiers/keys distinguish instances of an entity class –simple key: a property whose inverse is functional for each v in the range, there exists at most 1 d in the domain such that P(d,v) almost always an attribute (value type) –relative uniqueness property P is unique within property Q for each p in the range of P and each q in the range of Q, there exists at most 1 d in the domain such that P(d,p) AND Q(d,q) p is usually a value, and q is usually an entity such that for each d there exists exactly 1 q such that Q(d,q) selection of a key for q gives rise to a composite key for d by concatenating (making a tuple of) the keys –a key property must apply to all things in the class –a given entity class may have multiple identifier/key properties

22 04/12/07Next Generation Info Models22 Dependencies Entity type E is dependent on property P(e,x) iff (exists e)E(e) implies (exists x)P(e,x) –that is, the e cannot exist unless the x exists –a meta-property of a relationship between instances sometimes modeled as dependent on class X in IDEF1-X, E is a weak entity type and P supports E –not all mandatory properties are dependencies –dependency is an intrinsic property –dependency is an invariant property: the x never changes Example –course-has-section(course, section) has inverse section-of-course(section, course) –section is dependent on section-of-course the section cannot meaningfully exist without the course

23 04/12/07Next Generation Info Models23 Aggregates Entity type E aggregates property P(e,m) iff every instance e of E is a collection and P(e,m) is the relationship of e to its members –aggregate is a metaproperty of E that is based on P –P is a logical or virtual part of relationship Problem: e is only instantaneously a set –the identity of e does not change if a member is deleted –no axiom is associated with this metaproperty Example: –Entity type Convoy, with property convoy-includes-ship(c,s) Convoy aggregates convoy-includes-ship by extension, Convoy is aggregation of Ship

24 04/12/07Next Generation Info Models24 Composition Entity type E is composed by properties P i (e,c i ) iff –each instance e of E is constructed from the c i such that P i (e,c i ) –each P i relates an instance e to one (or more) of its components –for each i, there are n distinct c i such that P i (e,c i ), where n is the minimum cardinality of p (otherwise e is not an instance of E) –for each c i such that P i (e,c i ), if P i (x,c i ) then x = e (a c i belongs to at most one e) –some models make the c i dependent on the inverse of P i –composite is a metaproperty of E that is based on the P i –each P i is a physical part of relationship Example –entity type Book is composed by book-has-chapter(b, c)

25 04/12/07Next Generation Info Models25 Validity Rules Validity Rule = arbitrary first-order logic expression involving instances, classifiers and properties that must hold in a valid information base Languages have limitations on expressibility –instance references –existentials –special functions –nature of comparisons NOT inferencing rules –cannot conclude x should be classified as an instance of E conclusion E(x) means invalid information base if NOT E(x)

26 04/12/07Next Generation Info Models26 Aside: Object Modeling –Ad hoc models of state properties needed for some set of software applications Object is to design software programs –Object templates (class models) –Attributes, Relationships (associations, pointers) –Superclasses and inheritance –Validity rules –Operations = actions on the object state No real association to process –No keys, no qualifiers

27 04/12/07Next Generation Info Models27 Some known Issues Diverse keys for union types –identity of individuals determined by type and type-specific keys Variance of cardinality constraints over time/state –can be stated as validity rules (only) Intermediate states (transactions) –validity rules dont apply while the info base is in transition during certain times in a process Localization of properties –subtype A always has property P, subtypes B and C never do –model property P local to A? –model optional property P to common supertype S, and use its existence to define (qualify) subtype A

28 04/12/07Next Generation Info Models28 Outline Overview of information modeling Features of information modeling Comparison to features of OWL Information modeling methodology Conclusions

29 04/12/07Next Generation Info Models29 OWL Features – Classification Classification –Entity typeClass –Value typeClass enumerationY (all values from) nameN (datatype string) textN (datatype string) quantitiesN (numeric datatypes) truth valuesY –Data typeY –Multiple classificationY –Default overlapY –Classification changenot applicable

30 04/12/07Next Generation Info Models30 OWL Features – Type relationships Type relationships –subtypeY –multiple supertypesY –exclusionY –coveringY –relative complementComplement, Difference –choice/unionY –intersectionY

31 04/12/07Next Generation Info Models31 OWL Features -- Properties Properties –AttributesDatatype property –RelationshipsObject property –InverseY –Multiplicity/CardinalityY –Set of property instancesY –Single domain, rangeY –Mutable propertynot applicable

32 04/12/07Next Generation Info Models32 OWL Features -- Metaproperties Property relationships –Property implies property Y –Property excludes propertyY –Properties cover entity typeN? –Relationship implies relationshipY –Relationship excludes relationshipY –Relationship refines relationshipN (only implies) Derived propertiessome Identifiersfunctional property DependenciesN Part of, Aggregates, CompositesN

33 04/12/07Next Generation Info Models33 OWL Features – Definitions and Rules Qualifying propertiesClass definition –based on presenceY –based on value equalY –based on function of valueN Validity rulesN NInferencing rules

34 04/12/07Next Generation Info Models34 OWL as Info Modeling Language OWL has all the major features OWL is formally defined –other information modeling languages have formal models ascribed to them after the fact (not standard interpretations) OWL has formal classification inferencing –but it is not much stronger than languages like ORM –not even strong in datatype reasoning OWL needs: –Identifier/Key metaproperties – identification of individuals –Relative uniqueness rules –Validity rules

35 04/12/07Next Generation Info Models35 Outline Overview of information modeling Features of information modeling Comparison to features of OWL Information modeling methodology Conclusions

36 04/12/07Next Generation Info Models36 Information Analysis Approach Interview –obtain initial information from the experts Formalize –formally capture what the experts said Design –reorganize the formal model to provide insight Review –walk the experts through the designed model –examine one or more use cases –solicit questions, concerns, variants Revise –correct the design to accommodate the clarifications

37 04/12/07Next Generation Info Models37 Information Analysis Method Identify the processes to be supported Identify the principal business classifications of things used/modified by the processes Identify the properties of those things that are used/modified by the processes Identify types, specializations and generalizations that collect uses and properties Determine type-to-type relationships Associate properties with the classifications Determine cardinality constraints Distinguish entity types from value types Identify the keys for individuals Specify validity rules Interview Formalize Design

38 04/12/07Next Generation Info Models38 Process Modeling Business Process Modeling –Activities and control flows –Decision points and rules –Process decomposition –Data/Message/Material flows –Information as documents –Languages: BPMN, ARIS, METIS,...

39 04/12/07Next Generation Info Models39 Binding process to information Actions of process on entities –creating an entity instance –creating a relationship instance between entity instances, usually as a property having a domain" (or subject") and a range" (or object") –changing one or more properties of an entity instance or relationship –destroying an entity instance –destroying a relationship instance –using a property of an entity instance

40 04/12/07Next Generation Info Models40 Relating Process to Info Requirements USE defines an information requirement All other actions define EVENTS –Process models can/should represent impact of events Use and Events can be aggregated or decomposed –Entity/Class level (UML) –Specific instance –Aspect (a collection of properties) –Property

41 04/12/07Next Generation Info Models41 Conclusions Emphasis on supported processes as driver –scopes the model in breadth and depth –orthogonal to semantic web concerns Model for understanding –model must be meaningful to the domain experts –correct formal interpretation is important –implementation is a separate engineering activity OWL language is strong –formal logic basis –almost all known features (necessary and optional) –identifiers are a critical concern –validity rules will be required

Download ppt "04/12/07Next Generation Info Models1 Information Models as a Basis for Ontologies Ed Barkmeyer, NIST Ontolog Forum, April, 2007."

Similar presentations

Ads by Google