In the Netbeans Workbench there was a "gateway" API which combined:

• A client-side implementation of the mIR3 information model as Java classes, which are dynamically generated from the WS client for the MIR3 built into the gateway. As well as reflecting the basic object/table model it also exposed additional metadata as properties. The potential hierarchical organisation of things based on WorkContext^? in which they were created was explicitly supported by this model.
• Additional classes and methods to support workflow execution on a remote enactor.
• The mIR and enactors to use were configured by the user when setting up the workbench, and only one of each could really be used.

Some random personal reflections on this and the MIR, to inform redesign/reployment.

• In that version it was required that all inputs to workflows be in the MIR already. Furthermore, it was required that they have reasonable semantic types in order to link to workflows. This meant that users had to import values from their filesystem or other applications before they could be used. With the additional requirement for semantic type selection this was slow and awkward.
  • users should be able to provide inputs by cut and paste, from local files, etc.
  • users should be able to use the workbench/taverna/whatever with or without an external MIR
• only one MIR was supported, presumed to hold everything
  • users should be able to mix and match multiple (layered/federated?) mirs, plus local files, email, cut n paste, ...
• All outputs and provenance were written to the MIR by the gateway automatically. Consequently they were all available. but...
• There was no way to delete things from the MIR or do garbage collection, and it quickly filled up with "junk" (e.g. runs from testing), which slowed down interaction and cluttered views.
  • users should easily be able to get (copies of?) results on their local system, export them to other applications, email them, etc.
  • a central MIR will need some real and effective admin/management facilities or it will bloat and die
• The WorkContext^? hierarchy was more or less hardcoded in the gateway and the netbeans view as the primary view-point. In part this was due to NetBeans forcing a file-system paradigm on it. This made the support for alternative viewpoints very difficult within the environment.
  • different, dynamic, views should be easy
  • these views may be dynamic
• The gateway "exploded" outputs into the MIR, both in that different output parts (i.e. "name" vs "description") were stored as different data items, and in that array-valued parts were split into individual items (e.g. an array of images to a number of individual images) so that the individual images could then be used by other elements knowing about (single) images.
• There was a special provision in the workbench to add (a) create a new data thing in the MIR and (b) add annotation to link it to its origin when a user selected a single DB cross-reference from a record or list. I.e. from a part of a result to an input, with provenance trail preserved.
• The ontology was loaded into the MIR via an ad hoc mechanism, and used in some places e.g. for workflow input type matching, data thing annotation. This needs tidying up - where should the ontology live and how should it be accessed and maintained.
• there was no access control, although users did self-identify, and the identity of creators was recorded
  • must try harder
  • e.g. people need to be able to manage the "publication" of their data, e.g. who/where can resolve their LSIDs? do people see different metadata for the same LSID?
• Arbitrary metadata was supported, but querying was limited to wildcard match on individual statements
  • facility for arbitrary metadata is good
  • requires access to ontology for properties, concepts (potentially also extending)
  • querying of metadata should be better, e.g. sub-graph matching
• the MIR was only available as a (relatively hard to set up) web service interface over DB2. this made it pretty slow and hard to set up, and relatively low performance compared to local filesystem use
  • it should be much easier than this to set up
  • like it says above you should be able to start without an external mir service, and then start using it (for some stuff?!) to gain benefits in proportion to use.

-- ChrisGreenhalgh - 27 Feb 2004