Feature Request - Deaccessions

[acdoll]

Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html

Is your feature request related to a problem? Please describe. We'd like to track our deaccessions.

Describe what you're trying to accomplish Track the details of deaccessions (numbers, specimens, dates, people involved, dispositions ...)

Describe the solution you'd like Something just like the accession records. Additional details required: Disposition: discarded, destroyed, transferred Status: in process, complete Approved by (if transferred) Received by (if destroyed) Witness of Destruction Attached documents

Describe alternatives you've considered Continue not tracking deaccessions in Arctos

Additional context Probably will require some bulkloading capabilities, but that can come later.

Priority Normal priority - not preventing any work, but would be nice

@mkoo @ebraker @ewommack @lin-fred

See a summary as at https://github.com/ArctosDB/arctos/issues/4189#issuecomment-995994456

[dustymc]

This has come up a few times, we always come around to the idea that deaccessions are just loans. I continue to believe that this is the best way to handle the situation - one data object to track stuff leaving your custody, for however long and with whatever expectations for return.

I think that's been a transfer of custody loan type but I'm not sure of that. I'd certainly have no objections to a more-dedicated loan type.

Also no objections to more roles if necessary.

Certainly needs documentation - I'm sure we had that at one point but I can't find it now....

[lin-fred]

NPS definition: Deaccessioning is the process of permanently removing an object or document from a repository's collection, thereby signifying a change in ownership and custody through a change in title.

MRM5 definition: Deaccession: An object that has been removed permanently from the museums collection; Formal removal of accessioned objects from the museum's permanent collection

To me, a transfer of custody is a deaccession, but deaccession is the more official and legal word. I disagree with the definition currently with transfer of custody :Items are transferred to another institution. All or some rights may be retained as specified in the loan.

How can there be partial or all rights?

[Jegelewicz]

Maybe we just need a new loan type = deaccession?

[dustymc]

deaccession is the more official and legal word

I still have no objections to a new loan type.

I think the idea is that the shredder is an "institution" but I'm still not sure (and that's a little messy if it's the case).

How can there be partial or all rights?

Loan agreement says "you can.... but you are required to......" or "its yours have fun" or ....

The NPS definition is definitely what transfer of custody is aimed at - it's still out there, we might have extra data but we don't have the thing we gave away. If a new term comes to exist it should be clearly separate from any existing.

[Jegelewicz]

deaccession - indicates permanent removal an object or document from a repository's collection, thereby signifying a change in ownership and custody through a change in title.

BUT this seems denormalizing? just another way to say "transfer of custody"? Maybe we should just change "transfer of custody" to deaccession? Is there any other transfer that isn't a deaccession?

[dustymc]

just another way to say "transfer of custody"?

That should definitely be avoided. I don't care what the distinction might be, but if we're to have two terms then there should be a clear one. If we have one term I don't much care how we spell it, as long as it's clearly documented.

Is there any other transfer that isn't a deaccession?

That would have to come from users, but lacking other evidence I'll assume they've followed the documentation.

select guid_prefix from collection inner join trans on collection.collection_id=trans.collection_id inner join loan on trans.transaction_id=loan.transaction_id
where loan_type='transfer of custody' group by guid_prefix;

-------------
 UAM:Herb
 KNWR:Herb
 KNWR:Ento
 UAMb:Herb
 UAM:ES
 BYU:Herp
 UMNH:Mamm
 MSB:Bird
 UTEP:Herp
 UAM:Ento
 UMNH:Bird
 MVZ:Mamm
 UAM:Art
 UAM:Fish
 UAM:Mamm
 MSB:Mamm
 MVZ:Egg
 MVZObs:Mamm
 MVZ:Herp
 MLZ:Bird
 UMNH:Herp
 ALMNH:Geo
 ALMNH:EH
 MVZ:Bird

select
    replace(get_address(contact_agent_id,'GitHub'),'https://github.com/','@') as ghaddr
