permits - use restrictions

[dustymc]

Help us understand your request (check below):

• other

Describe what you're trying to do

@mkoo wants to

1. Find records which do or do not have use restrictions
2. Download data which indicates such restrictions

Simple solution: add a use_restrictions BOOLEAN flag to table permit, which will always be public so it can be summarized in flat and filtered_flat. Note that we ARE NOT proposing to make any details public, that's expected to remain between the user and the collection, only 'has some use restriction' would be exposed.

Does that cover the identifiable use cases, or is there some need for more complexity? (The extreme in that direction might be permit_attributes, but I don't think I see anything like that need yet.)

My first thought was to add some value to https://arctos.database.museum/info/ctDocumentation.cfm?table=ctpermit_type, but after more discussion I think this is an addition to that, not one of those.

Related (possibly this issue will need expanded or accompanying will need filed, not sure how to shape that right now):

• permits are in my view 'any sort of permissive document' - an informal 'don't loan this' directive/stickynote from your Curator or a "I don't need a permit" statement from a contributor are well within bounds of the concept. @mkoo suspect the term "permit" leads curatorial users to the idea that permits are something more formal than that. Should we rename the node (to what?) in an attempt to get in front of that? Just update documentation?? (Seems clear to me, but I think I wrote it.)
• there's currently no 'permit statement' (not the right term, but I don't have a better) in the table, only remarks (and the ability to link Media). Do we need a new "field" (fields??) dedicated to 'what this thing does'? (If so we need a name for it/them!)
• There's a lot (like 100%...) overlap between my idea of permits (a fairly new structure, at least in this form) and restrict usage encumbrances (a concept which hasn't changed in a very long time). Scattering same-kind data around different places is about always evil, and there's some clear confusion about that particular encumbrance. Can we permit-ify and drop that term (which would help with some recent big-picture encumbrance-related struggles)?!

[campmlc]

Will this provide a flag on catalog items selected for transactions, particularly loans? That is where collections staff need to see usage restrictions. Harvard folks wrote a paper describing how they do this. Will post here.

[dustymc]

provide a flag

This should not be confounded with UI, except that scattering similar data across encumbrances, disposition, and permits will ensure that we cannot reliably find all of the like data and therefor cannot build good UI. If we can consolidate then this should be a big step towards being able to get those data in front of whoever needs to see them in whatever UI (and simplification in general), and if we can't then this should be killed as a further denormalization.

[happiah-madson]

While I see the appeal of

Simple solution: add a use_restrictions BOOLEAN flag to table permit

Here is my concern. We have a few typical types of results of permits/agreements/etc.

1. no restrictions (just the standard terms of our MTA).
2. attribution for material usage.
3. notification and attribution for material usage.
4. extremely complex restrictions (recipient needs to have a permit to use the materials/CITES or ESA is implicated/it's a marine mammal/etc. etc. etc.)

1, 2, and 3 are all different (they require us to put in different kinds of language into loan paperwork). And 4 is a nightmare. In the boolean solution, you would propose putting 2, 3, and 4 together, which results in almost the same amount of work as no boolean system because of the amount of follow up required to disambiguate 2 from 4. But grouping 1, 2, and 3 together means that it could be possible that terms are missed when putting together a loan.

Part of this is coming out of the struggle @falco-rk and I were having to figure out why bother putting permits into Arctos if there is not an easy way to see the consequences of them when working with our part exports.

[campmlc]

https://doi.org/10.14351/0831-4985-35.1.1

[dustymc]

@happiah-madson I think I'm working with second-hand information, if this isn't useful then we can kill it.

If anyone needs something more in permits (my 'maybe related...' is there because I'm not sure I'm not lost) please file another issue.

If anyone else needs to see whatever data in whatever UI, public or private, file an Issue for that.

If anyone isn't sure what they need, open a discussion.

---

different kinds of language into loan paperwork

Sounds like a job for...

not an easy way to see the consequences

File an issue! I can't build things I don't know you need.

[dustymc]

AWG discussed:

• NOT public
• YES new category field (not sure what to call it, values TBD, start near permits - use restrictions #8241 (comment))
  • use_condition
• ALSO new "summary" ?? field (maybe forced brief eg varchar(50)) for one-line description
  • use_condition_summary

(right??)

[dustymc]

AWG more discussion

• move restrict usage encumbrances to permits
• kill restrict usage disposition - file issues as necessary, some may need permits (and there's no data with the value so requires discussion with collection)

[dustymc]

Discussed with permit committee

• use_condition, use_condition_summary are satisfactory terms for new permit fields
• cardinality (zero or one per permit) is correct

@happiah-madson will file an issue regarding restrict usage encumbrances.

After #8305 is addressed this is ready for dev.