Re: [mdr-users] Repository Questions

Hi Adam,
please see below for my answers.

Adam wrote:

> 1) Can the MDR contain multiple models similar models? For example the 
> central model for HL7 is called the RIM but in addition we'd like to 
> be able to hold locally defined variations, datatypes,vocabs etc. Can 
> each model be updated separately? How easy is it for the application 
> to identify a given model (e.g. if I create a Locab vocab model & call 
> it "LocalVocab" can I pass that in as as string taken from a value in 
> a properties/XML file?

Sure - if I correctly understand your question, this is easily possible 
with MDR. You can create multiple instances of MOF or any other 
metamodel (e.g. UML or anything else described in MOF) - these are 
identified using a name (string) - we call these "extents". In each 
extent you can store any number of models you wish. To create an extent 
you just call repository.createExtent(extentName, package), where 
"package" is the root package of a metamodel the extent should be 
instance of (Model package for MOF). Later to retrieve that extent, you 
can call repository.getExtent(extentName).

> 2) Easy loading. How easy is it to load a model into the repository 
> (esp given the above local additional models which would need to 
> remain untouched if say the RIM was updated).The repository needs to 
> be manageable by modellers who are mostly from a clinician backgroound 
> rather than an IT/Technical background.

Very easy - just use XMIReader to read in an XML document conforming to 
the metamodel (e.g. MOF) into a given extent. If, by reading the data 
you want to replace existing data in the extent, you can first delete 
the extent, create a new one with the same name and import the XML into it.

>
> i.e. if we had a MIF<>MOF profile & the RIM was updated & we were to 
> export the new RIM as a MIF, could the MDR replace the current RIM-MIF 
> in the local repository with the updated one easily?

I guess I described this above - you can remove the extent with the old 
RIM and create a new one (with the same name) loading the new RIM into it.

>
> Equally if a local vocab had been updated & the MIF was sent out, 
> could the MDR just update/replace the local vocab?

Yes.

>
> 3) Does MIF<>MOF profile need to be generated, does the MIF need to be 
> a MOF variant or can some other route be taken e.g. XSD > EMF > EMOF > 
> MDR?

I would probably create a MOF metamodel of MIF and have an xslt 
transforming the current MIF XML files into the XML files conforming to 
the XMI derived from the MOF metamodel of MIF. The transformer (based on 
the xslt) can even be plugged into MDR programmatically to preprocess 
the input taken by XMIReader. So the transformation and reading of the 
XML into the MDR can be made to look like a one-step thing.

>
> 4) Does the JDBC implementation allow for concurrent multi-user 
> access? Can you export from the JDBC to the local Btree easily? At all?

I am not sure about the multi-user access - there may be certain things 
that may not work (such as even notifications).
Exporting JDBC to the local b-tree should be easy. It is definitely 
doable via XMI import/export. There could be more effective ways of 
doing this - e.g. being able to connect to both local and remote DB and 
do copy without the intermediate XML form - but then the extents in the 
local db would need to have different names than the extents in the 
JDBC. I don't know if that would be feasible. And nobody experimented 
with this kind of approach yet.

>
> In the "We do it ourselves using derby" there'd be a simple SQL script 
> & 2 connections to the 2 databases (i.e. the central network one & the 
> local derby one) & data could be transfered like that. Possibly all 
> the data associated with the RIM might be dropped (from the local db) 
> & the new data inserted.
>
>
> 5) Is it easy to pack up & copy (e.g. zip), install etc?

I think so.

>
> The most obvious way of transferring the data from the cenral copy to 
> the local copy would be via a single large XML-MIF file & then rely 
> upon the local engine to absorb it (assuming that the localend is not 
> JDBC compliant).
>
> Would it be simpler to autocreate a repository instance (e.g. via ant 
> scripts running on the server) & then offer that for download? If so 
> again would the install/absorbtion etc be easy (given the clinician & 
> not technical background of the users)?

I guess it can be made easy - it depends on how you implement your tool 
on top of MDR.
Regards,
Martin