from (
    select
        contact_agent_id
    from
        collection_contacts
        inner join collection on collection_contacts.collection_id=collection.collection_id
        inner join (
            select guid_prefix from collection inner join trans on collection.collection_id=trans.collection_id inner join loan on trans.transaction_id=loan.transaction_id
            where loan_type='transfer of custody' group by guid_prefix
        ) x on collection.guid_prefix=x.guid_prefix
    where
        contact_role='data quality'
    group by
        contact_agent_id
)x where get_address(contact_agent_id,'GitHub') is not null
;

 @amgunderson
 @jldunnum
 @catherpes,@catherpes
 @campmlc
 @dssikes
 @StefanieBond
 @mlbowser
 @ccicero
 @mkoo
 @cjconroy
 @atrox10
 @mvzhuang
 @aklompma
 @Jegelewicz
 @kderieg322079
 @byuherpetology

[lin-fred]

deaccession - indicates permanent removal an object or document from a repository's collection, thereby signifying a change in ownership and custody through a change in title.

BUT this seems denormalizing? just another way to say "transfer of custody"? Maybe we should just change "transfer of custody" to deaccession? Is there any other transfer that isn't a deaccession?

Yes, transfer of custody is a type of deaccession.

Deaccession comes first, and then either a transfer or disposal is a result.

[acdoll]

Deaccession is as much of a thing as accession - why not treat it the same? It is not a loan. If the disposition is 'discarded', that's not the same as transferring custody to the waste management systems. This deserves its own type of tracking system.

[dustymc]

and then either a transfer or disposal is a result

I'm not sure that's universal - I believe "permanent loans" are involved as well, no further action is expected but there's still some sort of ownership-like arrangement.

I think the reason we always circle back to loans is because that (alleged!) distinction isn't clear - different institutions and disciplines have different words for similar/identical actions. A new node would set up two structurally different ways of doing the same thing, they'd get used arbitrarily, and nobody could find anything. I'm not saying there is no structural difference, but there's not one that anyone's ever been able to define (at least in a way I have understood). I'm definitely open to the idea that a different structure is required, but I don't yet see any evidence that this is more than a terminology problem.

[lin-fred]

Deaccession is as much of a thing as accession - why not treat it the same? It is not a loan. If the disposition is 'discarded', that's not the same as transferring custody to the waste management systems. This deserves its own type of tracking system.

I think that deaccession needs more than just a code table word as well. It is literally the opposite of an accession, not a loan.

I have difficulties with my records that have been deaccessioned. They are encumbered but still show up when I search for specimens. I want a snapshot of the data as it was left, as we are not curating it any further, but I also don't want to delete the data out of Arctos?

[dustymc]

I'm still up for anything, but I need to understand the structural difference to act on it, and I'm still not seeing that here.

One possible improvement might be to relabel "loans" - the model readily supports usage (and/or whatever "deaccessions" and "transfers" and "permanent loans" and etc. might be called) beyond what most think of as "loans."

I think how the data for not-here-right-now records is handled will vary quite a bit from case to case, but if there's no compelling reason to hide it then leaving it public is probably useful to some users, and keeping it up to date when things change so it remains findable seems like a part of that.

Encumbrances generally only act on the public face of records - you can't hide things from yourself.

[AJLinn]

Yes, transfer of custody is a type of deaccession.

Deaccession comes first, and then either a transfer or disposal is a result.

But you can have a transfer of custody without a deaccession - they're not the same. The deaccession is just a change in your legal/ethical obligation to a certain level of care. You can deaccession something without disposing of it (we've deaccessioned things and changed their status to "exhibit prop / hands-on item" but they're still in our database & files, and they're still on exhibit, we just don't have the responsibility to care for them in the same way anymore).

One possible improvement might be to relabel "loans" - the model readily supports usage

I would support this idea, if we can come up with a new encompassing term to indicate diverse usage, then maybe we could track deaccessions as a project and the transactions of deaccessioning (& disposing) of those items are tracked as a loan/usage that is associated with that project each year?

