Code Table Request - new part disposition: restricted usage

[falco-rk]

Initial Request

Goal

Describe what you're trying to accomplish. This is the only necessary step to start this process. The Committee is available to assist with all other steps. Please clearly indicate any uncertainty or desired guidance if you proceed beyond this step.

Create new part disposition for objects that are held in our collection but cannot be loaned out.

Context

Describe why this new value is necessary and existing values are not.

OGL holds a lot of DNA and tissue samples that we cannot loan out. I want to have those objects included in object tracking but not be able to be added to a loan/found by people looking for loanable samples. The data about these samples can be distributed to aggregators (ggbn, etc).

Table

Code Tables are http://arctos.database.museum/info/ctDocumentation.cfm. Link to the specific table or value. This may involve multiple tables and will control datatype for Attributes. OtherID requests require BaseURL (and example) or explanation. Please ask for assistance if unsure.

https://arctos.database.museum/info/ctDocumentation.cfm?table=ctdisposition

Proposed Value

Proposed new value. This should be clear and compatible with similar values in the relevant table and across Arctos.

~~unloanable~~

restricted usage

Proposed Definition

Clear, complete, non-collection-type-specific functional definition of the value. Avoid discipline-specific terminology if possible, include parenthetically if unavoidable.

~~the object is in the collection, but is not available to be loaned~~

The object is in the collection, but there are restrictions on its use. These should be described in part remarks, condition report part attribute, or a curatorial encumbrance. This disposition will not prevent addition to a transaction, it is a curatorial flag.

Collection type

Some code tables contain collection-type-specific values. collection_cde may be found from https://arctos.database.museum/home.cfm

n/a

Attribute Extras

Attribute data type

If the request is for an attribute, what values will be allowed? free-text, categorical, or number+units depending upon the attribute (TBA)

n/a

Attribute controlled values

If the values are categorical (to be controlled by a code table), add a link to the appropriate code table. If a new table or set of values is needed, please elaborate.

n/a

Attribute units

if numerical values should be accompanied by units, provide a link to the appropriate units table. n/a

Part preservation attribute affect on "tissueness"

if a new part preservation is requested, please add the affect it would have on "tissueness": No Influence, Allows, or Denies

n/a

Priority

Please describe the urgency and/or choose a priority-label to the right. You should expect a response within two working days, and may utilize Arctos Contacts if you feel response is lacking.

Example Data

Requests with clarifying sample data are generally much easier to understand and prioritize. Please attach or link to any representative data, in any form or format, which might help clarify the request.

Available for Public View

Most data are by default publicly available. Describe any necessary access restrictions.

Helpful Actions

• [x] Add the issue to the Code Table Management Project.

• [x] Please reach out to anyone who might be affected by this change. Leave a comment or add this to the Committee agenda if you believe more focused conversation is necessary.

@ArctosDB/arctos-code-table-administrators @Jegelewicz @campmlc

Approval

All of the following must be checked before this may proceed.

The How-To Document should be followed. Pay particular attention to terminology (with emphasis on consistency) and documentation (with emphasis on functionality). No person should act in multiple roles; the submitter cannot also serve as a Code Table Administrator, for example.

• [x] Code Table Administrator[1] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
• [x] Code Table Administrator[2] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
• [x] DBA - The request is functionally acceptable. The term is not a functional duplicate, and is compatible with existing data and code.
• [x] DBA - Appropriate code or handlers are in place as necessary. (ID_References, Media Relationships, Encumbrances, etc. require particular attention)

Rejection

If you believe this request should not proceed, explain why here. Suggest any changes that would make the change acceptable, alternate (usually existing) paths to the same goals, etc.

1. Can a suitable solution be found here? If not, proceed to (2)
2. Can a suitable solution be found by Code Table Committee discussion? If not, proceed to (3)
3. Take the discussion to a monthly Arctos Working Group meeting for final resolution.

Implementation

Once all of the Approval Checklist is appropriately checked and there are no Rejection comments, or in special circumstances by decree of the Arctos Working Group, the change may be made.

