1. The Ontology Spectrum & Semantic Models
Dr. Leo Obrst
MITRE
Information Semantics Group
Information Discovery & Understanding
Center for Innovative Computing & Informatics
November 28, 2006

2. Agenda Semantic Models: What & How to Decide?
Tightness of Coupling & Semantic Explicitness
Ontology and Ontologies
The Ontology Spectrum
Preliminary Concepts
Taxonomies
Thesauri
Conceptual Models: Weak Ontologies
Logical Theories: Strong Ontologies
Upper, Middle, Domain Ontologies
More: Logic Spectrum

3. Tightness of Coupling & Semantic Explicitness
Explicit, Loose
Far
Performance = k / Integration_Flexibility
EA Ontologies
From Synchronous Interaction to Asynchronous Communication
Application
Same Process Space
Same CPU
Same OS
Same Programming Language
Same Local Area Network
Same Wide Area Network Client-Server
Same Intranet
Compiling
Linking
Agent Programming
Web Services: SOAP
Distributed Systems OOP
Applets, Java
Semantic Brokers
Middleware Web
Peer-to-peer
N-Tier Architecture
Same
Address
Space
Same DBMS
Federated DBs
Data Warehouses
Data Marts
Workflow Ontologies
Semantic Mappings
XML, XML Schema
Conceptual Models
RDF/S, OWL
Web Services: UDDI, WSDL
OWL-S
Proof, Rules, Modal Policies: SWRL, FOL+
Enterprise Ontologies
EA Brokers
1 System: Small Set of Developers
Systems of Systems
Enterprise
Community
Internet EA
Semantics Explicitness
Data
SOA
EAI
The point of this slide is to show that we have evolved over time in information technology from tightly coupled systems to loosely coupled systems, primarily to deal with increasing heterogeneity and increasingly many kinds of heterogeneity. Correlated to that evolution is the need for increasingly more explicit semantics to deal with the heterogeneity.
Range is from lower left, very Tightly Coupled with very implicit semantics (local), to upper right, very loosely coupled with very explicit semantics (far): red and blue arrows from lower left to upper right.
Red font indicates the data constructs that have evolved over time in information technology to adjust to increasingly necessary loose coupling.
Blue font indicates the application constructs that have evolved over time in information technology to adjust to increasingly necessary loose coupling.
Green font (far right of graphic) indicates from bottom to top the evolution of the groups involved in dealing with the heterogeneity, from the original small set of developers creating one system with a couple applications or subprocedures and one database (where the developers can make implicit agreements as to the semantics, by nodding their heads that yes, this API and this database schema, means what we say it means), to systems of systems to enterprise level computing to the Internet. At the Internet level, we can’t all nod our heads and say, yes, this is what we mean. We need increasingly more explicit semantics, and that semantics needs to be increasingly more machine-interpretable.
Rationale for increasing loose-coupling: dealing with the heterogeneity forced on us over time in information technology. We have progressed from writing and executing programs in the same programming language on the same operating system on the same computer/CPU, in the same address space and same process space to a vast heterogeneous world, inventing new data and application constructs at each increase in heterogeneity. This increased heterogeneity forces us to adopt increasingly more explicit semantics to deal with it.
The two curves indicate different things. The Right Curve (From Synchronous Interaction to Asynchronous Communication) roughly characterizes the evolution from synchronous to asynchronous). The Left Curve (Performance = k / Integration_Flexibility) roughly demonstrates the inverse relationship between performance and integration flexibililty, i.e., tightly coupled systems generally have better performance than loosely coupled systems, but increasingly we need to emphasize integration flexibility over that performance, a tradeoff to deal with heterogeneity.
Local
Implicit, TIGHT
Looseness of Coupling

