sciencehistory / scihist_digicoll

Science History Institute Digital Collections
Other
11 stars 0 forks source link

Add a "role" attribute to our Digital Collections content #996

Closed jrochkind closed 3 years ago

jrochkind commented 3 years ago

Right now, the data model of OH is based on PCDM, and we have a Work, which has "members" which can be Fkles (we call them Assets), or child works that have their own Assets.

The software doesn't "know" any role other than "it's a member, whose content type happens to be a JPG", or a PDF, or whatever.

That served us very well for our "traditional" photographic image based materials.

But with oral histories it breaks down a bit. The designs we have done for UX, we want to label something or put it on a page in a certain place because it's the PDF Transcript, or PDF Front Matter, or Portrait -- not just any old PDF that might happen to be in there.

So our current logic relies on a lot of assumptions -- eg IF there's not any PDF marked "by request" then you can assume that any PDF is full text. These are fragile and can easily break in confusing ways in the future, making a big mess for us.

Should we add a "role" attribute to our internal digital collections data model, so individual "members" can be marked from an internal controlled vocabulary of "roles", such as "full_text_transcript" etc.?

This would be sort of an enhancement of PCDM, it's still PCDM, but additionally "members" have a "role" which is not part of the PCDM model, if we were exporting to or integrating with some other system based on PCDM, it wouldn't know about the "role". That seems fine to me.

I think this probably makes sense. It wouldn't have to be used for our "traditional" materials, it could be optional. But we'd use it for OH and as a feature it would be available in the future for any future special purposes.

The main thing we'd have to figure out is at what point ingest staff assigns roles to members -- where we put this on what screen, in order to be most efficient for them, and hopefully not slow down their ingest too much, to have to chose the "role" for certain things.

MDiMeo commented 3 years ago

Yes, we should add "role" to our data model.

According to @HKativa it would be most helpful to assign on the following Page: -Under Members tab, there is a list of members associated with a work. On the righthand side, next to an individual item there is an "admin" link that offers "edit" as an option. It should be on this page. When the UI is ready for review, please ping @HKativa

jrochkind commented 3 years ago

@MDiMeo @HKativa ok! Not sure what you mean by the page -- are you saying on the edit page, or on the page that has the "edit" link that takes you to the edit page?

Feel free to use a URL to tell me, the URL of the page or a sample page, will be unambiguous.

HKativa commented 3 years ago

The edit page associated with an individual asset; here's a link to one example: https://digital.sciencehistory.org/admin/asset_files/m0c2yma/edit

jrochkind commented 3 years ago

Great, that's also the most straightforward place to add it.

@MDiMeo So, this is for giving roles to OH content -- I'm not sure if wht those roles should be is this ticket or a different one. Also, for existing content, we should probably auto-assign roles based on current logic for guessing them.

jrochkind commented 3 years ago

Per meeting, for now I will ONLY add a "Portrait" role, and then we will demo it, before adding possibly "front matter" and "transcript" role.