Forgot password? | Forgot username? | Register

Core conservation tabs v1.0.3

Core conservation tabs v1.0.3

This thread is now LOCKED -- please use the v1.0.4 thread.

Hi. Attached, a PDF outlining a possible arrangement of tabs and fields for recording conservation treatments. We are putting this document out for comment and response. The intention is to arrive at a core group of conservation tabs which will form a revised conservation module for the standard KE distro, rather than each institution having to re-write the current (rather unsatisfactory) conservation module from scratch.

The draft presented here was constructed after a round-table discussion involving workers from the NMAI, the Field Museum, the NMNH, the US Holocaust Memorial Museum, and Winterthur Museum. The document has circulated amongst those participants and their comments are embedded in the draft document. We feel that the high degree of interest shown in this draft at the recent KE User Group meeting in Chicago suggests that it would be beneficial to widen the discussion, and the EmuUSers.org forums seemed a natural place for this to occur. Please encourage conservators at your institution to read this draft and post their comments.

Please consider the following before posting:

1. The attached PDF is an outline draft for comments. Nothing is set in stone. The deadline for comments on the current draft (1.0.3) is COB 12 October (EST). We will then revise the design in light of current comments and post the revised version for further comment.

2. Conceptually, we find that that 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.

Cheers,

JP Brown
Conservator, CRC
The Field Museum


Attachment: Summary of Conservation design 1.0.3.pdf

Edited by: Gerard Wood (Axiell Melbourne) - 14-Aug-18 10:24:33

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Notes:

1. Top section of Record Info tab will always require institution specific customization (this is by design).
2. Description, Condition, PhotoDoc, Treatment and Recommendations are intended to be core Tabs, used by everyone.
3. Analyses tab still needs some work, and some people have indicated that they probably will not use it.
4. Proposal and Accounting tabs will not be used by at least half of the people who are involved at the moment. There seems to be a consensus that there needs to be a simpler, text-only proposal tab -- we will be putting one in for the next release.
5. There is no consideration of recording condition surveys, or managing repetitive maintenance tasks (e.g., changing silica gel).

JP Brown
Conservator, CRC
The Field Museum

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Hello All,

Just a few questions/comments on the proposed core conservation tabs.

First I should outline why the current Conservation Module is structured the way it is. When KE first spoke to Conservation staff, they indicated that when conservation was performed a formal conservation document was created in Microsoft Word (or some other word processor) detailing the treatment, etc. When asked whether it was possible to extract information into structured fields the general response was that this was not possible due to the differing work required for each project. In order to facilitate this work flow the Conservation Module does not have any treatment information (or very little) as it was intended that conservators attach their Word document to the conservation record (and use full text retrieval to allow searching of the documents via the Multimedia Repository).

It also became apparent that Institutions needed some scheduling mechanism that allowed curators to request conservation work to be carried out. Hence the current Conservation Module is designed as a request system so people can request conservation work, with the actual work described in a Word Document (with associated images, etc) attached to the request record.

Somme questions/comments about the proposed core tabs:

1. The proposed core conservation tabs are designed to hold the treatment information (amongst other information) within the conservation record. One concern I have is what will happen to information that does not fit nicely into the provided fields. Is it proposed that the conservation doumentation will still be attached to the record (and if this is the case are so many fields required)?

2. While not particularly useful to conservators, I still think there is a need for a "Request" tab where users can enter information requesting conservation work. In many Institutions this starts the conservation process (e.g. conservation work required for an exhibition object, etc).

3. It is unclear from the proposal, but from memory I think the discussion in Chicago decided, that there would be one object only per conservation record? Is this correct? If not then there are issues with repeating information which is recorded on a per object basis (eg. Storage requirements, etc). If there is only one object the * should be removed from the "Object" field on the "Record Info" tab.

4. The "Other Reason" field on the "Record Info" tab is an attachment field. What does it attach to?

5. I am unclear of the need for the "Photo Doc" tab. It seems to be a copy of the standard Multimedia tab. Is there a need for a copy (as opposed to using the Multimedia tab)? Also it is possible to store non-digital data in the Multimedia repository (as a Reference or a URL). Could someone please advise the purpose of this tab?

6. Should the information added on the "Recommendations" tab be fed back into the catalogue record? If not, how do you flag there are some special conditions regarding the use/handling of the object from the catalogue?

Regards

bern.
Bernard Marshall
KE Software
Melbourne, Australia

Bernard Marshall (Axiell Melbourne)
useravatar
Offline
43 Posts
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Dear Bern

> 1. The proposed core conservation tabs are designed to hold
> the treatment information (amongst other information) within
> the conservation record. One concern I have is what will happen
> to information that does not fit nicely into the provided fields.
> Is it proposed that the conservation doumentation will still be
> attached to the record (and if this is the case are so many
> fields required)?

We have been operating a database structure that looks fairly similar to the one proposed here, and find that it encompasses our documentation and reporting needs. The problems do not come from the core treatment documentation fields (Description, Condition, Treatment, PhotoDocumentation) but rather from corner cases in object provenience (e.g., objects from loans).

> 2. While not particularly useful to conservators, I still think
> there is a need for a "Request" tab where users can enter
> information requesting conservation work.

OK, we can add one.

> 3. It is unclear from the proposal, but from memory I think the
> discussion in Chicago decided, that there would be one object
> only per conservation record? Is this correct? If not then there
> are issues with repeating information which is recorded on a per
> object basis (eg. Storage requirements, etc). If there is only
> one object the * should be removed from the "Object" field on
> the "Record Info" tab.

Your understanding is correct -- catalog record and conservation record are intended to be 1:1 and we will remove the * in the next iteration of the design.