4. Ontology Spectrum: The Range of Semantic Models & a Migration Path
strong semantics
Modal Logic
First Order Logic
Logical Theory
Is Disjoint Subclass of with transitivity property
Description Logic
DAML+OIL, OWL
From less to more expressive
UML
Conceptual Model
Is Subclass of
RDF/S
Semantic Interoperability
XTM
Extended ER
Thesaurus
Has Narrower Meaning Than ER
DB Schemas, XML Schema
Structural Interoperability
Taxonomy
Is Sub-Classification of
Relational
Model, XML
Syntactic Interoperability
weak semantics 1

5. Ontology Spectrum: The Range of Semantic Models & a Migration Path
strong semantics
Modal Logic
First Order Logic
Problem: Very General
Semantic Expressivity: Very High
Problem: Local
Semantic Expressivity: Low
Problem: General
Semantic Expressivity: Medium
Semantic Expressivity: High
Logical Theory
Is Disjoint Subclass of with transitivity property
Description Logic
DAML+OIL, OWL
From less to more expressive
UML
Conceptual Model
Is Subclass of
RDF/S
Semantic Interoperability
XTM
Extended ER
Thesaurus
Has Narrower Meaning Than ER
DB Schemas, XML Schema
Structural Interoperability
Taxonomy
Is Sub-Classification of
Relational
Model, XML
Syntactic Interoperability
weak semantics 1

6. Ontology Spectrum: Application
Concept- based
Ontology
strong
Logical Theory
weak
Conceptual Model
Term- based
Thesaurus
Expressivity
Taxonomy
Synonyms, Enhanced Search (Improved Recall) & Navigation, Cross Indexing
Enterprise Modeling (system, service, data), Question-Answering (Improved Precision), Querying, SW Services
Real World Domain Modeling, Semantic Search (using concepts, properties, relations, rules), Machine Interpretability (M2M, M2H semantic interoperability), Automated Reasoning, SW Services
Categorization, Simple Search & Navigation, Simple Indexing
Application 1

7. Triangle of Signification
Intension
<Joe_ Montana >
Concepts
Semantics: Meaning
Reference/
Denotation
Sense
Real (& Possible)
World Referents
Terms
“Joe” + “Montana”
Syntax: Symbols
Pragmatics: Use
Extension

8. Term vs. Concept Term (terminology): Concept:
Natural language words or phrases that act as indices to the underlying meaning, i.e., the concept (or composition of concepts)
The syntax (e.g., string) that stands in for or is used to indicate the semantics (meaning)
Concept:
A unit of semantics (meaning), the node (entity) or link (relation) in the mental or knowledge representation model
Concept Vehicle
Term “Vehicle”
Concept Ground_Vehicle
Concept Automobile
Term “Automobile”
Term “Car”
Narrower than
Synonym
Term Relations
Subclass of
Concept Relations

9. Example: Metadata Registry/Repository – Contains Objects + Classification
Data Element
Taxonomy
Namespace
Class
Data Objects
Classification Objects
Terminology Objects
Meaning Objects
Data Attribute
Conceptual Model
Ontology
Thesaurus
XML DTD
XML Schema
Concept
Property
Relation
Attribute
Value
Instance
Privileged TaxonomicRelation
Data Schema
Documents
Data Value
Term (can be multi-lingual)
Keyword List

10. Taxonomy: Definition Taxonomy:
A way of classifying or categorizing a set of things, i.e., a classification in the form of a hierarchy (tree)
The classification of information entities in the form of a hierarchy (tree), according to the presumed relationships of the real world entities which they represent
A taxonomy is a semantic (term or concept) hierarchy in which information entities are related by either:
The subclassification of relation (weak taxonomies) or
The subclass of relation (strong taxonomies) for concepts or the narrower than relation (thesauri) for terms
Only the subclass/narrower than relation is a generalization-specialization relation (subsumption)

11. Taxonomies: Weak Example: Your Folder/Directory Structure
No consistent semantics for parent-child relationship: arbitrary Subclassification Relation
NOT a generalization / specialization taxonomy
Example: UNSPSC