[lin-fred]

But you can have a transfer of custody without a deaccession - they're not the same.

Can you give me an example?

The deaccession is just a change in your legal/ethical obligation to a certain level of care. You can deaccession something without disposing of it (we've deaccessioned things and changed their status to "exhibit prop / hands-on item" but they're still in our database & files, and they're still on exhibit, we just don't have the responsibility to care for them in the same way anymore).

True that is a change of legality and level of care, but I would consider your example a form of disposal. If you are are not tracking, taking care of something, etc. on the same level as it was accessioned, then it is, in a sense, being disposed of. Maybe not straight in the trash disposal, but on some level it is no longer being taken care of. And if you don't want it to be considered a disposal, then its a transfer from collections to exhibits/education department. Ultimately still a deaccession, and not a loan and no longer being "curated".

Thanks Angie for coming into the discussion, I'm looking forward to what you have to say!

[AJLinn]

But you can have a transfer of custody without a deaccession - they're not the same.

Can you give me an example?

Let me preface this discussion with the fact that I have always disagreed with the existence of the COLL_OBJ_DISPOSITION transfer of custody. Looking at the code table I see we have indicated "DO NOT USE THIS - transfer of custody is a loan type. Use "on loan" for the objects which have been transferred. "Custody" simply indicates possession, with a legal right/responsibility of care. There is no direct correlation to ownership. A loan is a temporary transfer in custody with ownership (title) remaining with whomever accessioned it.

For our definition, disposal is the step taken after removing it from your collection/legal responsibility and a physical transfer of the object to another's possession (whether that's the dumpster, another museum, an auction house, etc.). In the example I used, we did not dispose of the item, its status merely changed. It is still located in the same exhibit location on our property.

But now looking at the same code table I see someone has applied the DO NOT USE label to deaccessioned, and I think that's the bigger issue at hand. It says to use "discarded" or "transfer of custody," which also says DO NOT USE. Deaccessioning is a legal procedure that we undergo and it must be documented either as the object's dispossession or as it's own transaction.

I'd suggest we add this to the next Issues meeting so we can all discuss in person?

[dustymc]

I would consider

I think that's the fundamental issue - from here this still looks like a matter of opinion and terminology, whether that's a matter of tradition, discipline, or what your legal team requires.

I think all "loans" have some sort of legal-ish documentation, and most involve some sort of transfer, whether that's for 10 seconds to snap a photo in the drawer or by hucking something in the dumpster. I don't see any functional/structural split there either, just details.

COLL_OBJ_DISPOSITION

Yea, that's all from a bunch of ways of doing about the same things - that discussion was abandoned long ago, I'd be happy to see it resurrected. FWIW I see disposition as more "we can|can not get our hands on this thing" and the loan documenting (perhaps in great detail) WHY you can't get your hands on it (and maybe who can).

[Jegelewicz]

I think the one thing this points to is that we have no consistent path to finding all deacessioned things right now.

And we need to decide - does deacession belong in the transaction or the disposition of the part? Can we put that word in two places?

We also need to decide whether loan functionality is appropriate for a deaccession.

• If not, why? what is missing from a loan transaction that is required for a deaccession?
• If so, we need a good definition for deaccession as a loan type and a better definition for transfer of custody to eliminate confusion with deaccession and possibly we need to call these kinds of transactions "Use and Disposal" transactions or something of the sort.

What else needs deciding?

[dustymc]

does deacession belong in the transaction or the disposition of the part?

Transaction; that needs explanation, there's a place designed for such information. Disposition is not structurally capable of carrying the sort of information that's being discussed.

put that word in two places

Maybe, but not as a substitute for other stuff. Eg disposition could potentially be used to distinguish between "part still exists (as far as we know) but we don't have it" and "we chucked this thing in the shredder, it is no more, if you think you have it you don't" - but "as far as we know" might be clarified in the loan, I think that's still probably overloaded, "on loan" (or whatever we might eventually decide to call this node) still seems much better as a universal pointer to "we don't have it, click here for more information." I think I've just come around to plain "no" unless there's some compelling argument that I'm not seeing....

