MOKB Ontology Specification

This document describes the ontology and its components which are being used in task-discussion. Each section below reflects the subset of the knowledge space which is being generated by one single component of the architecture. Each of these sections is represented by a particular color in the MokbOntologyDiagram.

In addition to the writeups in this file, the linked file below contains a list of all officially supported classes and slots in the ontology for use in MOKB (the link accesses the MOKB implementation area directly). All MOKB queries and updates should use vocabulary from this list. If you need a class or slot which is not in this list, please be sure to let John know so he can include it.

• MOKB domain file (requires read-only password-protected access privileges)

Chart Recognition

Here is a proposal for grounding the chart ontology in the context of the communication model, and a list of high-priority ontological elements which are needed for immediate integration into the task-discussion environment for use in year 2...

A GraphicalUnit is a type of LinguisticUnit used in the language of GraphicalGesture. They are realized by Mark (Embody) actions as PhysicalMarks. The .information-content slot, as a slot of LinguisticUnit, like in natural languages like English, assigns a semantics to the symbolic unit containing individuals, classes, roles, or facts. A Word might have a .information-content filled by a Person object just as in a Line this may be filled by a Task.

I plan to include an example of this in the MokbOntologyDiagram, though I am not currently done with this. Nevertheless, you might want to view the diagram anyways to see how 3D gestural and spoken language linguistic units (and their physical realizations) are currently being used to do multimodal communication modelling.

Now, here is a proposed elementary list of GraphicalUnits which are needed for immediate year-2 implementation purposes. Other graphical units in the chart ontology of are less importance immediately. (this may be slightly wrong...Sanjeev will have to clarify)

• GraphicalUnit
  • .label (OrthographicString)
  • .ordinal-position (xsd:integer)
  • .information-content (Thing)
  • TickMark (for axis unit marks)
    • .unit-of-measure (TemporalEntity? year, day, etc...)
  • Line (for both axes and tasklines)
  • OrthographicString (for labels)
    • .value (xsd:string)

There seems to be no immediate need for containment or other relations between the graphical units. Is this correct Sanjeev?

The semantics of the chart in terms of projects is realized through the .information-content slot in that Lines point to Tasks. The "names" of these project entities (is there a .has-name slot?) simply point to the .value of the .label of the associated graphical element.

Currently, the used components of the project model is indeed shown in the MokbOntologyDiagram. Projects have Tasks which have Milestones. It is still somewhat unclear as to whether we should be using the subevent slot or the other hasMilestone etc. slots. It is also unclear how we should be defining the temporal elements. The diagram shows our current proposal for this. (You will find all these items in the bottom of the diagram.)

Further comments from Sanjeev

I haven't had a chance to integrate these comments from Sanjeev into the above summarization, but hopefully they will stand on their own to outline the required additions to the above specification...

CHART ENTITIES
--------------

I think that the list of graphical units on that webpage is nearly complete.
Going through my code for populating MOKB, I find that perhaps it will be
helpful to have X-Axis and Y-Axis in the graphical unit for this year as
well.

 X-axis and Y-axis have labels but is already taken care of in your
proposal (GraphicalUnit has label and X-axis is graphical unit so it has
label). If we don't introduce X-axis and Y-axis then we would need to
introduce two artificial concepts that say "project-has-xLabel" and
"project-has-yLabel" so lets just add X and Y axis.

 The only containment kind of relationship that we would need is that
tick-marks belong to an axis. So X-axis will have TickMarks and Y-axis will
have TickMarks.

 Also, one may ask "What is the unit of axis?" which is basically the unit
of measure of the TickMark for that axis. So perhaps, we should move
.unit-of-measure (TemporalEntity? year, day, etc...) as a slot in the X and
Y Axis that we are introducing? Then the unit of measure for a tickmark
would be the unit of measure for the axis that this tick mark belongs to.

 The slot .information-content will also be useful for Y2 Test. We will use
this to link a chart entity to a project entitiy (that is its meaning).

PROJECT ENTITIES
----------------

We need to add few slots to project entities:

 .ordinal-position (xsd:integer)

  This is just a year 2 convenience. Strictly speaking this will not be
needed in subsequent years because chart objects will have things like
diamonds that will have ordinal-position (as per your proposal) so people
can ask questions about the "3rd diamond". However, for this year, they
would have to say "3rd milestone" .... So little weird to give semantic
objects an ordinal position but we will have to do it for year 2 test.

 .has-name  (just as you suggest on that page)

 .creation-time
 .deletion-time

 Perhaps these should belong to higer level "Entity" rather than to just
project entity?

PROJECT OPERATION
------------------

We would need the following project operations for year 2 Test. Each of them
should perhaps be subclasses of event?

  create_task_event
     .task
  delete_task_event
     .task

Since milestone is a subclass of Task, we don't need create_milestone, etc.

Physical Awareness

Here is a rundown on current knowledge being generated by David's AV Integrator