12. Taxonomies: Strong HAMMER Claw Ball Peen Sledge
Consistent semantics for parent-child relationship: Narrower than (terms) or Subclass (concepts) Relation
A generalization/specialization taxonomy
For concepts: Each information entity is distinguished by a property of the entity that makes it unique as a subclass of its parent entity (a synonym for property is attribute or quality)
For terms: each child term implicitly refers to a concept which is the subset of the concept referred to by its parent term
HAMMER
Claw
Ball Peen
Sledge
What are the distinguishing properties between these three hammers?
Form (physical property)
Function (functional property)
“Purpose proposes property” (form follows function) – for human artifacts, at least

13. Two Examples of Strong Taxonomies Many representations of trees
Simple HR Taxonomy
Linnaeus Biological Taxonomy
manager
animate object
agent
person
employee
organization
Subclass of

14. Another, mostly strong Taxonomy: Dewey Decimal System

15. When is a Taxonomy enough?
Weak taxonomy:
When you want semantically arbitrary parent-child term or concept relations, when the subclassification relation is enough
I.e., sometimes you just want users to navigate down a hierarchy for your specific purposes, e.g, a quasi-menu system where you want them to see locally (low in the taxonomy) what you had already displayed high in the taxonomy
Application-oriented taxonomies are like this
Then, in general, you are using weak term relations because the nodes are not really meant to be concepts, but only words or phrases that will be significant to the user or you as a classification devise
Strong taxonomy:
When you really want to use the semantically consistent narrower-than (terms) or subclass (concepts) relation (a true subsumption or subset relation)
When you want to partition your general conceptual space
When you want individual conceptual buckets
Note: the subclass relation only applies to concepts; it is not equivalent (but is similar) to the narrower-than relation that applies to terms in thesauri
You need more than a taxonomy if you need to either:
Using narrower than relation: Define term synonyms and cross-references to other associated terms, or
Using subclass relation: Define properties, attributes and values, relations, constraints, rules, on concepts

16. Thesaurus: Definition
From ANSI INISO , (Revision of ):
A thesaurus is a controlled vocabulary arranged in a known order and structured so that equivalence, homographic, hierarchical, and associative relationships among terms are displayed clearly and identified by standardized relationship indicators
The primary purposes of a thesaurus are to facilitate retrieval of documents and to achieve consistency in the indexing of written or otherwise recorded documents and other items
A consistent semantics for the hierarchical parent-child relationship: broader than, narrower than, i.e., generalization/specialization
A thesaurus is a term taxonomy
Unlike Strong subclass-based Taxonomy, Conceptual Model, & Logical Theory: the relation is between Terms, NOT Concepts

17. Thesaural Term Relationships

18. Center For Army Lessons Learned (CALL) Thesaurus Example
imagery
aerial imagery
infrared imagery
radar imagery
combat support
equipment
moving target indicators
radar photography
intelligence and electronic
warfare equipment
Narrower than
Related to
imaging systems
imaging radar
infrared imaging systems

19. When is a Thesaurus enough?
When you don’t need to define the concepts of your model, but only the terms that refer to those concepts, i.e., to at least partially index those concepts
Ok, what does that mean?
If you need an ordered list of terms and their synonyms and loose connections to other terms (cross-references)
Examples:
If you need to use term buckets (sets or subsets) to use for term expansion in a keyword-based search engine
If you need a term classification index for a registry/repository, to guarantee uniqueness of terms and synonyms within a Community of Interest or namespace that might point to/index a concept node
You need more than a thesaurus if you need to define properties, attributes and values, relations, constraints, rules, on concepts
You need either a conceptual model (weak ontology) or a logical theory (strong ontology)

20. Conceptual Models: Weak Ontologies
Most conceptual domains cannot be expressed adequately with a taxonomy
Nor with a thesaurus, which models term relationships, as opposed to concept relationships
Conceptual models seek to model a portion of a domain for a database or a system
UML is paradigmatic modeling language
Drawbacks:
Models mostly used for documentation, required human semantic interpretation
Limited machine usability because cannot directly interpret semantically
Primary reason: there is no Logic that UML is based on
You need more than a Conceptual Model if you need machine-interpretability (more than machine-processing)
You need a logical theory (high-end ontology)

