Skip to main content
Jump to: navigation, search

Difference between revisions of "Higgins/ModelAPIs"

(The model for attribute models)
Line 41: Line 41:
 
==The model for node models==
 
==The model for node models==
 
What defines a node model node?  This does:
 
What defines a node model node?  This does:
* Java type: an impl of INode called NodeModel. This is implemented by Higgins and is always the same.
+
* Java type: an impl of INode.  Higgins will provide a default class called NodeModel.class, but a context provider is free to return its own (which may or may not be a subclass of the Higgins NodeModel.class), as long as it contains the “http://www.eclipse.org/higgins/ontologies/2006/higgins#attributeTypes” and its values mentioned below.  A context provider is free to add more values to the “http://www.eclipse.org/higgins/ontologies/2006/higgins#attributeTypes” attribute.
 
* getNodeID() returns: the unique ID for this node.  This is “http://www.eclipse.org/higgins/ontologies/2006/higgins#NodeModel”
 
* getNodeID() returns: the unique ID for this node.  This is “http://www.eclipse.org/higgins/ontologies/2006/higgins#NodeModel”
 
* getAttributes() returns: the following attributes:
 
* getAttributes() returns: the following attributes:
** http://www.eclipse.org/higgins/ontologies/2006/higgins#attributeTypes:  These values exists here:
+
** http://www.eclipse.org/higgins/ontologies/2006/higgins#attributeTypes:  These values exists here (note that a context provider may add to this set of values):
 
*** “http://www.eclipse.org/higgins/ontologies/2006/higgins#attributeTypes”
 
*** “http://www.eclipse.org/higgins/ontologies/2006/higgins#attributeTypes”
 
**** Note there's a subtlety here that may look confusing.  The attribute is called attributeTypes and this value is also called attributeTypes.  What we're saying is that this model (which defines what it means to be a node model – really a node model model to be precise) specifies that instances (like the model for person, or organization) can have an attribute called attributeTypes.  We could rename this value to something like “http://www.eclipse.org/higgins/ontologies/2006/higgins#nodeAttributeTypes” if that would make it more clear.
 
**** Note there's a subtlety here that may look confusing.  The attribute is called attributeTypes and this value is also called attributeTypes.  What we're saying is that this model (which defines what it means to be a node model – really a node model model to be precise) specifies that instances (like the model for person, or organization) can have an attribute called attributeTypes.  We could rename this value to something like “http://www.eclipse.org/higgins/ontologies/2006/higgins#nodeAttributeTypes” if that would make it more clear.

Revision as of 13:40, 6 March 2008

Problem

Today, IdAS defines a set of special interfaces for accessing a context's model elements. There are a number of problems with these interfaces:

  1. They are 'fixed' in nature. The only way to represent extra information about the model of context elements is to revise these interfaces. For example, say there's a need to associate an image with the attribute called “http://example.com/some/name/space#telephoneNumber” (this image might be used by a management UI). To make that association we need a new method like IAttributeModel.getManagementImage().
    1. Even if we felt like it's ok to revise the current I*Model interfaces, we do not know what kinds of information will need to be associated with the models of elements in a context. It may be the case that some people will have needs that we think are unworthy of revising the interfaces for. For example, say someone wants to associate an astrological symbol to each different attribute model. Does that mean we should add a new IAttributeModel.getAstrologicalSymbol()?
  2. There is no way to update a context's model. We have a need to be able to add models for new node types, attribute types and so-on. We also need to be able to change existing models (such as changing the cardinality of an attribute). Also, we may need to remove models.
  3. We cannot look up a model with partial information. For example, say I know there's an attribute with the word "telephoneNumber" in its ID, but I don't know the entire ID. It would be nice to be able to have a way to find what I need without enumerating through the entire set of attribute models.

Proposal

It may be better to move away from the existing special interfaces for the purpose of defining the model of elements, but instead simply re-use the existing interfaces that are used to access normal information within a Context (nodes and their attributes).

Following is a proposal which shows how these model nodes might look. To illustrate the proposal, we start by showing how an instance of a person looks (nothing new) and then examining the model nodes that govern instances of nodes and attributes:

A person

Example of an instance of a person node.

  • Java type: some impl of INode. The context provider implements this class
  • getNodeID() returns: the contextually unique ID for this person
  • getAttributes() returns: typical attributes about this person (things like a homeAddress and phoneNumber)
  • getType() returns: an identifier for this person's model node. assume it's called “http://example.com/some/name/space#Person”
  • getTypeNode() returns: some impl of INode, assume it returns a PersonModel.class

A person's model

Now, say we look at the “person model” node we saw above (we got this either by calling INode.getTypeNode(), or INode.getType() followed by IContext.getNode(NodeID)), we see (NOTE: this node is a model element):

The "top" node model

Ok, now let's look at the instance of the node called “http://www.eclipse.org/higgins/ontologies/2006/higgins#Node”. This is simply the top-level model definition for all node model hierarchies. Thus it contains model definitions for things common to all nodes:

The model for node models

What defines a node model node? This does:

The model for model elements

Finally, here's the model for model elements:

Note the recursive nature of getType and getTypeNode above. We could instead return null or throw some well-known exception.

An attribute model

Now for fun, let's look at an attribute's model, and follow that. We'll take the example of “http://example.com/some/name/space#homeAddress”:

The model for attribute models

And here's that the node identified by “http://www.eclipse.org/higgins/ontologies/2006/higgins#AttributeModel” looks like:

Then of course we have value models. Again from the bottom-up, here's a node that describes a value type called <TODO: finish this>

<TODO> needs to be a way for people to extend NodeModel and AttributeModel such that they can add their own elements (like displayName, icon, etc.>

<TODO need to be able to specify min/max cardinality on each attributeType associated with a specific node model so we can preserve the ability to say "person nodes must have at least one surname attribute value, and may have a telephone number" without causing all instances of surname to be min=1

Back to the top