[lin-fred]

If not, why? what is missing from a loan transaction that is required for a deaccession?

The legality level. If deaccession is part of loans, then why not have accessions as part of loans?

I think that deaccession needs to basically be a copy of the details in the accession page. It's just the antithesis of an accession and has the same level of legality as an accession.

Then the deaccession and accession pages can be linked, as they will be using the same accession number (or can be assigned its own number). When you deaccession, you don't just deaccession a part of it, it's everything that your institution has that is associated with that object/specimen. And so the disposition can be updated to represent where the parts have gone, but disposition is just part of the deaccession.

[lin-fred]

From AAM:

“Deaccessioning” is used to refer to what is actually a two-part process: first, the formal removal of an item from a museum’s permanent collection and second, determining the disposition of the item.

edit: If I need to get the documents from AAM I do have a login and can share them if needed.

[lin-fred]

Also check out the NPS handbook on deaccessioning https://www.nps.gov/museum/publications/MHII/mh2ch6.pdf

[Jegelewicz]

When you deaccession, you don't just deaccession a part of it, it's everything that your institution has that is associated with that object/specimen.

So how do we treat a bunch of disgusting tissues after a freezer failure when they are thrown out, but the skins and skeletons are sill in a cabinet somewhere? Disposition is "destroyed" and that's it? It makes sense, but I just want to be sure that aligns with everyone's expectations.

[dustymc]

everything that your institution has that is associated with that object/specimen.

That's definitely only one use case. The rotten heart sample is tossed, ideally with paperwork, the skull and skin is kept.

[campmlc]

Sorry to be out of the loop on this one and not having read the whole thread - but in the use case here, I would hope to continue to be able to enter "discarded" or "used up" in the rotten heart part disposition? Would I be required to create a transaction just for a discarded rotten heart?

On Tue, Dec 14, 2021 at 5:40 PM dustymc @.***> wrote:

• [EXTERNAL]*

everything that your institution has that is associated with that object/specimen.

That's definitely only one use case. The rotten heart sample is tossed, ideally with paperwork, the skull and skin is kept.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/4189#issuecomment-994180011, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBH4BDNNUVJMUCZCCQTUQ7PYDANCNFSM5KBPTIWQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[dustymc]

Nope, not required, this is just a mechanism to record why you no longer have something with some formality. If it's a holotype - yea, probably a good idea to have some extra paperwork. Rotten RBV from the low-data pile? Not so much....

[campmlc]

Thanks for the clarification. This makes sense.

On Tue, Dec 14, 2021 at 5:59 PM dustymc @.***> wrote:

• [EXTERNAL]*

Nope, not required, this is just a mechanism to record why you no longer have something with some formality. If it's a holotype - yea, probably a good idea to have some extra paperwork. Rotten RBV from the low-data pile? Not so much....

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/4189#issuecomment-994188807, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBA5N56O6T4HKW4XJI3UQ7SARANCNFSM5KBPTIWQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[dustymc]

legality level

Maybe something in that's what I'm missing, but I still don't understand the distinction - all transactions have a place for whatever legal (or other) documentation is necessary.

deaccession is part of loans, then why not have accessions as part of loans?

The data objects involved are different.

disposition can be updated to represent where the parts have gone

Disposition is not structurally capable of that.

[AJLinn]

does deaccession belong in the transaction or the disposition of the part?

Transaction; that needs explanation, there's a place designed for such information. Disposition is not structurally capable of carrying the sort of information that's being discussed.

I vote create a new kind of loan/usage=deaccession. Sometime we deaccession one object, sometimes we deaccession many as a group. If it's a transaction (like accessions and loans, both actions with legal implications):