21. Conceptual Model: UML Example
Human Resource ConceptualModel

22. Logical Theories: Strong Ontologies
Emphasize Real World Semantics
Frame-based:
Node-and-link structured in languages which hide the logical expressions
Entity-centric, like object-oriented modeling
Centered on the entity class, its attributes, properties, relations/associations, and constraints/rules
Axiomatic:
Expressed as logical expressions
Non-entity-centric, focus on predicates, relations, properties
Enables automated inference

23. Logical Theories: More Formally
Conceptualization C
Language L
Models M(L)
Ontology
Intended models IM(L)
* N. Guarino Formal ontology in information systems, pp In Formal Ontology in Information Systems, N. Guarino, ed., Amsterdam: IOS Press. Proceedings of the First International Conference (FOIS’98), June 6-8, Trent, Italy. p. 7

24. Axioms, Inference Rules, Theorems, Theory
(1) Theorems are licensed by a valid proof using inference rules such as Modus Ponens
(2) Theorems proven to be true can be added back in, to be acted on subsequently like axioms by inference rules
Theorems
Axioms
(3) Possible other theorems (as yet unproven)
(4) Ever expanding theory

25. Axioms Inference Rules Theorems Class(Thing)
Class(Person)
Class(Parent)
Class(Child)
If SubClass(X, Y) then X is a subset of Y. This also means that if A is a member of Class(X), then A is a member of Class(Y)
SubClass(Person, Thing)
SubClass(Parent, Person)
SubClass(Child, Person)
ParentOf(Parent, Child)
NameOf(Person, String)
AgeOf(Person, Integer)
If X is a member of Class (Parent) and Y is a member of Class(Child), then  (X Y)
And-introduction: given P, Q, it is valid to infer P  Q.
Or-introduction: given P, it is valid to infer P  Q.
And-elimination: given P  Q, it is valid to infer P.
Excluded middle: P  P (i.e., either something is true or its negation is true)
Modus Ponens: given P  Q, P, it is valid to infer Q
If P  Q are true, then so is P  Q.
If X is a member of Class(Parent), then X is a member of Class(Person).
If X is a member of Class(Child), then X is a member of Class(Person).
If X is a member of Class(Child), then NameOf(X, Y) and Y is a String.
If Person(JohnSmith), then  ParentOf(JohnSmith, JohnSmith).

26. Ontology Representation Levels
Language
Meta-Level to Object-Level
Ontology (General)
Meta-Level to Object-Level
Knowledge Base
(Particular)

27. Ontology/KR Expressible as Language and Graph
In ontology and knowledge bases, nodes are predicate, rule, variable, constant symbols, hence graph-based indexing, viewing
Links are connections between these symbols: Semantic Net!
isa
?BATTALION
implies
(implies (isa ?BATTALION InfantryBattalion)
(thereExistExactly 1 ?COMPANY
(and (isa ?COMPANY Company-UnitDesignation)
(isa ?COMPANY
WeaponsUnit-MilitarySpecialty)
(subOrgs-Direct ?BATTALION ?COMPANY)
(subOrgs-Command ?BATTALION ?COMPANY))))
CYC MELD Expression Example
InfantryBattalion
thereExistExactly 1 1
and
?COMPANY
isa
?COMPANY
What’s important is the logic!
Company-UnitDesignation
isa
WeaponsUnit-MilitarySpecialty)
subOrgs-Direct
subOrgs-Command

28. A Military Example of Ontology
13465
121.25°
CNM035
13458 °
MIG-29
CNM023 … T
stamp
Long
Lat
Type
Tid
2.45
121°2‘2"
AH-1G C
330298
2.35
121°8'6"
F-14D
330296
Sense
Time
Coord
Model
S-code
Aircraft
Identifier
Signature
Location
Time Observed
Army
Navy
Service
Tupolev
TU154
Observed
Ontology
Commander,
S2, S3
Decimal
Geographic Coordinates
UTM
Coordinate
Sexigesimal
Ontology: defines the terms used to describe and represent an area of knowledge (subject matter): vocabulary + meaning + machine understandable
Axiomatized
Ontologies are the core of the Semantic Web.
Ontologies support semantic integration and interoperability at high levels (enterprise, community).
Ontologies are hub-and-spoke paradigm, not point-to- point integration, so cost of integration is N (linear), as opposed to N2 of point-to-point solutions.

