This work was initiated from the joint monthly call of EDMC and OMG's Finance Domain Task Force.

The purpose is to specify the requirements for which information about ontology elements should be displayed to end users (of various types) via a web browser. See more detail below.


There was a weekly call Wednesdays at 10am Pacific chaired by Pete Rivett - meetings have now been suspended given that deliverables are now complete (on this and the sub-pages).


  • Recommendations to OMG/EDMC/industry
  • Serve as requirements for tools
  • Provide web-addressable pages for understanding ontology elements
  • Accessible via element URI and content negotiation
  • Allow redirect/mapping of server address
  • Support https
  • Allow “follow your nose” browser navigation of related elements

In Scope

  • Any (OWL 2) ontology resource as entry point…
    • Ontology
    • Class
    • ObjectProperty
    • DatatypeProperty
    • Individual
    • Datatype
    • Domain/Module (as in FIBO)?
  • Labels/synonyms
    • With scoping (incl to ontology/jurisdiction and language)
  • Annotations - Dynamic set

Out of Scope

  • Technology
    • May have an issue with # ontologies (hash vs slash) since a server will not receive the full URL after #
    • Multiple providers (tools/servers) for different views of same URI from different tools/servers
    • How to insert static/curated/manually created diagrams into a dynamic structure? May be part of the navigation structure

  • Static vs dynamic generation
    • But should allow for both
  • Presentation look and feel
    • Focus on content not how it is presented/laid out
    • Or mechanisms for interactivity

Types of View

  • Artifact aspect
    • Glossary view: terms, definitions, synonyms
    • Taxonomy view (equivalent of SKOS): adds hierarchy
    • Structure view: adds properties
    • Ontology view
  • Role aspect
  • Enrichment aspect
    • Direct element detail
    • Related element info – queried or inferred
    • Text/diagrams/tables
  • Any of above may include diagrams – which can be static (manually curated) or dynamically generated 
    • Idea: start at glossary view and allow user to add more info
    • Web applications could extend the above diagrams to provide a dynamic interactive/exploratory experience
  • Stickiness
    • Should allow for remembering user's last choice of view (e.g. via a cookie, or user profile) and apply that to any URI 
  • Start point
    • Via URI of specific element; there is one URI per concept regardless of view
    • Query 
      • Reach of queries may benefit from the notion of Workspace (e.g. Production only, or Business Entities only)
    • Top-down
    • Access via label/synonym as opposed to URI

Open Issues

  • Issue: common terminology across views e.g. don’t want to change from “term” to “concept” to “class” when changing view for the same element. Current feeling is to use common terminology e.g. "synonym" and document how it maps to differetn representations.


  • No labels