For the purpose of the this page I'm going to use the name SAILObject. I know that is controversial, but I need to use something. It is very much a work in progress, I hope I can distill something useful out of it and then link it into owl tree. Scott Cytacki
As described on the Ontology page, there are going to be Units, Pedagogical Objects, and Assets. The lowest level of the data model doesn't need to know about any of these things. To the data model there is going to be a single root object type called SAILObject with the following characteristics:
- a type which is a java class name, or a reference to a java class name, and a data description for that class.
- named and typed references to other other SAILObjects
- the reference can also parameterize the object being referred to.
- a globably unique id and a version number.
- body: structured content of the object which can include script
There might be an advantage to defining static and changing object types. A static object types id could be a hash of its content. If the content changed then the hash would change. This would mean all references to this object will still point to the old object unless they are explicitly updated. A changing object would have a content independent id and version number.
Requirements of the data model:
- very flexible and expandable.
- fast dependency graph traversal. To do efficient downloading and management the links between objects must be explicit.
- low overhead, and easy to manage. To get the most benifit out of the number of objects can be large. I imagine a typical unit would have a few thousand objects.
Types
A type has a java class and data description the describes how an instance of this class is synchronized. The java class needs to be a subclass of the root SAILObject class. Among other things the data description gives names and types to references to other SAILObjects. When another owl object references an object of this type, it can parametrize it. So it is an interesting question if the parameters need to be explicity defined, or if they can just be customization of the references.
References
As stated above the references are named by the type definition. For simple SAILObject types this means the type is like a form definition. Each field on the form has a name and is filled in with an object reference or a primitive type. Then the class of the SAILObject has the logic that uses these fields.
So how is the reference actually stored in the data of the SAILObject? It is stored as the globablly unique id and a version pattern.
For next steps we can try to formalize this model more and diagram it. We can also think about how our existing pedagogica activities and topics would look.