29. Upper, Middle, Domain Ontologies
But Also These!
Most General Thing
Time
Identity
Upper Ontology
(Generic Common
Knowledge)
Part
Space
Processes
Material
Locations
People
Organizations
Middle Ontology
(Domain-spanning
Knowledge)
Facilities
Terrorist
Lower Ontology
(individual domains)
Financier
Terrorist
Org
Jihadist
Terrorist
Lowest Ontology
(sub-domains)
Al Queda
Areas of
Interest

30. Summary of Ontology Spectrum: Scope, KR Construct, Parent-Child Relation, Processing Capability
Machine-readable
Term
Concept
Machine-processible
Sub-classification of
Machine-interpretable
Taxonomy
SubClass of
Narrower Than
Thesaurus
Strong Taxonomy
Ontology
Disjoint SubClass of with Transitivity, etc.
Weak Taxonomy
Conceptual Model (weak ontology)
Logical Theory (strong ontology)

31. Thanks!
Questions?

32. Ontology & Ontologies 1
An ontology defines the terms used to describe and represent an area of knowledge (subject matter)
An ontology also is the model (set of concepts) for the meaning of those terms
An ontology thus defines the vocabulary and the meaning of that vocabulary
Ontologies are used by people, databases, and applications that need to share domain information
Domain: a specific subject area or area of knowledge, like medicine, tool manufacturing, real estate, automobile repair, financial management, etc.
Ontologies include computer-usable definitions of basic concepts in the domain and the relationships among them
They encode domain knowledge (modular)
Knowledge that spans domains (composable)
Make knowledge available (reusable)

33. Ontology & Ontologies 2
The term ontology has been used to describe models with different degrees of structure (Ontology Spectrum)
Less structure: Taxonomies (Semio/Convera taxonomies, Yahoo hierarchy, biological taxonomy, UNSPSC), Database Schemas (many) and metadata schemes (ICML, ebXML, WSDL)
More Structure: Thesauri (WordNet, CALL, DTIC), Conceptual Models (OO models, UML)
Most Structure: Logical Theories (Ontolingua, TOVE, CYC, Semantic Web)
Ontologies are usually expressed in a logic-based language
Enabling detailed, sound, meaningful distinctions to be made among the classes, properties, & relations
More expressive meaning but maintain “computability”
Using ontologies, tomorrow's applications can be "intelligent”
Work at the human conceptual level
Ontologies are usually developed using special tools that can model rich semantics

34. Tree vs. Graph Tree Directed Acyclic Graph Directed Cyclic Graph Root
Node
Directed Edge

35. Thesaurus vs. Ontology Ontology Concepts Thesaurus Real (& Possible)
Controlled Vocabulary
Terms: Metal working machinery, equipment and supplies, metal-cutting machinery, metal-turning equipment, metal-milling equipment, milling insert,
turning insert, etc.
Relations: use, used-for, broader-term, narrower-term, related-term
Ontology
Concepts
Logical-Conceptual
Semantics
(Strong)
Thesaurus
Real (& Possible)
World Referents
Terms
Term
Semantics
(Weak)
‘Semantic’ Relations:
Equivalent =
Used For (Synonym) UF
Broader Term BT
Narrower Term NT
Related Term RT
Logical Concepts
Entities: Metal working machinery, equipment and supplies, metal-cutting machinery, metal-turning equipment, metal-milling equipment, milling insert, turning insert, etc.
Relations: subclass-of; instance-of; part-of; has-geometry; performs, used-on;etc.
Properties: geometry; material; length; operation; UN/SPSC-code; ISO-code; etc.
Values: 1; 2; 3; “2.5 inches”; “85-degree-diamond”; “231716”; “boring”; “drilling”; etc.
Axioms/Rules: If milling-insert(X) & operation(Y) & material(Z)=HG_Steel & performs(X, Y, Z), then has-geometry(X, 85-degree-diamond).
Semantic Relations:
Subclass Of
Part Of
Arbitrary Relations
Meta-Properties on Relations

