| Author |
Messages |
|
JP Brown
Posts:26
 |
| 12-05-2006 12:05 AM |
 Alert
|
Hi,
Attached, a pdf with the 1.0.4b version of the draft for a set of core conservation tabs. This version supercedes the document at the top of the v.1.0.4 thread. The document presented here is the result of online discussion between workers from (inter alia) the NMAI, the Field Museum, the NMNH, the US Holocaust Memorial Museum, the Winterthur Museum, Museum of Victoria, Carnegie Museum of Art, The Whitworth Art Gallery, and KE Software.
Please encourage conservators at your institution to read this draft and post their comments.
Notes:
1. We believe that the draft is now complete. If there's anything you hate, let us know now!
2. Conceptually, there are three elements to the design of KE screens for the conservation treatment process:
- Catalog-related information (which object is being treated?)
- Recording expert conservation-specific data (treatment documentation required by professional conservation ethics standards)
- A management layer (related to Tasks/Requests/Events/Loans, things like timing, prioritization, and approvals)
Of these, the first and third items are more or less institution-specific and will likely always require some customization. We are working on this core in the belief that much of the second element (conservation record keeping) is common between conservation sub-disciplines, and also common between institutions.
3. The intention is produce a set of core conservation tabs which will be of use to all museums with conservation departments. Some institutions will undoutedly need to subclass the management tabs (vide supra).
Cheers,
JP Brown
Conservator, CRC
The Field Museum
|
|
|
|
|
JP Brown
Posts:26
|
| 12-05-2006 12:51 AM |
Alert
|
| Hmmm..., I don't seem to be able to upload the PDF file. I've asked Forbes to look into it. In the eman time, I can email you a copy if you contact me at jpbrown@fmnh.org |
|
|
|
|
EMuUsers Administrator
Posts:41
|
|
atspin
Posts:0
|
| 18-05-2006 6:32 AM |
Alert
|
Hi JP,
This is my first post to this Forum and I wanted to say how much I look forward to further discussions. It has been a bit difficult to follow what appears to be a year-long discussion given that most of the posts here are dated from October 2005, however, my colleagues here at USHMM has brought me up to date about their involvement in the process of drafting a set of requirements for a core Conservation module.
Thanks for pulling this requirements document together. We’ve had a chance to review it and our comments/recommendations are included in the attached Word document. We look forward to hearing other comments as well.
We need to know a couple of things about where we go from here.
1. How long will the comment period be open?
2. What is the process for finalizing the document?
3. Will we use the Forum exclusively for discussion, or is there an opportunity for a group call, or other ‘get together’?
4. Can you update us on the timetable for the module development?
Thanks,
Angela
|
Attachment: 1519212193771.doc
|
|
|
|
John Doolan
Posts:7
|
| 20-07-2006 3:52 PM |
Alert
|
Dear JP, Ducky and others who worked on this proposal,
Thanks for your efforts and congratulations on the final document. It is concise and well presented.
I had hoped that there might be a few more responses from users and so have been holding back my questions. But we would like to keep this moving and so I'll post my questions anyway.
My questions/observations are:
1. On the Information tab, you have shown a selection of 9 fields from the catalog. As you are aware, each catalog is potentially different. There is no guarantee of a catalog having any particular fields except for a very limited number (IRN, SummaryData, ExtendedData). This means that we can't design the module with these fields in it, even as defaults. The only option would be to design an empty panel (i.e. put the Group Box there). Then the module would have to be subclassed for every installation. No-one could use the base version. I think this is problematic. Alternatively, we could show only certain generic fields (SummaryData, ExtendedData). Sites would have to subclass the module in order to see any other fields.
2. I note that Assoc. Event, Assoc. Loan and Other Reason appear on both the Request and Information tabs. Are these the same backend fields or are they different? If the former, why do they need to be repeated? If the latter, what is the purpose of each set?
3. On the Description tab, I would guess that some institutions would consider that these data should be stored in the catalog. Indeed many catalogs have fields already for materials, measurements and description:
3.1. I note that you say the Materials can push back to the catalog, while Dimensions need to be pushed back to the catalog. Is there a distinction?
3.2. How are you anticipating that values would be pushed back to the catalog (notwithstanding the different catalog designs)?
3.3. Are there any security/permissions issues with conservators updating catalog fields?
3.4. When should they be pushed back? Conservation records will be kept in perpetuity. What should happen if a conservator were to update an old record? Should this push back the values in the Description tab to the catalog again?
3.5. Many catalogs have variations of the measurements grid. For example, some support multiple units, with automatic conversions between units. How would this be addressed on this tab? For example, if this tab did not have all of the dimensions columns that were recorded in the catalog, or it had different columns, then the values pushed back to the catalog would be incomplete or even incompatible.
3.6. Do you expect that these values would be copied from the catalog when a new conservation record is created?
4. How does the Condition tab relate to the Condition tab which appears in most catalogs? Do you expect the Condition tab in the catalog still to be used? If not, does this mean you do not want any audit trail of Condition statements?
5. Also in regard to the Condition tab, is this the Condition before treatment or after?
6. On the Int. Proposal tab, I note you can have more than one Authorization. Why is this necessary? Also, each Authorization entry can have an Approved? value of Yes or No. What does it mean to have both a Yes and a No in the same list? I note elsewhere that you want to implement some tab-switching based on the Approved flag but this is impractical if the flag is actually a list and not an atomic value.
7. On the Ext. Proposal tab:
7.1. You appear to have a list for Proposed By: but are only displaying one value. This is certainly possible but can be confusing to users. Was this purely a screen real estate issue?
7.2. For external objects, is it safe to assume that they would be documented in the catalog? If not, then what happens to the linking information and the "pushing back" of data?
7.3. This tab also has a list of Approved flags. How do these interact with those on the Int. Proposal tab?
8. The Treatment tab appears to support recording of the details of one treatment only. Is this adequate?
9. There doesn't appear to be anywhere to record the results of a treatment. Are you intending that this would be included somewhere in the Treatment text?
10. On the Analyses tab, I note that you allow an attachment to Multimedia using the standard record attachment feature. While this is technically feasible, I believe it is very non-standard and hence not particularly intuitive.
11. The Recommendations tab includes simplified versions of several fields that are included in most catalogs. How do you see these interacting with those catalogs? Should this data be pushed back to the catalog? If so, then this suffers from the same problems raised above.
12. On the Non-Digital Media tab, you suggest that the Locator field might be controlled by a regular expression. This is possible but of course will be very institution-dependent and so could lead to more sub-classing of the module.
13. In regard to Special functionalities, when generating duplicate records, what should be done with the object-specific attributes such as measurements, description, condition, handling instructions, etc.? Also do you have a concept for how you see the user interface to this working?
14. Do you believe that this model is adequate for institutions that contract out their conservation activities (as opposed to providing a contract conservation service to others)?
I still have concerns about the 1-to-1 relationship to the catalog. As you are aware, the existing module has a 1-to-many relationship with the catalog, which means that your new design is incompatible with data already stored in the old design. Should those with existing conservation records move to this 1-to-1 model then there will be additional data migration costs for them, which will of course make the decision more difficult.
Again thanks for your input and I look forward to your response.
John Doolan
|
|
|
|
|
Karen Lovaas
Posts:12
|
| 28-07-2006 2:36 AM |
Alert
|
Hi, John and everyone. I haven't had time to thoroughly review all of the proposed changes to the Conservation module, but I must express concern at the proposed change to a one-to-one relationship between the Catalog and Conservation modules. This would, in our opinion, disable one of the primary strengths of the EMu data model, which is the ability to record conservation activity for batches of items without having to create numerous (sometimes hundreds) of individual Conservation module records. If this change were made, the Minnesota Historical Society would be forced to have a totally custom Conservation module; we have too much existing data where multiple Catalog records are attached to a single Conservation record, our policies and procedures are established using the current model, and we would not wish to switch to a model where only a one-to-one relationship was allowed.
Would it be possible, instead, to treat one-to-one and one-to-many relationships between these modules as "disciplines" and set up tab-switching entries that would force EMu to present different screens/fields when the relationship is one-to-one and when the relationship is one-to-many? There could be a field on the first tab in Conservation where the user would select either "one" (meaning that only one Catalog record would be attached to the current Conservation record) or "many" (meaning that more than one Catalog record would be attached to the current Conservation record). The backend could be set up so that multiple Catalog records could be attached to a given Conservation record, but the interface screen for a "one" record could limit the user to attaching only one Catalog record. The "one" value could also, perhaps, control other tabs that might be displayed only in the case of a one-to-one relationship (since I haven't reviewed the entire proposal, I'm not sure what those might be, but it seems possible that some fields might need to display differently depending on whether the the relationship is one-to-one or one-to-many).
This is just one thought about how we might accommodate everyone's wishes with a revised Conservation module. I'm sure John and the programmers at KE might have a better solution.
-- Karen
|
|
|
|
|
DucPhong Nguyen
Posts:17
|
| 21-08-2006 7:25 AM |
Alert
|
John, my apologies for not responding sooner. I'm attaching my responses in a pdf file as there are so many questions ;-)
Our NMAI Conservation staff is very excited about this development. This design supports the documentation requirements that are part of the American Institute of Conservation (AIC)'s Code of Ethics. We look forward to adopting this design and hope that others in the EMu community would join in.
|
Attachment: 182125767871.pdf
|
|
|
|
JP Brown
Posts:26
|
| 22-08-2006 5:41 AM |
Alert
|
> 1. On the Information tab, you have shown a selection of 9
> fields from the catalog... No-one could use the base version. I
> think this is problematic.
I agree. I like this tab, but given that every institution will have to subclass it, there's no sense including it in the base design.
> 2. I note that Assoc. Event, Assoc. Loan and Other Reason
> appear on both the Request and Information tabs. Are these the
> same backend fields or are they different? If the former, why
> do they need to be repeated? If the latter, what is the purpose
> of each set?
The fields were intended to be the same, but, since we are deleting the Information tab on which the duplicates appear (see 1, above), we don’t need to get into this.
> 3. On the Description tab, many institutions would consider
> that these data should be stored in the catalog. Indeed many
> catalogs have fields already for materials, measurements and
> description:
> 3.1. I note that you say the Materials can push back to the
> catalog, while Dimensions need to be pushed back to the
> catalog. Is there a distinction?
> 3.2. How are you anticipating that values would be pushed back
> to the catalog (notwithstanding the different catalog designs)?
> 3.3. Are there any security/permissions issues with
> conservators updating catalog fields?
> 3.4. When should they be pushed back? Conservation records will
> be kept in perpetuity. What should happen if a conservator were
> to update an old record? ...
> 3.5. Many catalogs have variations of the measurements grid.
> For example, some support multiple units, with automatic
> conversions between units. How would this be addressed on this
> tab? ...
> 3.6. Do you expect that these values would be copied from the catalog when a new conservation record is created?
I would prefer that, by default, there be no pushing back from Conservation to the Catalog. The intention behind materials/dimensions fields is to maintain separate, conservation-recognized standards for data entry. These standards are generally independent of (and may directly conflict with) curatorial and registration standards.
> 4. How does the Condition tab relate to the Condition tab which
> appears in most catalogs? Do you expect the Condition tab in
> the catalog still to be used? If not, does this mean you do not
> want any audit trail of Condition statements?
I do not expect them to relate. I understand Catalog.condition to be a record of incoming condition of the object, primarily used by registrars during the acquisitions process and also, possibly, updated by Collections Management. Conservation.condition is a standard part of any conservation condition/treatment report and has different purposes.
> 5. Also in regard to the Condition tab, is this the Condition
> before treatment or after?
I don’t know how this varies over all the KE user institutions, but at all the labs in which I have worked, condition is the pre-treatment condition.
> 6. On the Int. Proposal tab, I note you can have more than one
> Authorization. Why is this necessary? Also, each Authorization
> entry can have an Approved? value of Yes or No. What does it
> mean to have both a Yes and a No in the same list? I note
> elsewhere that you want to implement some tab-switching based
> on the Approved flag but this is impractical if the flag is
> actually a list and not an atomic value.
I, personally, agree that having multiple approvals is confusing. However, apparently this is how some museums work, so I guess it's going to have to stay, whether or not it can be used to automate tab-switching.
> 7. On the Ext. Proposal tab:
> 7.1. You appear to have a list for Proposed By: but are only
> displaying one value. This is certainly possible but can be
> confusing to users. Was this purely a screen real estate
> issue?
Yes, this was a screen real-estate problem and I agree it is confusing. I will look at it and try to figure out a work-around.
> 7.2. For external objects, is it safe to assume that they would
> be documented in the catalog? If not, then what happens to the
> linking information and the "pushing back" of data?
I don't know how safe this assumption would be. In general I would prefer that there not be any 'floating' conservation records (i.e., orphaned from the catalog), so this implies the creation of 'spoof' records in the catalog, e.g., for objects coming through on loan. Our registrar is happy with this sort of procedure, but other institutions' mileage may vary.
> 7.3. This tab also has a list of Approved flags. How do these
> interact with those on the Int. Proposal tab?
I don't know. This is one for Ducky. Personally, I would be happy to delete all the proposal, approval, and accounting tabs --I don't particularly like implementing workflow in a database (but that's just me).
> 8. The Treatment tab appears to only support recording of the
> details of one treatment only. Is this adequate?
Yes. I feel that the treatment areas should be a single block of text.
> 9. There doesn't appear to be anywhere to record the results of
> a treatment. Are you in0tending that this would be included
> somewhere in the Treatment text?
Result is generally described at the end of treatment report as a part of the treatment.
> 10. On the Analyses tab, I note that you allow an attachment
> to Multimedia using the standard record attachment feature.
> While this should be technically feasible, I believe it is very
> non-standard and hence not particularly intuitive. I am not
> particularly comfortable with this approach (without being able
> to articulate why). Perhaps Bern might offer a comment here.
We can let this go. An alternative approach (somewhat more clunky, but perfectly doable) is to attach mm relating to analysis in the regular Multimedia tab and note in the analysis result that there is a mm record (e.g., gif of a graph, or excel table of results) in the Multimedia tab.
> 11. The Recommendations tab includes simplified versions of
> several fields that are included in most catalogs. How do you
> see these interacting with those catalogs? Should this data be
> pushed back to the catalog? If so, then this suffers from the
> same problems raised above.
Again, I don’t expect this to be pushed back to the catalog. The Conservation.xxxrecommendation fields are for generating conservation reports and are distinct from recommendations elsewhere in the database. Individual institutions may choose some reconciliation mechanism between recommendations in the Catalog and in the Conservation fields, but I don't think this is required.
> 12. On the Non-Digital Media tab, you suggest that the Locator
> field might be controlled by a regular expression.
> This is possible but of course will be very institution-
> dependent and so could lead to more sub-classing of the module.
Ummm..., the point here is that the format of the record locator is institution dependent. In our lab we record photos as year.roll.exposure_number, so for validation we would something like an MS RegularExpressionValidator that made sure the expression was nnnn.nn.nn. It doesn't seem like this would be hard to implement as customizable using an administrator-settable registry entry.
> 13. In regard to Special functionalities, when generating
> duplicate records, what should be done with the object-specific
> attributes such as measurements, description, condition,
> handling instructions, etc.? Also do you have a concept for how
> you see the user interface to this working?
This goes to the 1-1/1-many problem. See remarks in the final para.
> 14. Do you believe that this model is adequate for
> institutions that contract out their conservation activities
> (as opposed to providing a contract conservation service to
> others)?
I think this is reasonably compatible with standard objects conservation documentation. I do not see why contractors' reports could not be formatted (e.g., with XML markup) so that treatment reports could be imported correctly. However, it is not adequate to record the existence of off-line hard-copy reports (which is an interesting thought -- Ducky?).
> I still have concerns about the 1-to-1 relationship to the
> catalog. But this may well be a question that has to go to the
> whole user base. Should those with existing conservation
> records move to this 1-to-1 model then there will be additional
> data migration costs for them, which will of course make the
> decision more difficult for them.
Yes, I have concerns too. I would prefer 1-conservation-record-to-many-objects model because it is more extensible. The more I think about it, the more I think it could be done (although using the existing input screens it would rely heavily on decent data entry in some areas). What does everyone think?
Cheers
JP
|
|
|
|
|
Robin Green
Posts:1
|
| 26-08-2006 1:56 AM |
Alert
|
Hi John, Ducky, JP and everyone who has been working on this,
I have held back from commenting on the developments, as they broadly supported our needs at Lancashire. After talking to John last night, I realise that now is the time to add our views.
Taking the points in the order raised by John, and taking on board Ducky’s comments:-
1. The Information Tab: we can live quite happily with just the object summary data being visible. You can always click on the blue arrow if you want more detail. If this field moves to the Request tab and the Info tab is dropped, we would still have an acceptable system.
2. No comment, other than above.
3. We strongly support the view that these fields should NOT be pushed back. Our conservators like to record dimensions and materials in their own particular way – i.e. millimetres – whereas we need the Catalogue fields that are published on the web to be in units and terms that the public (and Curators!) understand – i.e. centimetres. We don’t want to end up with a situation where data is being altered depending upon whether it’s a curator or a conservator who last edited the record!
4. We agree completely with Ducky – it’s a different type of condition.
5. It’s the condition before treatment.
6. We would need to record the Authorization process in two stages. As Ducky says, internally it would be the Conservation Manager and the Curator or Head of Collections, depending upon the cost. For external work, we need to record the client’s approval, so we would prefer the second of Ducky’s suggestions – the extra value that indicates the final decision.
7. On the question of external objects, yes we treat external objects (up to 50% of our workload). I’ve sold EMu to the conservators on the basis that it allows us to upgrade our tracking of external objects – we will be creating skeletal records for all the external objects we treat.
8. Treatment. I think we would probably use this only for an overall description of the total treatment on the object, probably as the treatment (or each section) is completed. We would record who did it on the accounting tab, although we have yet to work out the precise methodology for this.
9. We agree with Ducky.
10. We don’t, in general, do analyses, but can’t see why a spreadsheet attached to the Multimedia tab should get lost! A note in the Result field could indicate the presence of such an attachment.
11. Agree with Ducky.
12. Not sure about the Locator filed, but guess that a text field would do. Internally, I would push strongly for the digitisation of everything possible and attachment to Multimedia.
13. I personally see no real problem with having a 1-to-many relationship. In my simplistic way, if you want 1-to-1, only attach one object record. Maybe I’m naïve on this one! This would seem to solve the Special functionalities question as well. I have not discussed this with our conservators, though, because I suspect they will not, in general understand the nuances of the concept – they just want a system that works! The problems of pushing data back are solved if you don’t push it back.
I have one further point – the implementation time scale! We have a brand new conservation facility coming on stream as I write. We have brought our team together from two sites (one of which had virtually no IT connectivity) and now have the opportunity to introduce new working practices and procedures. It is hoped that they will be offering a commercial service again from late September. It would be very helpful to know if the new Conservation module will be released by then, or shortly afterwards. I don’t want to have to train staff to use one system, and then in a few months time have to repeat the process.
Cheers.
Robin
|
|
|
|
|
Jessica Johnson
Posts:2
|
| 26-08-2006 9:25 AM |
Alert
|
Hi All,
I have been letting Ducky and JP take the workload on all of this - and first off let me say a huge thanks to both of them for listening to many voices, thinking about what is needed to get us moving, and to developing a very elegant design that will start to allow conservators, who are notorious for doing things their own way, to begin to keep their documentation in a place that is visible to someone besides themselves. We owe these two individuals a huge round of applause.
Second, I want to add my voice to the need to get this moving, hopefully in the near future, as just like Robin, we have a big new crop of employees coming, and I don't want to train twice.
Everyone knows that people don't like to chance their habits. Conservators being part of the general documentation system of a museum is a new habit - there may not be lots of noise about the need, but it is a need, and though I hate to say this as it's become so cliche - if you build it they will come.
Jessie Johnson
Senior Objects Conservator
National Museum of the American Indian
|
|
|
|
|
Julian Tomlin
Posts:11
|
| 30-08-2006 8:25 PM |
Alert
|
I'm pleased to see this proposal getting a lot of close examination and a growing consensus.
I would like respond to a couple of questions and make a few points, using John Doolan's numbering.
3.6 I would not like to see data copied from Conservation to the Catalogue.
6. I would prefer multiple approvals.
6. & 7. I have a suggestion that the internal and external proposal tabs are merged since there is a lot of the same information in both. I would like to see the field 'Context' retained but as a text field. The initial idea was that this field could be used to provide some background information on the proposal, for instance that that full conservation was to be deferred as the object needed to go on show at short notice.
One tab 'Proposal' would cover Context, Task/s, Material/s, Proposer/s and Cost/s. There could be a radio button for internal/external. A new tab 'Authorisation' would cover Name, Comment/s etc. This would mean a gain of real estate on what is currently a very crowded ExtProposal tab.
8. I would prefer to see more than one treatment supported here.
Finally, one to many is fine with me.
Julian Tomlin
The Whitworth Art Gallery |
|
|
|
|
Ian Turnbull
Posts:4
|
| 05-09-2006 2:33 PM |
Alert
|
Hi all,
Many thanks to all who have contributed to this forum.
A lot of excellent information has been discussed and shared and KE Software is appreciative of the time and effort given by all contributors (and by all readers).
We believe the discussion has reached a point where KE can use the content to build a new EMu Conservation module.
In fact we have already begun doing so and anticipate having a first draft available in EMu in October this year.
The broad aims of our development are:
- Accommodate as many suggestions as possible from the discussion in the core design.
- Build the new module such that a reasonably simple upgrade from the existing EMu Conservation module is possible. We believe this can be achieved without need for data export from the old Conservation module for re-import to the new module.
- Support the existing "one conservation record to many catalogue objects" approach. But also provide a simpler "one conservation record to one catalogue object" view so that customers may choose (and enforce) use of the module in that way if that is more appropriate to their business rules.
- Structure the module so that local customisation for particular clients can be accommodated. Pushing data from conservation to catalogue or catalogue to conservation will not be part of the new Conservation module. Customers can sub-class if this functionality is required.
I will submit new Conservation module screen shots to this forum as development progresses.
A number of EMu customers already have in place customisations of the existing EMu Conservation module.
Each of these customers will, in due course, need to consider whether all or part of the new Conservation module supercedes their existing customisations and what adjustments may need to be made.
Regards,
Ian Turnbull
KE Software |
|
|
|
|
JP Brown
Posts:26
|
| 06-09-2006 12:51 AM |
Alert
|
Dear Ian
It's great that KE is taking this on  I'm also incredibly grateful for the time everyone has put into refining the conservation model -- many thanks to all the contributors, but particularly to Ducky for pushing this along.
One point on the relationship between catalog and conservation records:
the relationship can be either
catalog 1--m conservation
or
catalog m--m conservation
(with support for catalog m--1 conservation)
But in either case, a single catalog record *has* to be able to link to multiple conservation records.
Cheers
JP |
|
|
|
|
Ian Turnbull
Posts:4
|
| 22-10-2006 8:31 AM |
Alert
|
Hi all,
Attached are screen shots and brief commentary for the new EMu conservation module. Work is well advanced in incorporating these changes into EMu. We will very soon begin trialling these changes with one customer and once through that phase the changes will become available to all.
As always, comments/suggestions are welcomed.
I expect the changes will be formally released as part of the upcoming EMu 3.2.03 release.
Customers with a sub-class of the existing Conservation module please note that use of the new Conservation functionality will be on an opt-in basis. If you choose to stay with what you already have then that is fine.
Regards,
Ian Turnbull
KE Software |
Attachment: 11022334239971.zip
|
|
|
|
|
| You are not authorized to post a reply. |
|
|
|
ActiveForums 3.6
|