Yesterday I unexpectedly read two whole papers about ontology development methodologies.  They were open in tabs I don't remember opening, but presumably did so during our weekly Ontologies With A View meeting last Friday.  There are still a bunch more tabs open with papers or articles about the same thing, so maybe I'll read those later..

The notes are here more or less as I scribbled them down whilst reading, and I haven't expanded with any analysis or discussion as of yet.

Notes in purple are things I intend/need to investigate further; colour-coding is just for me, really.


Jean Vincent Fonou-Dombeu & Magda Husiman (2011)  Combining Ontology Development Methodologies and Semantic Web Platforms for E-government Domain Ontology Development.  International Journal of Web & Semantic Technology (IJWesT) Vol.2, No.2, April 2011 

• Start by describing ontology in a human-readable way, then turn to RDF (etc) to be machine readable.
• Says there's not sufficient practical research around existing technologies or ontology development guidelines that would allow non-experts in e-government domain to make ontologies.
  
• Uses framework from Uschold & King (see later in this post) to describe ontology - technique used here should be platform independent.
• Then uses UML to semi-formally represent ontology
• Uses Protege and Jena to convert to OWL and RDF

• Paper's goal is to produce guidelines for e-government developers to create semantic content AND strengthen adoption of Semantic Web technologies in governments (particularly developing countries).
  
• Outlines RDF, OWL, Protege and Jena (described as leading platforms; mentions other platforms: WebODE, OntoEdit, KAON1, Sesame).
  
• Very critical of other literature; either ontologies have been produced but no practical information given; they've been developed with proprietary platforms; or they're only conceptual and don't say how they could actually be constructed with existing technologies.  other studies have not focused on a methodological approach, which means nothing is easily repeatable.
  
• Detailed comparative studies of methodologies in:
• M. Fernandez-Lopez, “Overview of Methodologies for Building Ontologies, ” In Proceedings of the IJCAI-99 workshop on Ontologies and Problem-Solving Methods (KRR5), Stockholm, Sweden, 2 August, 1999. 
• H. Beck and H.S Pinto, “Overview of Approach, Methodologies, Standards, and Tools for Ontologies,” Agricultural Ontology Service (UNFAO), 2003. 
• C. Calero, F. Ruiz and M. Piattini, “Ontologies for Software Engineering and Software Technology, ” Calero.Ruiz.Piattini (Eds.), Springer-Verlag Berlin Heidelberg, 2006.
  
• Case study: Ontology for monitoring development projects in developing countries (OntoDPM)
1. Create with Protege:
   
   • class heirarchies
   • slots
   • domain and range of slots
   • Based on the UML
   • Saved as OWL
2. Then put content in RDF with Jena

Mike Uschold and Martin King (1995*) Towards a Methodology for Building Ontologies. Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95.

• Steps:
1. identify purpose
2. build ontology
   
   • capture
   • coding
   • integrating existing ontologies
3. evaluation
4. documentation

• Purpose
• Many ontologies are intended for reuse
• Should survey purposes to clarify options for future projects
• Building
• Capture
• Identify key concepts and relationships in domain of interest
• Produce unambiguous text definitions for these
• Identify terms for these
• Agree on all of the above
• Coding
• Explicit representation of conceptualisation in a formal language (choose a language)
• When can capture and coding stages be merged?
• Differences between building ontology and creating a general knowledge base (thinking about methodology will help with this)
• Integrating (during either or both of above)
• Work must be done in agreement between communities
• Make explicit all assumptions underlying an ontology
• Evaluation
• Judge against requirements specification (and/or)
• Judge against competency questions (and/or)
• Judge against real life
• This paper looks at knowledge base systems, and adapts for ontologies.
• Documentation
• Desirable to have established guidelines for documenting
• Main barrier to effective knowledge sharing is inadequate documentation
• ALL important assumptions should be documented

• Case Study
• Main emphasis is on capture phase
• Initially:
• define ontology (Gruber)
• identify users and usage (initially abstract, then clarify with real life)
• choose language (Ontolingua was chosen)
• choose method for capture - BDSM (IBM) supported by others:
• KADS
• IDEF5
• OO Analysis and Design techinques
• Gruber's principles for ontology design
• Categorisation is fundamental to the human condition (Lakoff)
• Not heirarchical, but:
• GENERAL
         ^
     BASIC  ->  primary with respect to knowledge organisation
         v
  SPECIFIC
• eg.
        SUPER:   Animal    /   Furniture
        BASIC:    Dog        /   Chair
        SUB:        Retriever /   Rocker
• Certain concepts used subconsciously, rather than understood intellectually.
• These have a more important psychological status.
• Therefore paper uses middle-out approach to capture terms
• (bottom-up = too much detail unnecessarily,
• top-down = risks imprecision)
• BASIC concepts first because:
• most important
• used to define non-BASIC terms
• increase clarity, especially for non-technical use
• backed by BSDM experience of paper author
• Scoping
• Brainstorming
• Consult corpora if there aren't enough domain experts to brainstorm
• Grouping
• structure terms into naturally arising sub-groups
• collate synonyms
• consider things that might refer to each other
• Meta-ontology
• Don't commit too early, can restrict thinking.  Let concepts and relationships themselves determine requirements.
• Be consistent.
• Use technologically neutral language ('thing' vs 'entity').
• Start with areas where there's most overlap.
• Work from basic terms to more abstract ones within an area.
• Producing definitions
• Agreeing on definitions (varying degrees of problems)
• Handling ambiguous terms
• clarify ideas without technical terms
• use a dictionary!
• label definitions, eg. x1, x2
• determine most important concept
• choose a term, avoiding original ambigious one
• Avoid new terms
• Terms get in the way (peoples' preconceived ideas) - concentrate on underlying meaning and concepts.