36. A More Complex Picture (from E-Commerce)
Models MB1(LB1)
Conceptualization B: Buyer
Conceptualization S: Seller
Language LB2
Conceptualization B2: Non-Technical Buyer
Conceptualization B1: Technical Buyer
Language LB1
Conceptualization S1:
Manufacturer Seller
Language LS1
Distributor Seller
Language LS2
Models MB2(LB2)
Models MS1(LS1)
Models MS2(LS2)
Ontology
Intended models IMB1(LB1)
Intended models IMB2(LB2)

38. Upper Ontological Distinctions 1
Focus here is on a few of the many possible upper ontological distinctions to be made
Descriptive vs. Revisionary: how one characterizes the ‘ontological stance’, i.e., what an ontological engineering product is or should be
Revisionary: every model construct (concept) is a temporal object, i.e., necessarily has temporal properties
Descriptive: model constructs are not necessarily temporal objects
Multiplicative vs. Reductionist: how one characterizes the kinds and number of concepts to be modeled
Multiplicative: Concepts can include anything that reality seems to require or any distinction that is useful to make
Reductionist: Concepts are reduced to the fewest primitives from which it is possible to generate complex reality

39. Upper Ontological Distinctions 2
Universal vs. Particular: the kinds of entities that ontologies address (the ‘universe of discourse’(s) of the ontology)
Universals: generic entities, which can have instances; classes
Particulars: specific entities, which are instances and can have no instances themselves
Continuant vs. Occurrent
Continuant: An entity whose identity continues to be recognizable over some extended interval of time (Sowa, 2000)
Occurrent: An entity that does not have a stable identity during any interval of time (Sowa, 2000)
3-dimensional (endurant) vs. 4-dimensional (perdurant)
3D view/ Endurant: an object that goes through time (endures), with identity/essence-defining properties that perhaps depend on occurrent objects but are not essentially constituted by those occurrent objects
4D view/ Perdurant: an object that persists (perdures) through spacetime by way of having different temporal parts at what would be different times

40. Upper Ontological Distinctions 3
Part & Whole: Mereology, Topology, Mereotopology, the ‘part of’ relation
Mereology: parthood, what constitutes a ‘part’?
Topology: connectedness among objects, what constitutes ‘connected to’?
Mereotopology: the typical contemporary analysis of ‘part of’ says that the relation requires both the notion of part and the notion of connectedness; neither is sufficient alone to describe what we mean by saying that something is a part of another thing

41. Ontology Spectrum strong semantics
Logic Spectrum on Next Slide will cover this area
Modal Logic
First Order Logic
Logical Theory
Is Disjoint Subclass of with transitivity property
Description Logic
From less to more expressive
DAML+OIL, OWL
UML
Conceptual Model
Is Subclass of
RDF/S
Semantic Interoperability
XTM
Extended ER
Thesaurus
Has Narrower Meaning Than ER
DB Schemas, XML Schema
Structural Interoperability
Taxonomy
Is Sub-Classification of
Relational
Model, XML
Syntactic Interoperability
weak semantics 1