> 4. The "Other Reason" field on the "Record Info" tab is an
> attachment field. What does it attach to?

Excellent question. Ummmm..., I don't know. My feeling is that we should remove the link and leave it as a free text field to cover corner cases.

> 5. I am unclear of the need for the "Photo Doc" tab. It seems to
> be a copy of the standard Multimedia tab. Is there a need for a
> copy (as opposed to using the Multimedia tab)? Also it is
> possible to store non-digital data in the Multimedia repository
> (as a Reference or a URL). Could someone please advise the
> purpose of this tab?

Purpose of the tab is combine a text-based indexing facility with the multimedia tab. That is, there are objects for which analog transparencies/negatives/x-rays are taken which are not subsequently digitized. In this case, it is important that the file locator of the transparencies/negatives/x-rays is recorded as part of the treatment file. For instance, the TFM b+w negatives have file locators yyyy-rr-nn (year-roll#-negative#) which allows us to find a particular negative in our filing system. Alternatively, and again at TFM, X-rays are numbered consecutively from 1 onward. These different systems reflect institutional inertia, but also the volume of material and the physical form of filing for storage.

> 6. Should the information added on the "Recommendations" tab be
> fed back into the catalogue record? If not, how do you flag there
> are some special conditions regarding the use/handling of the
> object from the catalogue?

This (I think) is an institution-specific problem and relates to institutional workflow. In some institutions the conservators are the sole generators of handling information. In others, conservation recommendations are one element of a more complex process which includes consideration of factors beyond the structual integrity of the object. An example would be first peoples' sensitivities (e.g., no female handling, must be stored upright, must be kept fed). The latter type of information may be managed by collections managers or curators and combined with conservation recommendations into a general, object-specific statement, of how handling is to be conducted.

Cheers,

JP

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Hi JP,
At MV we've already forged ahead with developing the Conservation Module tabs to accept the transfer of our Conservation Department legacy data and to suit new use.
We still have the actual migration of data part to go so I can't tell you if our design concept is a resounding success. Perhaps our design and experience may in the end contribut to the establishment of the core set though from this entirely different angle? We will need to finally see what does and does not work with our concept but it seems that we've taken some similar paths.

-Conservation staff manage the Conservation module, requests are not made by other collection staff using EMu, other forms of internal proceedures kick in there. Requested By link is retained but entered by the Conservator.
-We've retained some read only aspects of the attached Catalogue data.
-We've gone with the 1:1 but have retained the old "Objects" tab for the legacy material to display through (multiple Parent and Child records may be attached due to the legacy data situation but only the Parent will lead the links and thus display to other areas - still maintaining a viable query via the Reg Number and Department details)
-The display forward of Catalogue information into the main Conservation tab does so upon linking - it is also a queryable set of fields from this point. We think this will enhance and promote their centralised use of the Conservation module.
-The other tabs we've produced pretty much cover what is in your discussion document except for the pure Admin aspects of the "Accounting" tab (request style accounting was rejected here)and "PhotoDoc" (I like where that is going but would it work? - May require MMR development as well? Interesting though)
-We've retained links to Associated Loans & Events.

Hope this helps, when I get my managers back (one was with you all and the other is holidaying over there) I will see about forwarding screen shots if that would be of interest too.

regards,
Lee-Anne

Lee-Anne Raymond
DAMS Manager (Acting)
useravatar
Offline
21 Posts
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Hi, Lee-Ann

Sounds like our proposal is pretty close to what you are doing already [Smile]


> The display forward of Catalogue information into the main
> Conservation tab does so upon linking - it is also a
> queryable set of fields from this point. We think this will
> enhance and promote their centralised use of the Conservation
> module

Yup, I agree -- I think the tedious part of subclassing this area of the tab is well worth the effort.

> "PhotoDoc" (I like where that is going but would it work? -
> May require MMR development as well? Interesting though)

I see no reason why it wouldn't work in the narrow sense of technically achievable within the code base. We are looking at zero or more sub-records, each containing information on image type, file locator information, name and date. This results in a small set (in the technical sense of zero-or-more non-identical records) of sub-records that form part of a particular conservation record object. Considered from a relational perspective, it would be a table of image data linked to the conservation record on some internally generated primary key. So long as image type is controlled by a lookup list, and file-locator is left free text, dates are valid, and the acquirer is linked to the parties module, I think it will work fine across institutions.

The immediate question is whether the UI for this can be spooged into an existing MM tab without making the overall UI for the MM tab too cramped.

The wider implication is that the text information on the conservation-generated not-born-digital material (image type, file locator, name, date, and view description) would be limited to the PhotoDoc tab of the Conservation module, and would not be accessible from a regular MM tab in other modules. I don't think this is necessarily a *bad* thing, but it's certainly something to consider.

Cheers,

JP

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Thanks to Ducky, JP, et al. for undertaking this effort.

Just a few observations/comments:

1:1 or 1:many? I favor retaining the possibility of 1:many, even if in practice there is most always only one object record attached. To display catalogue data in the conservation module for one or more attached objects, I picture something like a cross between the multimedia tab and the objects tabs of the management modules (particularly Events). At the top of the tab you would have a window displaying the specified catalogue fields (read-only), much as the multimedia tab in the catalogue displays some of the multimedia module fields to the right of the media window. Below that there would be a table listing the one or several objects attached to the record. The read only data displayed at the top of the tab would change based on which object is highlighted in the table below, much as the read-only data for attached multimedia records changes as you click on one multimedia icon or another. If there is only one object attached, then there is only one set of data to display.

It seems to me that if this scenario is possible, one can have it both ways--there can be only one object attached, and its information could be displayed just as it would if no more than one object could be attached, as in the prototype; or, there could be multiple objects attached, in which case the conservator would have access to the key catalogue data for each item without having to open the catalogue itself.

On the other hand, if using the 1:1 structure is simpler and less troublesome, I think it is fine, and appropriate for 90% of cases at least. I would just prefer (all other things being equal) to be able to choose how to use the module rather than being forced to use it for one object at a time.

Redundant fields: I have a strong bias against storing essentially the same kinds of data in more than one place. In the conservation module prototype, the fields that strike me as repeating information stored elsewhere are the handling instructions, measurements, and materials. To my mind, these are attributes of the object, not of the conservation treatment (I am assuming here that "Materials" in the prototype means not conservation materials but materials used to create the object--correct?).

Including a place to enter measurements invites the conservator to create another set of measurements for the object that may already be available in the catalogue. Depending on how the measurements are made, there could be slight variations in the data. Then the user has to wonder, which set of measurements is more accurate? (if like me they have great respect for conservators, they would naturally go with the conservation module set, but then, shouldn't those measurements be entered in the catalogue in the first place?)

Similarly materials and handling instructions. As someone at our sidebar meeting in Chicago mentioned, it is hard enough to get staff to look in one place for important information. If they have to look in the catalogue for handling instructions, but also check conservation in case there is something different there, they will probably end up asking for a hard copy report specifying which handling instructions to follow. It is potentially too confusing. Future staff will be confused about which set of instructions is to be considered the primary set.

Instead, I could imagine the handling data from the catalogue displayed read-only in the conservation record, while providing the conservators access to edit the handling instructions in the catalogue, if they are not sufficient or non-existent. Or the inverse of that: storing the handling data in the conservation module and displaying it read-only in the catalogue (the downside to that approach is that there has to be a conservation module record for every object requiring handling instructions, whether or not it is undergoing any conservation treatment).

Tracking: I understand that the management layer is not the primary focus of this design. However I do think that being able to keep track of when a request was made, when the work is due, and when it is actually finished, are important to include. It shouldn't take up too much space, perhaps on the Proposal tab.

PhotoDoc: I think this is a good way to deal with the vexing problem of referencing both digitized (multimedia module) assets and off-line analogue assets. Institutions who catalogue all of their media assets in the catalogue might opt for a linked field here instead of text.

Authorization: From the notes I see there has already been discussion about the problem of denied proposals etc. I agree with the point made by JEK about partial treatment approval, or approval of treatment options offered in the proposal. I don't know how one would handle this, but it is a valid point and something that happens more frequently than one might imagine.

Thanks for offering me the opportunity to comment and thanks for all of your work on this module.

Will Real
Carnegie Museum of Art

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Dear Will

Many thanks for your comments. You have highlighted many of the areas we have been struggling with.

?:1 or 1:many? I favor retaining the possibility of 1:many, … On the other hand, if using the 1:1 structure is simpler and less troublesome, I think it is fine, and appropriate for 90% of cases at least. I would just prefer (all other things being equal) to be able to choose how to use the module rather than being forced to use it for one object at a time.]

I don't feel strongly about 1:1 vs. 1:many – the reason we have gone with 1:1 is that it simplifies the data model. Once you get into 1:many it is not clear how you deal with, e.g., writing the condition report for multiple objects.

[Redundant fields: I have a strong bias against storing essentially the same kinds of data in more than one place… handling instructions, measurements, and materials…].

'Conservation.Materials' relates to object construction materials. The point I would make is that quite often the data is not, in fact, redundant. On materials, consider the case of an object whose 'Catalog.Material' is German Silver. This may be a perfectly correct datum, but is not useful from a conservation point of view: if the materials of the alloy are silver (+ small copper component) then it is silver alloy and the adjective German relates to its provenience, and you may need to take steps to reduce atmospheric sulfur levels to prevent tarnishing. On the other hand, if the materials are copper, zinc and nickel, then it is a copper-zinc-nickel alloy: the adjective 'German' relates to the popular English name for a 19th century alloy of that composition, which gives us a clue to the date of the object, and sulfur scavengers are unnecessary. Now, I do not want to lose the information that the object was cataloged as 'German silver' because that gives us either provenience or chronology information, and may be important for technological searches; OTOH, I do want a correct chemical description of the object for conservation purposes. What we gain in having two fields is clarity of meaning (at least in the conservation module).

[Including a place to enter measurements invites the conservator to create another set of measurements for the object that may already be available in the catalogue. Depending on how the measurements are made, there could be slight variations in the data. Then the user has to wonder, which set of measurements is more accurate? (if like me they have great respect for conservators, they would naturally go with the conservation module set, but then, shouldn't those measurements be entered in the catalogue in the first place?)]

Again, conservation measurements are generally made for specific purposes and are likely to create more detail (measurements of parts) than would be countenanced in the catalog entry; keeping the two separate also allows specific measurements for loan object mount building. I know that some conservators feel strongly that there should be a separate measurement facility in the Conservation tab. I don’t see why a particular institution can't decide that they will periodically update Catalog measurements from conservation (where these exist), but I don’t see that there is an absolute need to collapse Catalog measurements and Conservation measurements into one set of fields.

[Similarly …handling instructions. As someone at our sidebar meeting in Chicago mentioned, it is hard enough to get staff to look in one place for important information. If they have to look in the catalogue for handling instructions, but also check conservation in case there is something different there, they will probably end up asking for a hard copy report specifying which handling instructions to follow. It is potentially too confusing. Future staff will be confused about which set of instructions is to be considered the primary set.]

Again, we have two similar but distinct purposes. I regard 'Conservation.Handling Instructions' as data that goes in the printed report that accompanies an object on loan. These requirements are similar to, but distinct from, the requirements for handling an object in-house and might include uncrating instructions and mounting methods that only apply to the particular loan. Perhaps we need a better name for the field... Again, it is up to the institution how they handle handling instructions. At TFM we do not, for instance, include handling instructions on our printed Treatment reports, but they are invariably included in our printed loan condition reports.

[Instead, I could imagine the handling data from the catalogue displayed read-only in the conservation record, while providing the conservators access to edit the handling instructions in the catalogue, if they are not sufficient or non-existent. Or the inverse of that: storing the handling data in the conservation module and displaying it read-only in the catalogue (the downside to that approach is that there has to be a conservation module record for every object requiring handling instructions, whether or not it is undergoing any conservation treatment). ]

I agree about the downside of linking the conservation data read-only to the catalog module : )

[ Tracking: I understand that the management layer is not the primary focus of this design. However I do think that being able to keep track of when a request was made, when the work is due, and when it is actually finished, are important to include. It shouldn't take up too much space, perhaps on the Proposal tab. ]

We have added a Request tab, which deals with most (all?) of this. The v1.0.4 should be out any day now.

[ PhotoDoc: I think this is a good way to deal with the vexing problem of referencing both digitized (multimedia module) assets and off-line analogue assets. Institutions who catalogue all of their media assets in the catalogue might opt for a linked field here instead of text. ]

I'm glad you like it : ) I've been thinking some more about this, and I'm not sure that it wouldn't be better to revise the Multimedia module to accept more data, rather than having this just in the conservation module. The problem with the MM module that I have worked with is that there is no method of describing the whereabouts of non-digital media – if you create a MM record with no digital content, only the IRN is displayed in the MM pane of the related record (a useful datum, but not very informative by itself). Also, there does not seem to be any method of archiving the whereabouts of digital media which are not stored in the KE MM module. It might be better to add an 'asset location' field in the MM module's metadata tab, and have the MM tab in related records (e.g, conservation records) show a list view which includes this field.

Again, many thanks for your comments -- a great spur to clearer thinking.

Cheers,

JP Brown
Conservator CRC
Field Museum

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

JP

Thanks for the reply, which confirms for me that in most cases the issues I raised have to do more with usage than structure, and are to be resolved by laying out very clear instructions for the users to avoid any confusion about what kind of information goes where, and why.

[Once you get into 1:many it is not clear how you deal with, e.g., writing the condition report for multiple objects.]

Right; the only reason you would ever create a single conservation record for multiple items is if the condition, treatment, etc. are literally identical for all objects attached. While rare, this does happen occasionally; in such cases a condition report/treatment proposal is written for the group, rather than one by one. So I don't think you want multiple condition details for multiple objects in the same conservation record--only a way to apply identical condition/treatment data to more than one object, in those unusual cases.


[I do not want to lose the information that the object was cataloged as 'German silver' because that gives us either provenience of chronology information, and may be important for technological searches; OTOH, I do want a correct chemical description of the object for conservation purposes. What we gain in having two fields is clarity of meaning (at least in the conservation module)]

Right, I'd not considered that. I think this is an instance of clarifying usage--so the conservators know that they need not replicate materials that are already sufficiently described in the catalogue, but rather to use this field to elaborate on materials insofar as they bear upon the preservation or treatment of the object.

[measurements of parts]

At CMA, we catalogue to the part level in most cases, and store measurements of parts in the part-level catalogue records. This is probably nuts, but that is what we set out to do. Also our measurements tab in the catalogue, which is far from ideal, does nonetheless allow the entry of multiple measurement sets, including, I would imagine, mount measurements (though in our case this particular issue has not come up yet). But as you pointed out, if the conservation measurements are really so specific perhaps they ought not be recorded in the catalogue. And again, the key would be to clarify for the conservators that this field is not meant to replicate basic object measurements that are already in the catalogue.


['Conservation.Handling Instructions' as data that goes in the printed report that accompanies an object on loan. These requirements are similar to, but distinct from, the requirements for handling an object in-house]

I can see the logic behind this. On the other hand in my experience (at least for the types of objects in our collection) the handling instructions for loans are fairly static. That is, if an object is loaned more than once, its handling instructions would most likely be the same, or nearly so, in each loan. If that is so, I am thinking that an additional tab in the catalogue, similar to the canned Display, Storage, Illumination etc. tabs, called something like "Loan requirements", might be useful. Where this approach would fail is if the institution wants to retain in the database the specific instructions made for every loan in an object's history. If keeping this level of detail for posterity is not important, then tweaking/updating the loan handling instructions from time to time would work. Just a thought mind you from someone who is working too late [Smile]

[PhotoDoc]

this whole conundrum relates very much to the discussion of the multimedia/media asset data model discussion that is underway in another forum. It would be nice if we could have a better sense of where that is headed so it could be incorporated into our thinking re: the conservation design. I'd weigh in on that but I cannot quite get my head around it just yet...

OK, I'm done, thank goodness

Will

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

I have a couple proposals to the group.

1) Should we add a Notes tab that supports many notes (nested table) to allow for all institution-specific textual information that do not fit the standard process? For example, at NMAI, we have consultations with native communities prior to doing treatments. These object-specific consultations are recorded in its own field in the current database. Rather than designing our own tab to hold this kind of information, it would seem more practical to include that information in a Notes tab. Attached is a screen shot of the Notes tab in the NMNH Catalog.

2) We would like to add a new field to the Condition tab for storing treatment goals. Again, this is NMAI specific because sometimes treatments need to be done differently based on native communities' recommendations. Our thinking is that the field could be hidden (via the Registry) for other museums who do not use this.

Feedback is most welcomed!

Ducky
NMAI

Attachment: Notes tab.pdf

Edited by: Gerard Wood (Axiell Melbourne) - 14-Aug-18 10:26:09

CIS Manager / EMu whipping girl

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

I have put together this response to proposed changes to the conservation module from discussions with conservators at Manchester City Galleries (Amanda Wallace) and the Whitworth Art Gallery (Ann French and Nicola Walker).

We are quite happy with the process driven arrangement of the current module but welcome the ability to record information in specific tabs relating to condition, analyses, proposed treatment and treatment.

Record Info
Should this be renamed Information? This name is used in other tabs. From the current module we would like to have the fields Conservation Number and Status, and Request Details. This needn’t be used by everyone but is a very good way of seeing what stage the conservation is and informing people that work is complete.

Ref the object/s, we would want to allow for more than one object as this would allow some flexibility. Displaying the Summary Data for the object/s would seem the best option. The Current Location field might be useful as a read-only field. We would like to have a notes field alongside the object to record contextual information. The Notes field could also be used to record information on objects which are not in the Catalogue. The Events and Loans module have a notes field alongside the object field.

The Associated Event and Associated Loan are important fields. Can Other Reason be a look up list? We would use this to record project names etc.

Description
This is welcome as it allows for amplification of the description in the Catalogue module. Can we use the same approach to recording measurements as in the Catalogue module? Add Recorder and Record Date.

Condition
It would be useful to have two fields – Summary and Detailed Information. Add Recorder and Record Date.

PhotoDoc
We would like to retain the standard Multimedia tab and add another tab for other Related Non-Digital Media. These might include paper based reports so PhotoDoc and Images are not appropriate headings. The fields should include Reference Number eg Kind | Ref No | Description | Location | Date

Analyses
We would be interested in some kind of link to relevant multimedia here. Whilst a report might be in the Multimedia tab it is not always easy to identify amongst many other items.

Proposal
We would like to include the context for the conservation. For instance sometimes minimal work is done to prepare an object for display at short notice. Looking back conservators can then question why only minimal work was done. This might also cover Ducky’s wish to store treatment goals. We suggest two fields – Context and Proposal plus Proposer and Proposal Date.

We would like to see the accounting information related to proposed conservation moved to the accounting tab. This would seem more logical and in many cases would prevent the need to enter the information twice (see Accounting). We would like to retain all the costs information as we sometimes recharge.

Treatment
Add Treated by and Treatment Date and Supervisor. Maybe this should be a nested table to allow for a number of treatments by different people at different stages. Would a checkbox for Completed be convenient?

Accounting
See Proposal above. Is there an easy way of recording changes from what was proposed? This would save entering the data twice. Is Completion Date the same as Treatment Date/Treatment Completed? It might be more relevant to have a checkbox Accounting Completed.

Add Insurance Details link as existing.

Recommendations
We felt that a general Recommendations field should record recommendations that arise from this conservation report and that the catalogue module as now should record recommendations over and above standard practice.

There should be fields to record Monitoring Requirements and Future Treatment with a recall contact and date.

Tasks
Add the standard tasks tab.

Notes
Add the standard Notes tab or Ducky’s new improved version!

Shortcut
Can a shortcut be created to enter the current user into fields supported by the Parties module. This could save lots of work entering your own name.

Thanks

Julian Tomlin

Julian Tomlin Head of Administration and Operations
The Whitworth Art Gallery The University of Manchester Oxford Road Manchester M15 6ER United Kingdom

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Dear Ducky

[Should we add a Notes tab that supports many notes (nested table) to allow for all institution-specific textual information that do not fit the standard process? For example, at NMAI, we have consultations with native communities prior to doing treatments. ]

I'm all for a notes tab. But, if we do it as a nested table, won't there be a problem if someone uses return characters in the text of the 'Notes.Notes' field (e.g., to start a new paragraph)?

Cheers

JP

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Hello JP,

The issue with return characters in the text of nested tables not aligning correctly is fixed in EMu 3.1. I have attached a general purpose notes field used by AMNH in all modules which may be worth considering.

Regards

bern
Bernard Marshall
KE Software
Melbourne, Australia
https://emu.axiell.com/images/agorapro/attachments/62/notes.jpg

Edited by: Gerard Wood (Axiell Melbourne) - 14-Aug-18 10:27:32

Bernard Marshall (Axiell Melbourne)
useravatar
Offline
43 Posts
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Dear Bern

[I have attached a general purpose notes field used by AMNH in all modules which may be worth considering]

Very cool. I'll drop it into the 1.0.4 version.

Cheers,

JP

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Dear Julian

[Record Info. Should this be renamed Information? This name is used in other tabs. From the current module we would like to have the fields Conservation Number and Status, and Request Details. ]

OK, we can rename as Information. We are adding a Request tab which will have most of the current module information. Should Conservation Number go on the Information sheet as well?

[Ref the object/s, we would want to allow for more than one object as this would allow some flexibility.]

The more I think about it, the more I think that if we go 1:many, then we have to use the 'materials' and 'dimensions' from the catalog. I also think going 1:many will make reporting a huge pain (but I'm open to counter-argument).

[Displaying the Summary Data for the object/s would seem the best option. The Current Location field might be useful as a read-only field. We would like to have a notes field alongside the object to record contextual information.]

The next revision has a Notes tab (see your request below). Would this suffice, or do you want to keep notes in alignment with the objects in the Information tab, as well as a Notes tab?

[The Associated Event and Associated Loan are important fields. Can Other Reason be a look up list? We would use this to record project names etc.]

Done.

[Information. This is welcome as it allows for amplification of the description in the Catalogue module. Can we use the same approach to recording measurements as in the Catalogue module? Add Recorder and Record Date.]

How do you see data entry proceeding for 'Description.Dimensions' and 'Description.Materials' if you have multiple objects?

[Condition. It would be useful to have two fields – Summary and Detailed Information. Add Recorder and Record Date.]

Can you enlarge a bit on the motivation for Summary *and* Detailed Information? Is this a reporting issue? It seeems redundant to me.

[Add Recorder and Record Date.]

We can add it if the auto-enter feature you mention below is enabled. Otherwise, data entry becomes a bit unwieldy.

[PhotoDoc. We would like to retain the standard Multimedia tab and add another tab for other Related Non-Digital Media.]

Yes, on reflection I agree -- the conventional MM needs to stay as it is, and there needs to be another Tab for other non-digital records. I am currently sketching this for the 1.0.4 version.

[Analyses. We would be interested in some kind of link to relevant multimedia here. Whilst a report might be in the Multimedia tab it is not always easy to identify amongst many other items.]

Hmmm... On balance I agree. Maybe there also needs to be a reference link to Bibliography as well (e.g., ref to Oodegard for spot tests).

[Proposal. We would like to include the context for the conservation. For instance sometimes minimal work is done to prepare an object for display at short notice. Looking back conservators can then question why only minimal work was done. This might also cover Ducky’s wish to store treatment goals. We suggest two fields – Context and Proposal plus Proposer and Proposal Date.]

OK, I think the context field could help in some cases.

[We would like to see the accounting information related to proposed conservation moved to the accounting tab. This would seem more logical and in many cases would prevent the need to enter the information twice (see Accounting). We would like to retain all the costs information as we sometimes recharge.]

Ummm..., wouldn't this involve two doubly nested tables? That is, we've got the nested table for Work, and the nested table for Materials, and then you want to nest both of these? I'm not against it, I'm just not clear how it would be represented in the KE UI. I think this could be one of the cases where institutional workflow demands that you do your own subclassing.

[Treatment. Add Treated by and Treatment Date and Supervisor.]

I'm trying to get a fix on motivation here. Is it the intention that the supervisor 'signs off' on each treatement stage, or is it the intention that it is simply recorded that 'Jane Bloggs' was the supervisor. Is it the case that most/all treatments will be supervised by someone? In the case of treatments performed by interns and supervised by staff, we would usually just add both names to the 'treated by' field -- the fact that one is an intern and the other is a staff member can be disambiguated at the Parties module.

[Treatment. Maybe this should be a nested table to allow for a number of treatments by different people at different stages.]

Again, this seems cumbersome. I agree that there are cases where someone takes over treatment form someone else (e.g., staff member leaves/is reassigned), but this can be indicated in the report text.

[Treatment. Would a checkbox for Completed be convenient]

I think there is some overlap with 'Request.Status' here. How would you resolve it?

[Accounting. See Proposal above. Is there an easy way of recording changes from what was proposed? ]

No, I don't think there is. I think you have to discard changes in the proposal. What you should end up with at the proposal stage is a clear statment of the proposed plan of work rather than a palimpset. Perhaps fields in the Notes tab can be used if it is important to record that a conservator felt one treatment mode was correct, but was overruled during the approvals stage.

[Add Insurance Details link as existing.]
To which tab?

[There should be fields to record Monitoring Requirements and Future Treatment with a recall contact and date.]

I agree, but it widens the scope somewhat from our orignal (narrow) definition of tabs for condition-reporting and treatment-recording. Perhaps you could draft what this would look like.

[Tasks. Add the standard tasks tab.]

Done.

[Notes. Add the standard Notes tab or Ducky’s new improved version!]

Will be adding Bern's version (vide ultra).

[Shortcut. Can a shortcut be created to enter the current user into fields supported by the Parties module. This could save lots of work entering your own name.]

I believe this can be done with a hard-coded routine. I think this feature will be absoutely necessary if we add all the author tagging you request here : )

Cheers,

JP
Conservator, CRC
The Field Museum

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

JP et al.,

[The more I think about it, the more I think that if we go 1:many, then we have to use the 'materials' and 'dimensions' from the catalog. I also think going 1:many will make reporting a huge pain (but I'm open to counter-argument). ]

OK, I'll take the bait [Smile]
When the details of a treatment, including requirements for conservation-specific meansurements and materials, vary from one object to another, it would not make sense to use a single conservation record for multiple objects. It only makes sense to do that if the details of the treatment are literally identical for all of the attached objects.

As an example: In my institution there are certain materials or objects that are routinely fumigated before they are brought into the building for a temporary exhibition. The conservators plan, supervise, and document this "treatment". This treatment does not require conservation-specific measurements or materials descriptions, or an elaboration of the condition of each object. The proposed treatment and actual treatment are going to be identical for each object. There is not going to be any PhotoDoc. So this, I think, is a case where having the possibility of a 1:many would be helpful. OTOH, without 1:many functionality, one could simply ditto the same cons. record for each object treated. Not that big of an inconvenience.

Reporting: without knowing what kinds of reports are needed at other institutions it is not easy to respond, but at CMA, for the above example, there would be a single treatment proposal and a single treatment report, each listing all of the objects, and copies of each would go into the appropriate files for each of the objects involved.

Where the reporting gets complex with 1:many is when you wind up, say, with the objects in a subreport, but you want to report on nested tables or linked fields from the catalogue, within the subreport. You cannot have a subreport within a subreport. The only way around this is to export the nested table as text. Then depending on how you want to output the data, you might have to create complex formulas to split apart multiple values from the nested table and put them back together. So I guess the complexity of reporting would depend upon how much and what kind of data from the catalogue is to be included in the report. If it is lots of data of various kinds, then a 1:many report from the conservation record would indeed be a pain. With 1:1, you don't have to put the catalogue data in a subreport so things are much more straightforward.

Thanks for all the good work and collaborative spirit.

Will
Carnegie Museum of Art

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

This might be getting a bit confusing but these are my response to your email of 20 October. I have only included any controversial points. My most recent replies are prefixed JT, the original points both mine and JPs are in square brackets. It was good to see so many suggestions accepted.

Dear Julian

JT [Ref the object/s, we would want to allow for more than one object as this would allow some flexibility.]
JP [The more I think about it, the more I think that if we go 1:many, then we have to use the 'materials' and 'dimensions' from the catalog. I also think going 1:many will make reporting a huge pain (but I'm open to counter-argument).]

JT- I think that we could go 1:many and still keep the material and dimensions (additional info) in the Conservation module. Obviously, it won’t always work for some records with many objects attached but these will be the exception.

JT [Displaying the Summary Data for the object/s would seem the best option. The Current Location field might be useful as a read-only field. We would like to have a notes field alongside the object to record contextual information.]
JP [The next revision has a Notes tab (see your request below). Would this suffice, or do you want to keep notes in alignment with the objects in the Information tab, as well as a Notes tab?

JT- I would like to see the notes in alignment with the objects as well as the more general Notes tab.]

JT [Information. This is welcome as it allows for amplification of the description in the Catalogue module. Can we use the same approach to recording measurements as in the Catalogue module? Add Recorder and Record Date.]
JP [How do you see data entry proceeding for 'Description.Dimensions' and 'Description.Materials' if you have multiple objects?

JT- see above. An alternative would be to put the object information and description fields in a extensive nested table, a little like Objects in the Events module but maybe this is too much nesting.]

JT [Condition. It would be useful to have two fields - Summary and Detailed Information. Add Recorder and Record Date.]
JP [Can you enlarge a bit on the motivation for Summary *and* Detailed Information? Is this a reporting issue? It seeems redundant to me.]

JT- It is just a way of giving users, particularly non-conservation staff, an overview of the conservation but it could be a local convention to put this in the first para.

JT [Analyses. We would be interested in some kind of link to relevant multimedia here. Whilst a report might be in the Multimedia tab it is not always easy to identify amongst many other items.]
JP [Hmmm... On balance I agree. Maybe there also needs to be a reference link to Bibliography as well (e.g., ref to Oodegard for spot tests).]

JT- Would this be a way of identifying the multimedia better ie you could reference a bibliographic record such as a report. The electronic version of which would be in the Multimedia tab for that record?

JT [We would like to see the accounting information related to proposed conservation moved to the accounting tab. This would seem more logical and in many cases would prevent the need to enter the information twice (see Accounting). We would like to retain all the costs information as we sometimes recharge.]
JP [Ummm..., wouldn't this involve two doubly nested tables? That is, we've got the nested table for Work, and the nested table for Materials, and then you want to nest both of these? I'm not against it, I'm just not clear how it would be represented in the KE UI. I think this could be one of the cases where institutional workflow demands that you do your own subclassing.]

JT-I has hoped Bern might find a way!

JT [Treatment. Add Treated by and Treatment Date and Supervisor.]
JP [I'm trying to get a fix on motivation here. Is it the intention that the supervisor 'signs off' on each treatement stage, or is it the intention that it is simply recorded that 'Jane Bloggs' was the supervisor. Is it the case that most/all treatments will be supervised by someone? In the case of treatments performed by interns and supervised by staff, we would usually just add both names to the 'treated by' field -- the fact that one is an intern and the other is a staff member can be disambiguated at the Parties module.]

JT-OK but it is less obvious. A separate field would allow someone to retrieve conservation where they were supervisor.

JT [Treatment. Maybe this should be a nested table to allow for a number of treatments by different people at different stages.]
JP [Again, this seems cumbersome. I agree that there are cases where someone takes over treatment form someone else (e.g., staff member leaves/is reassigned), but this can be indicated in the report text.]

JT-I don’t have strong views. I suggested it to be more precise but it maybe others have views.

JT [Treatment. Would a checkbox for Completed be convenient]
JP [I think there is some overlap with 'Request.Status' here. How would you resolve it? ]
I was looking at in terms of signing off the treatment stage but it might be redundant.

JT [Accounting. See Proposal above. Is there an easy way of recording changes from what was proposed? ]

JP [No, I don't think there is. I think you have to discard changes in the proposal. What you should end up with at the proposal stage is a clear statment of the proposed plan of work rather than a palimpset. Perhaps fields in the Notes tab can be used if it is important to record that a conservator felt one treatment mode was correct, but was overruled during the approvals stage.]

JT- I was particularly thinking of the benefit of retaining proposed costs and actual costs.

JT [Add Insurance Details link as existing.]
JP [To which tab? ]

JT- to the Accounting tab

JT [There should be fields to record Monitoring Requirements and Future Treatment with a recall contact and date.]
JP [I agree, but it widens the scope somewhat from our orignal (narrow) definition of tabs for condition-reporting and treatment-recording. Perhaps you could draft what this would look like.]

JT- I think that I should come back with some proposals.

Cheers,
JP

That’s all, thanks
Julian

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Dear Julian

[ I was particularly thinking of the benefit of retaining proposed costs and actual costs.]

This is done in the v.1.0.3 version by having two tabs: Proposal and Accounting. As you will, they are essentially identical, but one holds proposed costs/materials while the other holds actual costs and materials.

[......]

We're just about to post the 1.0.4 version, which has some of what you've asked for. Can we defer discussion until that version is posted?

Cheers,

JP Brown
Conservator, CRC
The Field Museum

Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Hi All,
I think Will you point out with absolute clarity the logic of the 1:1 scenario in the end.

It does seem to be correct that the 1:many scenario is the way to go as this is how the system best works; by reducing duplication and in the Collections management sense focusing in on the Catalogue as the core module. However, following years of restraint and being true to this aspect of the system we went ahead and fiddled the Conservation module to suit (thoughts of modifying the Conservation Module were toyed with earlier along the way and rejected as too expensive or not a good solution in context with the system functions). We realised after getting most of our collections data into the system that the "out of the Catalogue" and 1:many Conservation records scenario would not work without sacrifice. It could not provide the Conservation department with the flexibility and focus in the system they needed, it could further cause confusion with the collections by clashing with the two structured ways of working and create a burden on future users due to the lack of clarity in how it all hung together, it would work but not without forcing it.
We had been attempting to squish Conservation needs in along side the Collection needs in the Catalogue, whilst doing this we had really been articulating the changes that we needed in the Conservation Module itself. The designs when placed in the "out of the Catalogue" scenario were creating a monster and revealing just how awkward the existing Conservation module was in its current state. We would still need to substantially modify the Conservation module if it was going to be anything more than a mere "holder" of links to the Catalogue.
Additionally the "out of the Catalogue" scenario was not going to be manageable in context with what the collections staff needed to do and the conservators needed to do in the system.
Conservation needed to be the core module for the conservators to use EMu properly and work in real time along with the collections through the system.
The resolution to all of this it was to go back to the Conservation module - it is designed as a 1:many module - we simple dispensed with this and all the rest slotted into place.
We did need to create duplication in the end which some may gasp at but it relieved allot of the pressure on the 1:1 scenario. We duplicated dimensions, environment and materials tabs, gave them a completely separate back end from the existing Catalogue ones. This freed us up as well for pretty much everything else the Conservation module needed, job detail, treatments, condition, samples/tests, etc. We could work sensibly towards an "out of the Conservation module" scenario finally.
It took us a few years to get to this, and in the end were able to apply what we learnt from each of the Collection's data migrations along with a reasonable budget for enhancement to finally make it possible for us to be flexible.
We are sure to have further enhancement requests once Conservation start using the system too, we are only to our first load test for their transfer into EMu.
It may not be everyone's experience but I think it is important to let the forum know we made mistakes in our original thinking but also made some correct assumptions early on, we just got distracted off the better path by budget which in turn affected the concept.

Regards,
Lee-Anne
Museum Victoria

Lee-Anne Raymond
DAMS Manager (Acting)
useravatar
Offline
21 Posts
Administrator has disabled public posting. Please login or register in order to proceed.

Re: Core conservation tabs v1.0.3

Hello to All,

I am only now catching up on the discussion. I have not mapped out all the issues, replies, and solutions, so please forgive me if I am redundant and guide me if I am claerly off course.

Regarding the 1:1 or 1:many question. Yes, there are batch treatments as well as mass treatments that deal with the many. You will find these quite common in archives. The USHMM, being a hybrid institution with both museum and archival holdings, does deal with both individual and batch treatments in our conservation labs. Will is correct that all the details on each individual item is not recorded for a batch treatment. Our object numbering system allows us to identify the whole collection as undergoing a batch treatment as well as to identify individual items from a collection that are undergoing single item treatments. So, the question for me then becomes how these relate to each other. In the catalogue, we have the parent-child which, I believe, should carry over into the conservation module, yes? A related question is, does one necessarily have to cut and paste the batch treatment procedures for each item in the collection, or can one report be associated with the collection as a whole? Think in terms of a run of historic newspapers rather than a mixed media collection. In an archival cataloguing system, they are given a record group number and not number individually by the registrars. At the USHMM, when one of the newspapers is pulled for exhibition and is in need of conservation treatment, it is then given an item number which follows the record group number (hybrid institution, hybrid system). Therefore, the individual item may have received the batch treatment, but is now undergoing single item treatment, therefore two conservation reports associated with this one item.

Regarding a context field in the proposal: is this not redundant to purpose? I really do not understand the difference. I am also under the impression that having purpose as a drop-down field can allow one to add/customize the choices. If so, context may be taken care of here, unless I misunderstand what is meant by context.

Now I am on to something that the discussion seems to have touched upon but not in any detail. Our treatment proposals often give options. Sometimes the curator signs off on the least invasive, sometimes on the full treatment depending on a number of factors (intrinsic value, insurance value, time, etc). I would place all three options in the proposal narrative, thus we have a record of all the considered approaches. Where, however, would the approval for which option be specified? I may have posed this question at our meeting at NMAI, so forgive me if I am repeating myself. If the approved? field is not a Y/N only, this would allow for specification. This may, however, be an intitutional customization. But part of my point here is that a concern was voiced regarding maintaining a record of different treatment approaches. I think simply placing the options (a, b, c) in the free text field and documenting which was approved could satisfy this concern.

Administrator has disabled public posting. Please login or register in order to proceed.
There are 0 guests and 0 other users also viewing this topic

Board Info

Board Stats
 
Total Topics:
603
Total Polls:
0
Total Posts:
1363
User Info
 
Total Users:
871
Newest User:
Monica Syrette
Members Online:
3
Guests Online:
132