• We can include shipment information, which could be the mode of disposal depending on how things are disposed of.
• We can upload media, which might include photographs of a melted freezer, intentionally destroyed objects, PDFs of deaccession justification worksheets (if relevant), or other forms of documentation.
• The deaccession can be assigned a unique transaction number for tracking and correlating to paper files.
• (Maybe most importantly?) we can associate individual catalog records to the transaction and the transaction will show up in that catalog record.
• The physical disposition of the object/parts can still be reflected (as Dusty says, can I get my hands on this piece or has it become dust in the wind...) within the catalog record.
• We could connect it to a Project, which could pull together deaccessions from different collections (e.g., we might have a repatriation that includes human remains in the archaeology collection and sacred objects in the ethnology & history collection and we want to link the actions (which requires collections be deaccessioned and then the mode of disposal is repatriation) of both collections.

[lin-fred]

The data objects involved are different.

@dustymc how are they different?

We can include shipment information, which could be the mode of disposal depending on how things are disposed of.

I agree with most of what @AJLinn is saying, but I am still concerned about deaccession objects being public. What if it transfers to another museum, and that museum has their data online and then there are duplicate records online?

[lin-fred]

That's definitely only one use case. The rotten heart sample is tossed, ideally with paperwork, the skull and skin is kept.

I don't consider that to be a deaccession, and so it is just the tissue going on loans until it is used up. BUT I am also not sure on that as most of my references don't give examples for biological collections that get physically used.

[dustymc]

how are they different

One deals with parts and the other with whatever comes through the door.

@AJLinn if there's something in your list which loans do not do, please let me know.

The one thing missing from your list is "do something arbitrary, because these are the same things with different names, and then never find anything because it's not where it's expected to be."

don't consider

Exactly....

[AJLinn]

@AJLinn if there's something in your list which loans do not do, please let me know.

Nothing I can think of... in fact, I was visualizing the loan input screen as I imagined these various elements. I just wish we could call Loans something else?

[AJLinn]

What if it transfers to another museum, and that museum has their data online and then there are duplicate records online?

I'd actually see that as an advantageous situation where you are publicly documenting the provenance. The record clearly shows that it's been deaccessioned and you could add their new number as an alternate ID. I think that's a point on the "pro" list.

[dustymc]

wish we could call Loans something else?

That I can agree with. (I'd have suggested "usage" but I don't think deaccessions fall under that.)

the loan input screen

That's the more practical side of the same situation - there are a LOT of "loan screens," and a lot more loan-stuff that doesn't quite count as a "screen." Loans are deeply integrated into all sorts of "nodes." Replicating all of that for some subset of whatever we call loans would be a sustainability issue. (It would just be a cost worth paying if this is truly something different in some way I haven't yet recognized, which would presumably require new structure, new UI, new interactions - because it's different!)

provenance

Yep! I don't see not having the item as any reason to treat the data any differently. You had the thing, made it public, maybe loaned it out and that got published (or someone snarfed up your data and published on that), all of that history could be very useful for any number of reasons and Arctos can very easily accommodate.

[lin-fred]

What if it transfers to another museum, and that museum has their data online and then there are duplicate records online?

I'd actually see that as an advantageous situation where you are publicly documenting the provenance. The record clearly shows that it's been deaccessioned and you could add their new number as an alternate ID. I think that's a point on the "pro" list.

Yep! I don't see not having the item as any reason to treat the data any differently. You had the thing, made it public, maybe loaned it out and that got published (or someone snarfed up your data and published on that), all of that history could be very useful for any number of reasons and Arctos can very easily accommodate.

One would think, but I have been very forcefully told otherwise

[Nicole-Ridgwell-NMMNHS]

I agree that deaccessions shouldn't be categorized as a type of loan. I have a good example of the legal and ethical complications of doing so:

We collected a dinosaur skeleton (NMMNH:Paleo:25049), from Navajo land with permission of the tribe to be a repository for the specimen. It was cataloged into our collection and cited in many publications. A decade later, they reclaimed the specimen. It absolutely would not be right to document this as a loan, even a permanent loan back to the Navajo Nation. Legally, it always has been their specimen. We need to create a deaccession record for this specimen, and it needs to be something that is not categorized as a loan.

I'd prefer to create a new type of transaction as suggested by the original post, but maybe finding some way to rename loans would work as well.

[Jegelewicz]

One would think, but I have been very forcefully told otherwise

By people who don't understand how a museum is supposed to manage their collections LEGALLY.

[Jegelewicz]

Legally, it always has been their specimen.

Then should the museum ever have accessioned it?

[dustymc]

very forcefully told otherwise

It's easy enough to accommodate when necessary, it's just not an inherent part of getting rid of stuff.

not categorized as a loan

Transactions including loans are by default private; you can call it whatever you want it in any external correspondence-or-whatever.

Maybe a rename is as simple as revisting the terms in https://arctos.database.museum/info/ctDocumentation.cfm?table=ctloan_type with an eye towards using them for headers/titles - "data loan" and "returnable loan" and "whatever this thing is that we definitely don't call a loan" and .... could all look a lot like their own THINGS without too much UI work, I think.

I don't care much about the labeling most anywhere but I do care deeply about the functionality, that comes from data organization, and arbitrarily splitting some loan-like data off into some other structure is just about the most fundamental thing one should avoid in a system that can DO STUFF.

Whatever you call it, that situation is definitely within the scope of what the thing we now call loans has been used for. NPS claims we don't own anything from their land, there are probably lots more situations where museums are acting more like stewards than owners. (And lots of loan-things could be useful at this point - how was it returned, what's the tracking number, who packed it, what condition was it in when it was packed, etc.)

