Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Higgins/ModelAPIs"

(The model for attribute models)
(A person's model)
Line 12: Line 12:
  
 
==A person's model==
 
==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.getTypeNode()), we see (NOTE: this node is a model element):
+
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):
 
* Java type: some impl of INode – This is implemented by the context provider.  We can assume it's a PersonModel.class.
 
* Java type: some impl of INode – This is implemented by the context provider.  We can assume it's a PersonModel.class.
 
* getNodeID() returns: the contextually unique ID for this node.  This is the same value we got when calling INode.getType() on the person instance above, so in this case it would be “http://example.com/some/name/space#Person”.
 
* getNodeID() returns: the contextually unique ID for this node.  This is the same value we got when calling INode.getType() on the person instance above, so in this case it would be “http://example.com/some/name/space#Person”.

Revision as of 20:31, 22 February 2008

Today, IdAS defines a set of special interfaces for accessing a context's model elements. It may be better to not define special interfaces for this purpose, 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