MyContext Explorer (xCavate?)
MyContext provides a uniform interface to view metadata about and generated by applications.
- The context is represented as a graph structure but viewed as a tree
structure (similar to a file system with symlinks)
- Each node (comparable to a 'file')represents a metadata object containing:
- Name (similar to file name)
- Metadata type (similar to mime-type or file extension)
- Metadata or reference to the metadata with associated service
to retrieve the metadata (an actual file or url to the file)
- Edges can have annotations
- Metadata types have associated plugins to handle the
metadata. (similar to applications that can open files of a
particular mime-type or extension)
- Each metadata type can have multiple plugins associated with it with
- When a node is opened, the metadata for the node is retrieved
dynamically and cached locally
- Metadata present in the nodes can be edited.
- A node having metadata type file-manager-file has metadata
The default plugin for the file-manager-file would contact
the file manager service (fileManagerServiceLocation) and retrieve
the metadata for the fileId.
It can then provide the facility to download the file using the uri
for the file that is part of the retrieved metadata.
- A node having metadata type xmessage-source has metadata
The plugin for the xmessage-source node would contact the channel
(sourceLocation) and execute the query to pull the messages. It can
then allow the user to store the events locally.
- A node having metadata type xbook-file contains
The plugin would contact the xbook manager and get the properties of
the xbook and launch it.
- A node having metadata type opendap-file with the
metadata=[dodsUrl=http://www.cdc.noaa.gov/cgi-bin/nph-nc/Datasets/reynolds_sst/, dataFile=sst.mnmean.nc, query='']
The plugin would display an interface to contact the dods server and
perform queries on the dataset.
- A node having metadata type local-file contains the
The plugin for a local-file would simply open the file and display
- A node having metadata type node-container that is used to
store other nodes and has no associated plugin.
This port is intended to allow external services to send metadata to the
context which can be stored as nodes in the context without the user having
to do it manually.
Example: An event source sends the following metadata to the registration
- Metadata that are sent to the port contain the sourceid of the
metadata, the metadata type and the metadata content or reference.
- A new node is created for the metadata based on its type
- Nodes present in the context can request the registration port to
attach newly created nodes from a particular source as their
If multiple nodes make a request to attach nodes created by the same
source, the new node is made a child of the first requesting node
and the other nodes have symlinks created to the new node.
- A single source can register an array of metadata objects to improve
A new node of type xmessage-source is created. If any existing node has
requested for nodes from source sourceid, then the newly created
xmessage-source node is added as its child. Else, it is stored under a
Question: Should 'sourceid' be stored as part of the node
- An node with metadata type xbook-directory can be used to
store metadata about an xbook repository and display the list of
XBooks available in it as nodes of type xbook-file.
- The user can then select an XBook to launch and the plugin associated
with the xbook-file can launch it for the user. A unique id for the
XBook instance is returned.
- A new node with type xbook-run is created as a child to the
xbook-file node and passed the 'id' of the running instance.
- The xbook-run node requests the registration port to add all
incoming metadata with sourceid='id' to be attached as its child.
- The script in the xbook instance that actually launches the
application has the static and dynamic running parameters of the
application as part of its 'invoice'.
- The script then registers the metadata retrieved from the invoice
(like the location where the events are going to be published, the
files that are going to be generated etc.) with the registration
port using its 'id' as source.
The graph can be stored as an xml tree corresponding to the primary visual
representation with 'symlink' edges being recorded as xml idrefs to the
node element. Each node is 'serialized' into its xml representation
based on its type and similarly 'deserialized'. If you think of nodes as
implementing a java interface, the interface has a serialize and
deserialize method. The serialized nodes can be stored in a local xml
Question: Is MyContext local or remote?
Local: Allows user to work even when not connected to the
Remote: Allows easier sharing of nodes between users but
nodes are not shared frequently. This also means that metadata that
is cached is present at the server and if one user of the node updates it,
all users get the latest copy.
All metadata that has been retrieved will be cached and indexed. The user
can perform a text search on the cached metadata. The search can be by node
type (i.e.) search only event-publisher nodes. Each node has to ability to
search within its own subtree and the whole search is performed
Implementation - Interfaces
Annotation annotation; // String, metadata, file
SearchResult search(String query);
* Stores reference to the metadata service from which the metadata can be
* retrieved and other parameters that are needed to retrieve the metadata
* Maps the node type to the plugins that can handle that particular node
* type. The default plugin is used to open nodes but user can choose to
* open the node with another plugin type
Vector nodeTypeMapping; // each node type has an entry with a vector of
// plugins that can handle the node type
void registerPlugin(Node node, Plugin plugin);
Plugin getDefaultPlugin(Node node);
Plugin getAllPlugins(Node node);
* Handles the node and interacts with the user through the output window
* can create new nodes (children) using reference to context tree
handleNode(Node node, OutputWindow window, ContextTree tree);
* Handles the tree structure, adding, removing nodes,
* expanding and collapsing of tree
NodeLocation addChild(NodeLocation parent, Node child);
void removeChild(NodeLocation child);
void expandLevel(NodeLocation node);
void collapseLevel(NodeLocation node);
* listens of the registration port for newly arriving metadata.
* Plugins can register their interest in newly arriving metadata
* meeting a particular spec (say sourceid). The plugins are notified
* when the metadata arrives by invoking the handleNode method in them
Vector nodeSourceMapping; // maps each node source to list of plugins
// interested in its arrival
registerInterest(String nodeSourceid, Plugin callbackPlugin);
deregisterInterest(String nodeSourceid, Plugin callbackPlugin);
nodeArrived(String nodeSourceid, Node node);
Yogesh L. Simmhan [firstname.lastname@example.org]
[Last modified on Tue Dec 17 14:23:01 EST 2002]