search

ArctosDB / arctos

Arctos is a museum collections management system
https://arctos.database.museum
60 stars 13 forks source link

Feature Request - curatorial attributes #7792

Open dustymc opened 4 months ago

dustymc commented 4 months ago

Is your feature request related to a problem? Please describe.

Encumbering attributes is expensive and complicated. https://github.com/ArctosDB/arctos/issues/3452 has lead to a more unified code table which carries a lot of information: https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type. Adding a 'curatorial' (='for us only') flag to certain types of attributes, rather than encumbering individual assertions in individual records, might be a simplification for everyone.

Describe what you're trying to accomplish

Simplify and save come CPU if possible.

Describe the solution you'd like

First, discussion:

Describe alternatives you've considered

Do what we're doing.

Additional context

https://github.com/ArctosDB/arctos/issues/3536#issuecomment-2088807250 https://github.com/ArctosDB/arctos/discussions/6742 https://github.com/ArctosDB/arctos/discussions/6179

Priority

Somewhat high; the new format attribute table is also a simplification for everyone. I think it's much easier to understand, and it is much easier/cheaper for me to use. I'd like to do it for other attributes, but not until there's some stability in that model.

ewommack commented 4 months ago

@AJLinn - this sounds like a great discussion for the Encumbrance committee!

mkoo commented 4 months ago

I like this approach as there are often need to have a 'private' attribute -- so this flag would be available for all record attributes or are you suggesting we have a new attribute that is always private? Either way could work-- the former would be better for several reasons and I see little negative repercussions.

dustymc commented 4 months ago

I was suggesting the types be flagged, similar to https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_attribute_type (where eg https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_attribute_type#correspondence is always 'us' and https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_attribute_type#cultural_affiliation is always public)

A flag on individual attributes could be discussed, but I think that's most of the cost of encumbrances. (I'd still have to filter individual records, but it is a couple joins 'closer.')

One major drawback to any form of this might be a lack of transparency. Encumbrances require a contact person and some elevated rights. This potentially does not have that: especially if individual attributes can be flagged, maybe there's something sensitive and precious behind that and maybe some student just checked the wrong box, how would anyone possibly know?

mkoo commented 4 months ago

ok this is mixing implementation with functional need a bit. Your suggestion is more like the second option where we have new attributes that are always private, which could work-- we can use the Determiner, date and remarks fields to note those encumbered metadata potentially.

The lack of transparency may be an issue since the public wont see that there's a private attribute or not, right? Let me see how the Issues meeting agenda shapes up for adding there or whenever the next encumbrance w.g. meeting is....

dustymc commented 4 months ago

mixing implementation with functional

Yes, starting the discussion off with functional requirements would always be lovely!

use the Determiner...

I don't think that'll work, the determiner (and other metadata) is still important whether the info is public or not. You've determined whatever sensitive thing using whatever method on suchnsuch date, that's all critical to understanding the data.

We should possibly have an 'enteredby' capture on attributes (I've been meaning to file that issue for months, someone else is very welcome to grab it and run...) which would get at me entering your determination (and possibly explain typos and such), but still doesn't really paint the whole picture.

With encumbrances, we can clearly say "CuratorX doesn't want these data public because whatever reasons." (And ideally we might share that with eg https://dwc.tdwg.org/terms/#dwc:informationWithheld so that eg a trusted researcher could know that we do have data and who to ask about it, but I don't think we do.) I'm not sure losing that ability for a few specific administrative attributes would be much different, but losing it for any arbitrary thing somehow seems like it probably leads to scary and regrettable places.

(We could require 'encumbered_by....' metadata on each attribute, but I think that's probably WAY over in 'unusable' territory.)

dustymc commented 3 months ago

Encumbrance committee likes the idea of flagging individual items, but would like to limit access - eg a student can update everything about an (attribute, part attribute, whatever) except the 'hide' checkbox, which requires (manage collection or whatever).

@dustymc to explore feasibility, CPU costs, complexity, temporarily going active development to do so.

dustymc commented 1 month ago

Flagging individual items would very effectively prevent "load-as-encumbered" which is (more or less) not great for https://github.com/ArctosDB/internal/issues/332.

I am not sure that the complexity of our current encumbrance model supports scalability. https://github.com/ArctosDB/internal/issues/332 (and various other similar issues) might need some level of "custom UI," that might well require/be best addressed by a "deep" API which deals with various public and private information. I suspect that simple ways of withholding information (eg "this is structurally public, this private" vs. "nearly everything may sometimes be private, depending on descriptive data and conditional information several joins away") is going to have outsized impacts on the reality of providing such tools/services. We should reconsider the weight of simplicity, whatever form this might ultimately take.