[Nicole-Ridgwell-NMMNHS]

Then should the museum ever have accessioned it?

Yes, it is a repository agreement. https://arctos.database.museum/info/ctDocumentation.cfm?table=ctaccn_type#repository_agreement

[Nicole-Ridgwell-NMMNHS]

Transactions including loans are by default private; you can call it whatever you want it in any external correspondence-or-whatever.

Except that we are part of state government and these records absolutely could be requested as part of a public information request.

[Nicole-Ridgwell-NMMNHS]

an eye towards using them for headers/titles

That seems like a good potential solution.

[AJLinn]

Transactions including loans are by default private; you can call it whatever you want it in any external correspondence-or-whatever.

Except that we are part of state government and these records absolutely could be requested as part of a public information request.

BUT the records that you would share if requested would be those things that clearly state the material was deaccessioned and returned to the tribe, and would not show a loan form.

[lin-fred]

We should not be renaming loans as something else. There are 3 main transactions

Accessions Deaccessions Loans

Everything falls under those 3, there is no reason to reinvent the wheel on vocabulary here.

There needs to be a separate deaccession form, just like the accession form. This is for both legal and ethical reasons.

I don't understand why splitting the old way that you all have "deaccessioned" stuff is considered bad? I'm going to say it again, if deaccessions are under loans, then accessions are under loans, and that's as simple as it is! Which I don't think that should be the case, as deaccessions are on the same level as accessions and should be treated as such.

[lin-fred]

Accessions/Deaccessions - legal rights are transferred

Loans - legal rights are not transferred

That's it. So if deaccessions needs to stay under loans, because supposedly its data is similar to loans, then accessions also needs to move under loans.

[acdoll]

There are 3 main transactions

Accessions Deaccessions Loans

Agreed. This is SOP for many collections and has been for decades - they are administrative concepts surrounding how we handle the objects and the legal and ethical responsibilities. Each has its own separate function and (IMHO) should be treated as such in our database. If you can keep them in the loan structure but have them display differently in the UI, that would be fine by me. What I would like to see is: 1) a clearly identified section on the specimen record page indicating the deaccession: 2) a deaccession page with the pertinent info and linked documents: and 3) a dedicated search option:

[AJLinn]