42. Higher Order Logic (HOL) Second Order Logic (SOL)
Logic Spectrum: Classical Logics: PL to HOL
most expressive
SOL + Complex Types + Higher-order Predicates (i.e., those that take one or more other predicates as arguments)
Higher Order Logic (HOL)
From less to more expressive Logics
Second Order Logic (SOL)
Modal Predicate Logic (Quantified Modal Logic)
FOL + Quantifiers (, ) over Predicates
FOL + Modal operators
First-Order Logic (FOL): Predicate Logic, Predicate Calculus
PL + Predicates + Functions + Individuals + Quantifiers (, ) over Individuals
Logic Programming (Horn Clauses)
Syntactic Restriction of FOL
Description Logics
Decidable fragments of FOL: unary predicates (concepts) & binary relations (roles) [max 3 vars]
Modal Propositional Logic
PL + Modal operators (, ): necessity/possibility, obligatory/permitted, future/past, etc. Axiomatic systems: K, D, T, B, S4, S5
Propositional Logic (PL)
Substructural Logics: focus on structural rules
Propositions (True/False) + Logical Connectives (, , , , )
less expressive 1

43. Logic Spectrum: Semantic Web Languages: Ontologies & Rules
most expressive
Higher Order Logic (HOL)
From less to more expressive Logics
Second Order Logic (SOL)
Modal Predicate Logic (Quantified Modal Logic)
First-Order Logic (FOL): Predicate Logic, Predicate Calculus
SOL extensions
OWL-FOL
Logic Programming (Horn Clauses)
SWRL
OWL + Horn-like Rules
OWL Full
Almost FOL, but Classes as Instances goes to SOL
OWL DL
Mostly SHOIN(D): Close to the SHIQ and SHOQ
Description Logics
OWL Lite
Almost SHIF(D) (technically, it’s a variant of SHIN(D)
Modal Propositional Logic
RDF/S
Positive existential subset of FOL: no negation, no universal quantification
Propositional Logic (PL)
Linear Logic: consume antecedents
RuleML
Substructural Logics: focus on structural rules
less expressive
Expressed syntactically in XML, requires binding to a logic, ranges over all logics 1

44. Logic Spectrum: Other KR Languages, Query Languages
most expressive
Higher Order Logic (HOL)
From less to more expressive Logics
Second Order Logic (SOL)
Modal Predicate Logic (Quantified Modal Logic)
First-Order Logic (FOL): Predicate Logic, Predicate Calculus
SOL extensions
Knowledge Interchange Format (KIF), Common Logic (CL, SCL)
CycL
Logic Programming (Horn Clauses)
Constraint Logic Programming languages
OWL-QL
Open Knowledge Base Connectivity Language (OKBC)
Description Logics
Datalog
RDQL SPARQL
XQuery
XPath
Modal Propositional Logic
SQL
Propositional Logic (PL)
Linear Logic: consume antecedents
Substructural Logics: focus on structural rules
less expressive 1

45. Logic Spectrum: Tools most expressive less expressive
Higher Order Logic (HOL)
HOL
From less to more expressive Logics
Second Order Logic (SOL)
Modal Predicate Logic (Quantified Modal Logic)
Vampire
Otter
SNARK
OntologyWorks
First-Order Logic (FOL): Predicate Logic, Predicate Calculus
SOL extensions
Ontolingua/Chimaera
Knowledge Interchange Format (KIF), Common Logic (CL, SCL)
CycL
Cyc
Constraint Logic Tools: ECLIPSE, etc.
Logic Programming (Horn Clauses)
Constraint Logic Programming languages
Prologs: Amzi!, XSB, SWI, Ciao, BinProlog, Quintus, Sextus
OWL-QL
Open Knowledge Base Connectivity Language (OKBC)
Description Logics
Cerebra, Jena, L&C’s LinkFactory, KAON2, Racer, FaCT, Swoop, Pellet
Datalog
Protégé
RDQL
XQuery
XPath
Modal Propositional Logic
CLIPS, JESS
SQL
Propositional Logic (PL)
Linear Logic: consume antecedents
Substructural Logics: focus on structural rules
less expressive 1

46. What do we want the future to be?
2100 A.D: models, models, models
There are no human-programmed programming languages
There are only Models
Transformations, Compilations
INFRASTRUCTURE
Ontological Models
Knowledge Models
Belief Models
Application Models
Presentation Models
Target Platform Models
Executable Code