A Mathematical Approach to Ontology Authoring and Documentation

Motivation OMDoc for Ontologies Evaluation Metadata Conclusion

A Mathematical Approach to
Ontology Authoring and Documentation
FGWM 2009

Christoph Lange and Michael Kohlhase

Jacobs University, Bremen, Germany
KWARC – Knowledge Adaptation and Reasoning for Content

September 22, 2009

Lange/Kohlhase (Jacobs University) A Mathematical Approach to Ontology Authoring and Documentation September 22, 2009 1/19


Overview

Shortcomings of OWL (Web Ontology Language) w. r. t.
documentation:
limited expressivity
poor modularity
no full integrated documentation
Those problems (and solutions!) are known from other fields:
MKM (Mathematical Knowledge Management)
Software Engineering (program comprehension, software
documentation, UML, literate programming)
⇒ improve ontology engineering that way!
Concretely: engineer OWL ontologies in our mathematical markup
language OMDoc



Semantic Web Ontologies

Semantic Web: the web of data and intelligent agents
Ontology (there): formalization of a shared conceptualization
mostly implemented in decidable FOL subsets
Web Ontology Language (OWL): description logic
not just decidable, but also tractable sublogics of OWL



Lack of Expressivity

What if the world is more complex than your logic?
1 dumb the model down to the logic used (e. g. DOLCE in OWL)
2 add informal documentation of how things actually are

Example
Example from FOAF (Friend-of-a-Friend): foaf:membershipClass
“All foaf:members of this foaf:Group have to be instances of the class C”
Too complex for OWL ⇒ specified in lengthy, ambiguous natural language
(targets: authors and developers)

Problem is not just lack of expressivity, but also lack of modularity, and of
integrated documentation in general.



Correspondences . . .

OMDoc/MKM OWL/Ontology What is it?
Symbols Entities (classes, prop- “atoms”
erties, individuals)
Statements Axioms/Rules state (= define or assert)
properties of symbols
Theories Ontologies collections of related
symbols/statements
their “deductive closure”
often modularized



. . . and Differences
Expressivity:
OMDoc: logically uncommitted, can implement any logic as theory
heterogeneity
OWL: at most SROIQ (a DL), or subsets
Modularity:
OMDoc: theory morphisms (symbol/formula mappings), parametric
theories
OWL: import complete ontologies, and import them literally (rarely
used)
Documentation support:
OMDoc: literate programming; documentation in any granularity
OWL: attach strings to entities and ontologies
OWL 2: also axioms
more? – in theory (reification, named graphs, XML literals,
RDFa), but not in practice


OMDoc as a Semantic Web Ontology Language

Prerequisites are satisfied: URIs as identifiers, any logical foundation can be
formalized
Plan:
1 model OWL and its foundations RDFS and RDF (we go this way for
compatibility!) as OMDoc theories
2 introduce import syntax and semantics for referencing semantic web
ontologies from OMDoc
3 translate ontologies from OMDoc to the RDF syntax of OWL (to reuse
existing reasoners), and back



1. Knowledge Representation

implemented OMDoc theories for RDF, RDFS, and OWL, which declare
all of their symbols
most elementar representation: RDF triples = predicate(subject, object)
axioms
syntactic sugar for frequently used constructs:
individuals that are instances of classes: use OMDoc’s typing syntax
Michael Person
compound types for properties:
knows ObjectProperty(Person → Person)
more to come (subclasses, subproperties, . . . )
can distinguish between declared and inferred knowledge
(definition/axiom vs. theorem; “provenance”), can model proofs



Example
A well-known DL axiom: Student = Person ≥ 1 enrolledIn
<theory name= " u n i v e r s i t y " >
<imports from= " owl . omdoc# owl " / > <imports from= " f o a f . omdoc# f o a f " / >
<omtext type= " i n t r o d u c t i o n " ><CMP> F o r our o n t o l o g y , we f i r s t i m p o r t
FOAF and then i n t r o d u c e t h e c o n c ep t o f a s t u d e n t . . . . < /CMP>< / omtext>
<symbol name= " S t u d e n t " x m l : i d = " s t u d e n t . sym " >
<metadata>
<meta p r o p e r t y = " d c : d e s c r i p t i o n " >A s t u d e n t < / meta>< / metadata>
<type system= " owl " >
<OMOBJ xmlns= " h t t p : / /www. openmath . org / OpenMath " >
<OMS cd= " owl " name= " C l a s s " / >< / OMOBJ>< / type>
< / symbol>
< d e f i n i t i o n f o r = " # s t u d e n t . sym " type= " s i m p l e " >
<CMP>A s t u d e n t i s a p e r s o n who i s e n r o l l e d a t l e a s t once . < /CMP>
<OMOBJ xmlns= " h t t p : / /www. openmath . org / OpenMath " >
<OMA><OMS cd= " owl " name= " i n t e r s e c t i o n O f " / >
<OMS cd= " f o a f " name= " P e r s o n " / >
<OMA><OMS cd= " owl " name= " R e s t r i c t i o n " / >
<OMS cd= " u n i v e r s i t y " name= " e n r o l l e d I n " / >
<OMA><OMS cd= " owl " name= " m i n C a r d i n a l i t y " / >
<OMI>1< / OMI>< /OMA>< /OMA>< /OMA>< / OMOBJ>
< / d e f i n i t i o n >< / theory>