• [x] Review everything one last time. Ensure the How-To has been followed. Ensure all checks have been made by appropriate personnel.

• [x] Add or revise the code table term/definition as described above. Ensure the URL of this Issue is included in the definition. URLs should be included as text, separated by spaced pipes. Do not include HTML in definitions.

Close this Issue.

DO NOT modify Arctos Authorities in any way before all points in this Issue have been fully addressed; data loss may result.

Special Exemptions

In very specific cases and by prior approval of The Committee, the approval process may be skipped, and implementation requirements may be slightly altered. Please note here if you are proceeding under one of these use cases.

1. Adding an existing term to additional collection types may proceed immediately and without discussion, but doing so may also subject users to future cleanup efforts. If time allows, please review the term and definition as part of this step.
2. The Committee may grant special access on particular tables to particular users. This should be exercised with great caution only after several smooth test cases, and generally limited to "taxonomy-like" data such as International Commission on Stratigraphy terminology.

[Jegelewicz]

Perhaps this could cover the parts that @campmlc is using the restrict usage encumbrance for? This would also make it easier to spot them during loan prep?

[campmlc]

I was thinking the reverse - that we could expand encumbrances for this. But this might work better. Perhaps instead of "unloanable", we have "restricted usage", which ideally would tie in with an encumbrance providing additional documentation? We really need a catagory of encumbrances that doesn't expire every five years.

[falco-rk]

I'm fine with restricted usage

[dustymc]

ine with restricted usage

Good, because that's the correct answer (and why that exists).

This won't get at "unloanable because lost" or "actually loanable, but only with special approval by 4 separate entities" and all sorts of other stuff that encumbrances does just fine.

[campmlc]

So I'm confused - do we now have "restricted usage" as a dispositon? Or was the answer @dustymc gave indicating that we should just use encumbrances?

[falco-rk]

I am also confused. I meant that I was fine will calling the disposition "restricted use"

[campmlc]

I agree with that as well. Encumbrances should additionally be used to provide more information, but they aren't publicly visible and aren't easy to see even curatorially during loan processing. Using disposition = restricted usage provides an obvious flag to curators and public alike, and it is at the part level, which is even better than using an encumbrance on the record because not all parts may be subject to the restriction.

[dustymc]

Guess I'm the lost one!

https://arctos.database.museum/info/ctDocumentation.cfm?table=ctencumbrance_action#restrict_usage is the solution to the stated problem.

[Jegelewicz]

The answer is that we remove restricted usage encumbrance and use this instead.

[dustymc]

use this instead

Tell me how that does this?

[Jegelewicz]

@dustymc we are not asking for anything programmatic, just a code table term that indicates to humans that the part should not be loaned without some review.

[campmlc]

Actually, I do not want to remove the restricted usage encumbrance - that is necessary and provides much more control and metadata than just changing the disposition term. But I agree with @falco-rk that we need to be able to indicate at the part level whether a part is available for loan using disposition. Currently, if we say a part is "used up" then it greys out on the interface and it shows up on the loan item tools as "used up" - so we know it isn't available for loan. See below. We are just asking for the term "restrict usage" to be added to disposition to do the same thing - and to point curatorial staff to the existence of encumbrances for more info if necessary.

[Jegelewicz]

I do not understand how a code table term that is doing NOTHING is technically problematic.

[Jegelewicz]

@falco-rk wants is a disposition that keeps them from loaning parts that are under some form of loan embargo. The restrict usage encumbrance doesn't DO anything as far as I can tell and is less useful because it applies to an entire record - not a specific part. @campmlc can have that for whatever it is doing for her, but I don't see how it would accomplish @falco-rk goal.

[campmlc]

@falco-rk wants is a disposition that keeps them from loaning parts that are under some form of loan embargo. The restrict usage encumbrance doesn't DO anything as far as I can tell and is less useful because it applies to an entire record - not a specific part. @campmlc can have that for whatever it is doing for her, but I don't see how it would accomplish @falco-rk goal.