How do we link existing catalog records to this new Deaccession transaction without creating a new catalog record? There is a structure to doing that in the loans transaction but is that something that is functionally possible for this proposed Deaccession transaction? (I don't really understand that linking process).

I fundamentally agree with the concept of these actions both being transactions that through a completion of the process transfers title (assuming all steps are followed in the deaccession and disposal). I like the idea of linking to the deaccession record, like accession, project, and loan, but I don't much care how that shows up. I like the number format indicating a transaction that is clearly a deaccession. And of course, being able to easily and clearly search for deaccessions.

[ewommack]

There is a current NHCOLL thread where it was asked what you call it when an object has been destroyed, that has info that might be useful for this issue. For reference here are the sources and info coming through:

This is a very good guide to museum standards and is followed by many museums. The specific advice on disposal processes and how to document them is specified here: https://collectionstrust.org.uk/spectrum/procedures/deaccessioning-and-disposal-spectrum-5-0/

Nigel

Mr Nigel T. Monaghan

Keeper – Natural History Division

National Museum of Ireland – Natural History, Merrion St. Dublin 2, Ireland. D02 F627

Andy Bentley provided the following:

Yes, deaccessioning is the term you are looking for – which is the opposite of accessioning – the legal process of accepting material into your collection which is different from cataloging. The catalog record will remain in the collection for future reference but it will be indicated as having been deaccessioned. Although collections typically keep most of the material they accession, there are a few scenarios under which items may be deaccessioned:

• Gift to another institution
• Exchange with another institution
• Specimen lost (neglect, shipping issues, etc.)
• Specimen destroyed (destructive sampling, used up in the course of research, etc.)

There is a good explanation of these in Museum Registration Methods 6th edition (Chapter 3I) (https://rowman.com/ISBN/9781538113110/Museum-Registration-Methods-Sixth-Edition) and Things Great and Small (Chapter 7) (https://rowman.com/ISBN/9781442277458/Things-Great-and-Small-Collections-Management-Policies-Second-Edition) which I highly recommend you purchase as references. I will send you PDF’s of these chapters offline

[Jegelewicz]

Deaccession SHOULD be a transaction so that an institution can track the LEGAL process of removing an object from it's collection.

From AAM

The practice of deaccessioning an object is the act of formally removing that object from the museum’s permanent collection. Once an object is deaccessioned it can then be disposed of by various means. The Alliance has compiled this set of deaccessioning and disposal resources from amongst its own offerings as well as those throughout the nonprofit and museum sector.

A deaccession IS NOT a loan: "Once an object is deaccessioned it can then be disposed of by various means." indicates to me that there is a transaction to record the deaccession, then a loan could be used to record the disposition of the deaccessioned object.

See also National Park Service on Deaccession The Association of Art Museum Directors Policy on Deaccessioning

This should be separate from Accession (a deaccessioned object should retain a link to its original accession). My opinion is that we need a new transaction type = deaccession. It should hold basically the same information as an accession but not be REQUIRED for any given catalog record.

Bringing this to the AWG Issues Meeting.

[dustymc]

same information as an accession

That would stop any possibility of deaccessioning part of a cataloged item, which doesn't seem adequate. It certainly conflicts with "object" above.

not be REQUIRED

Obviously we can't require everything to be deaccessioned, which also means we can't reuse the structure of accessions.

My preference remains https://github.com/ArctosDB/arctos/issues/4189#issuecomment-995268227: data-driven forms which treat arbitrary collection-object-related (the table, it's not only "objects") transaction types as their own THING without requiring structural changes. I think that addresses everything mentioned here, and also makes creating some transaction type that we've never heard of (maybe for our next new type of collection) a matter of code table values instead of structure and code.

[Jegelewicz]

AWG - @AJLinn says it should be built upon the loan model BUT needs to be called "Deaccession" so that it is clear on the catalog record that there is a deaccssion and NOT a loan.

So instead of loans with loan types, we would have transaction types, many of which are currently loan types.