Example (nicer)



2. Connecting OMDoc and Semantic Web URIs

OMDoc: theory graph URI → theory name → symbol name
Semantic Web: namespace URI → local name (like XML)
Writing ontologies from scratch in OMDoc → no problem !
But how to reimplement or reference existing semantic web ontologies?
<theory name= " f o a f " >
<metadata>
< ! −− mapping from theory t o namespace U R I −−>
< l i n k r e l = " odo:semWebBase " h r e f = " h t t p : / / xmlns . com / f o a f / 0 . 1 / " / >
< / metadata>
< / theory>

Simplest migration path: start with this mapping only, OMDocify the whole
rest later



3. Compatibility to Reasoners etc.
Efficient DL reasoners and other ontology tools (e. g. visualization) don’t
support OMDoc – be compatible with them
extended our Krextor XML→RDF extraction framework to
OMDoc→OWL; implemented OWL/RDF→OMDoc (bootstrap editing)
formally specified (in OMDoc, of course ) how our syntactic sugar
breaks down to RDF
<file:.../uni.omdoc?university>
rdf:type owl:Ontology ;
owl:imports foaf: .
<file:.../uni.omdoc?university?Student>
rdf:type owl:Class ;
owl:equivalentClass _:d24e43 .
_:d24e43
owl:intersectionOf _:collection-d24e44 .
_:collection-d24e44
rdf:first foaf:Person ;
rdf:rest _:collection-d24e44-1 .
_:collection-d24e44-1
rdf:first _:d24e47 ;
rdf:rest rdf:nil .
_:d24e47
rdf:type owl:Restriction ;
owl:onProperty <file:.../uni.omdoc?university?enrolledIn> ;
owl:minCardinality "1"^^xsd:nonNegativeInteger .



Presenting Documentation

OMDoc has an elaborate adaptive presentation framework (JOMDoc,
http://jomdoc.omdoc.org) – use it
define notations for our logical symbols
many context-dependent alternatives possible, compare
Student = Person ≥ 1 enrolledIn to Manchester syntax:
C l a s s : Student
E q u i v a l e n t T o : P e r s o n t h a t e n r o l l e d I n min 1

Output contains interlinked presentation and semantic markup
(“parallel markup”; preserves semantic structure)
can use that for interactive navigation, e. g. definition lookup (“what
does mean again?” → JOBAD,
http://jomdoc.omdoc.org/wiki/AI-Mashup)



FOAF Rewritten and Presented in OMDoc


Evaluation: FOAF reimplemented in OMDoc

1 FOAF references other ontologies without importing them. More
support with OMDoc.
2 Could turn all source code  (e. g. section
headers) into proper documentation and document structure
3 Some comments attached to individual axioms – no problem with
OMDoc’s literate programming
4 Better handling of inverse properties, e. g. foaf:maker = foaf:made−
Define one direction, infer the other (and more facts about the inverse)
5 non-OWL semantics of foaf:membershipClass expressed in FOL
6 some relations to imported entities not stated properly (foaf:maker vs.
dc:creator) – solved by views
7 FOAF’s documentation contains completely informal sections – we
could seamlessly integrate them with the formal part


Scalable Metadata for Technical Specifications

Metadata not only needed for documenting ontologies, but also for
technical specifications (e. g. revision logs), digital libraries, etc.
OMDoc 1.2 OMDoc 1.6
custom XML syntax using RDFa, old syntax for com-
patibility
from statements upwards also inside formulæ
few vocabularies hard-coded (DC, can use any URI-based vocabulary
CC, plus ad hoc extensions)
not extensible can even define new vocabularies
in OMDoc
formal semantics not clear rely on metadata ontologies



Challenges and Future Work

High expressivity and good documentation ⇒ extremely verbose.
Need good editor support. Plan: extend OMDoc-aware semantic wiki
SWiM for ontologies, “invade” [Collaborative] Protégé and word
processors
Ontology documentation approaches:
add documentation to existing ontologies
formalize informal documents into ontologies
collaborative development
Mathematically define syntactic macros (and β-reduce them when
generating OWL) – no longer limited to OWL’s syntactic sugar
Do the same for other ontology languages
Evaluate with industry-scale ontologies



FOAF made interactive using OMDoc and JOBAD



Conclusion

We apply technology from (MK)M for M(KM).
Ontology engineering can benefit from better documentation (and
more explicit modularity/heterogeneity)
Scalable metadata approach for any semantic markup
(What semantic markup do you use?)

See our poster and discuss!


A Mathematical Approach to Ontology Authoring and Documentation

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Christoph Lange

Mehr von Christoph Lange (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

A Mathematical Approach to Ontology Authoring and Documentation