Just to be clear - I totally support the disposition request for exactly the same reasons, and cannot see how it is technically problematic.

[dustymc]

https://github.com/ArctosDB/arctos/issues/2667

I don't think "you can't have it (probably, and we can't say why if we wanted to)" says anything about disposition; it's problematic because it's something other than this. I think adding this would basically be a trap; someone will use it, not document it (because they can't, the structure isn't there), and we'll have another impossible cleanup to struggle with after everyone's forgotten why they did that.

Or maybe I just have strange ideas about what disposition is, which probably would have been good to flesh out before we started the still-stuck cleanup project...

available for loan

The aforementioned encumbrance is meant to do that; it should be on all the loan UIs. (But I think it's not...)

applies to an entire record - not a specific part

That's a real concern. I think we're also inundated by part attributes so I'm hesitant to suggest such things, but they (unlike disposition) can carry a bit of metadata and aren't stuck in a 1:1 relationship, so maybe that's a better/necessary approach?

[campmlc]

I think we are way overthinking this. Disposition is really a tool for collection management. It carries no real info, no metadata, no date - it merely acts a flag. A large number of my tissues are "being processed" because we don't have the resources or workflows to change them over to "in collection" except sporadically. And yet that doesn't break anything. Using disposition to flag parts that are perhaps in collection but not available for loan is a very simple easy solution to a complex problem using the simplest of possible tools. Setting up an encumbrance is more rigorous, more complex, more confusing, more opaque, and not visible from a large number of tool interfaces. Is it important in some cases? Yes! But does it solve this problem? No. If there is some minimal harm that could result from adding "restricted usage" to the disposition code table, it pales in comparison to the current difficulties involved in dealing with encumbrances.
The parts concern is real. This solves it for now. Eventually we should probably have disposition be a part attribute. But for now, this isn't any less evil than the current "condition" field, and it is certainly far more useful.

[Jegelewicz]

Happy to change this to a part attribute if it can render the part it is associated with impossible to place into a loan.

[jldunnum]

Support addition of "restricted usage" in Disposition, provides greater flexability when managing at part level, allows for easy modification when needed, don't want it to be impossible to loan either, just requiring more focused effort and an understanding as to the restrictions

[campmlc]

Is the requirement is that it be excluded from loan selection or just an obvious flag? For example, when I am searching for loan items, I have to manually exclude any used up or transfer of custody or on loan dispositions.We also have the option of including or excluding subsamples when we bulkload loan items. I assumed that this disposition would be similar. If they absolutely must not be loaned, we need this but we also need to do something better with encumbrances too, which is needed but will require a focused committee to overhaul.

[Jegelewicz]

AWG today

Add this disposition to the code table. It will not DO anything. It is simply a curatorial flag indicating restrictions on individual parts. It may or may not be used in conjunction with an encumbrance.

[falco-rk]

Does anyone else have comments about this? Can we move forward with adding it to the code table?

[campmlc]

I support this. @Jegelewicz is on vacation this week - can it be added when she gets back?

[Jegelewicz]

There is DBA objection - sending to AWG

[campmlc]

Can we get a summary of the objection? I'm having trouble sorting out from the issue.

[Jegelewicz]

According to the handbook:

Disposition describes the status of parts and, as an abstract generality, the status of cataloged items. Typical values are controlled by a code table

This seems to fit right in that definition as an abstract status.

[dustymc]

abstract status.

That's super old, back when cataloged items (as collection objects) were structurally required to carry disposition. In any case, defining disposition such that it encompasses this does address my concerns, and I don't think we need to get lost in the way things were. Disposition in my mind has been "the way in which something is placed or arranged, especially in relation to other things." That's clearly not sufficient, and "random things from a code table" probably isn't what anyone's looking for, so - help!

Someone please propose an updated definition of 'disposition.'

[Jegelewicz]

Disposition describes the curatorial status of parts. Values are controlled by a code table

[Jegelewicz]

My attempt to add this to the code table failed:

@dustymc

[dustymc]

attempt

I flailed around with my magic wand.

Your definition above is linking to the wrong code table.