Arctos: New code table values "shows catalog" and "shows field notes"?

[ebraker]

I would like to create two new media_relationship code table values, "shows catalog" and "shows field notes" as a way to make these media types more searchable. Unlike current documentation-related media relationships, these new values would ultimately link to individual or multiple specimen records rather than a transaction (e.g., "shows cataloged item" functionality).

Our library has scanned over 60 volumes of museum catalogs and field notes, and we will link Arctos records to these external resources in the near future. I am fine with using "shows cataloged item" if that is the preferred route, as I know that some institutions have already applied this value to field notes or collector catalogs. However, presumably we will be linking every single UCM record to a corresponding catalog page, and it would be nice to pull out this media type so that it is not only searchable, but also so so that it does not appear as if every single one of our records has an associated image of the physical specimen (as "shows cataloged item" implies).

Being able to specifically flag media as field notes would also improve finding (I see the "select Field Notes" hypertext on the Media Search page, but I am unsure as to how media are currently tagged as field notes).

Table
http://arctos.database.museum/info/ctDocumentation.cfm?table=CTMEDIA_RELATIONSHIP

Value: Definition
shows catalog: media relating to catalogs or ledgers
shows field notes: media relating to field notes

[dustymc]

Media relations are functional - they must end with a space and then a table name. So "whatever bla bla something else cataloged_item" works, but not "....{space}{not a table}."

Media relationships are key-pairs that originate with a Media object and refer to the table in the relationship. That is, they're media-->object, not object-->media.

"shows cataloged_item" does not go through transactions - its a link from Media to catalog records.

"this is [field notes, a ledger, etc.]" could be a media label.

TAGs work for linking a specific THING (eg, catalog record) to a place in a multi-page document. I suspect that's going to be the best tool for this. http://arctos.database.museum/document/rausch-necropsy-card-file-194249-other-avian-orders/34#1422 is an example of a TAGged multi-page document.

We may need a "documents cataloged_item" (or something of the sort) rather than 'shows,' but that also seems like a good way to introduce a bunch of arbitrary data in the gray area between 'shows' and 'documents' (and it may ALL be gray!).

[Jegelewicz]

The "shows" implies a relationship to a record/agent/project etc. (aka a link to something else in Arctos).

I suggest these terms be entered as "description", however, this also relates to "keywords" and it would be nice to have a controlled vocabulary to facilitate discovery. See #2362

[ebraker]

I like "documents cataloged_item". OR, I am fine with using the current "shows cataloged_item" with a secondary controlled vocabulary table as Teresa suggests. However, I think we should leave "description" as is, since it is a free text field that I'm sure many collection types use differently and likely contains rich info for cultural collections. Perhaps an optional "category" field? (e.g., field notes, catalog, cataloged item, micro slides, condition photo etc.)? That would help facilitate discovery.

The problem with the tags is that I will be creating links to an external resource, so I cannot use them. Even for some of the individual field note pages, I will be loading pdfs and not jpegs so they are a no-go unfortunately.

[dustymc]

We've never attempted controlled-vocabulary media labels, so that would be Major Surgery. I don't think it would be particularly difficult, but it certainly can't happen until I have a development environment.

creating links to an external resource

You can't do that with relationships either (at least not directly); relationships establish primary->foreign key - well, relationships!

An example would be useful.

Things like https://smallpdf.com/pdf-to-jpg exist (just a google search result, it could be malware for all I know!), and at least in theory I could create JPGs from PDF serverside. The format of the images (if that's what's in the PDF) doesn't necessarily have to block access to tools.

[Jegelewicz]

I will be loading pdfs and not jpegs so they are a no-go unfortunately.)

It's actually pretty easy to convert PDF to JPG using Adobe Pro if you have it. For Art Harris' field catalogs, I uploaded both and tagged the JPGs. See https://arctos.database.museum/project/10002900

[ebraker]

The vast majority of media will be links (approaching 100K) to a library server rather than uploaded Arctos media. These aren't live yet (migrating to a different server with stable links currently) so my example is taken from MCZbase: https://iiif.lib.harvard.edu/manifests/view/ids:11466694

MCZ has essentially linked every ledger page URL as a media relationship "ledger entry for cataloged_item" so that each page is linked to ~40 specimens represented on the page. I believe the original impetus to create a separate media relationship at MCZ was to prevent every single record linked to a ledger page from returning in search results when someone queried records with "images" (ledger entries are not flagged as images).

I believe the library has the original JPGs for field notes so I can likely access those to upload directly to Arctos so I can tag them rather than link out to the hosted field notes. Either way, it would be nice to have a separate "field notes" media_relationship or controlled vocab for quick finding.

[Jegelewicz]

It seems like adding a description of "UCM Field Notes" would do that?

[dustymc]

"ledger entry for cataloged_item"

My concern there is just the definition - come up with something that prevents multiple ".... cataloged_item" terms being used for the same purpose, I'm happy.

queried records with "images"

That should come from http://arctos.database.museum/info/ctDocumentation.cfm?table=CTMEDIA_TYPE, which exists to deal with things like images of text or html-wrapped images (or I suppose ASCII art of your dead rats....). How that's handled by the UI is always up for debate, but a 'find images, not text including images of text' option about anywhere is very possible.

rather than link out

No (technical) reason to choose, you could do something like...

• web-quality JPGs (that you can TAG)
  
  
  
  • derived from media-->your library's server (especially if if has cool zoom or whatever)
    
    
    
    
    
    • derived from media-->whatever came out of the sensor
    
    
    
  
  

upload directly to Arctos so I can tag

That's not necessary, BUT you'd be putting a lot of trust in the host if you TAGged remote files. I'd probably load them too.

[ebraker]

Ok thanks to you both for thinking this through. Can we go with "documents cataloged_item"? Seems like a good catch-all. I will include in my media descriptions some version of "field notes" or "ledger" so that should we decide to add a controlled vocabulary media category down the road, all applicable records would be easy to identify.

[dustymc]

documents cataloged_item

No objections from me, pending definitions that separates it from http://arctos.database.museum/info/ctDocumentation.cfm?table=CTMEDIA_RELATIONSHIP&field=shows%20cataloged_item

[ebraker]

documents cataloged_item = media relating to non-transactional documentation of a cataloged item (e.g., field notes, collector or prep catalogs, condition reports, museum ledgers)

[Jegelewicz]

Not sure I like that - why "non-transactional"? Aren't prep catalogs, field notes and condition reports all a kind of transaction documentation?

Also, I feel like I am missing something the more I look at this. Do you expect that even though you enter the catalog number of the "documented" record, the media won't show up on the record itself? I guess I am not 100% clear on your objective anymore - sorry!

[ebraker]

I mean transaction in the Arctos sense (accession, loan, permit, borrow). I specify this since there are other media_relationships for "documents accn" "documents loan" etc. I think we want to keep this as a documentation catch-all, since you could load something like experiment notes to this category or a condition report, which are not transactional. I would also argue that a catalog or field notes do not fall under transaction documentation (more like primary source info or supplemental info) vs. something documenting a curatorial transaction like an accession register or loan file.

The media will show up on the record, as with any media.

I think I made things confusing by sharing MCZ's model, where a user can toggle a checkbox on the search page "require media?" and then checks off the type of media they want to query: image, CT scan, 3D model, text, video. Under that model, the scanned ledger pages are not flagged as images, as that would cause nearly every record to return as having an associated image, which is misleading since likely users are only searching for images of the physical specimen rather than documentation of the specimen.

All this is to say, a MEDIA_TYPE of "text" will do for my purposes.

[AJLinn]

documents cataloged_item = media relating to non-transactional documentation of a cataloged item (e.g., field notes, collector or prep catalogs, condition reports, museum ledgers)

I actually like this a lot. Full disclosure, I've been using "shows cataloged item" relationship when referencing media that describes the cultural context of objects (e.g., info provided by a maker or collector re: the specific use of the piece, or the context of its creation/collection, etc.). I think this is a much more useful and accurate relationship. It will be super useful for links to oral histories, interviews, etc. (audio media) that don't "show" anything but rather directly describe the cataloged item. (e.g., http://arctos.database.museum/guid/UAM:EH:UA87-005-0001 ). Perhaps specifically add "A/V recordings" as an additional example in the definition?

[dustymc]

"shows cataloged_item" is not transactional either - it establishes a media_relations-->cataloged_item relationship, same as the new value would. I think including that terminology in the definition is confusing.

CT scan, 3D model

If those are important to search on (and they probably are), they should be added to http://arctos.database.museum/info/ctDocumentation.cfm?table=CTMEDIA_TYPE and disambiguated from any existing values.

More filtering on media metadata should be pretty easy, but deserves a dedicated issue.

[krgomez]

I actually like this a lot. Full disclosure, I've been using "shows cataloged item" relationship when referencing media that describes the cultural context of objects (e.g., info provided by a maker or collector re: the specific use of the piece, or the context of its creation/collection, etc.). I think this is a much more useful and accurate relationship. It will be super useful for links to oral histories, interviews, etc. (audio media) that don't "show" anything but rather directly describe the cataloged item. (e.g., http://arctos.database.museum/guid/UAM:EH:UA87-005-0001 ). Perhaps specifically add "A/V recordings" as an additional example in the definition?

I've been following Angie's lead and doing this as well. Yesterday I uploaded some artist statements as PDFs using the "shows cataloged item" relationship and found that the text icons now mostly display first in search results, obscuring the image thumbnails, which is not ideal for us and made me think maybe a different relationship is needed (#2920). "Documents cataloged item" seems like a good relationship for text, A/V recordings, and images that document and give context but do not specifically show the item.

[dustymc]

I'm still fine with this, but...

• how's it not overlap with "shows cataloged_item" (eg, need better definitions), and
• I'm still confused by the "transaction" bits of this conversation

I don't think this would influence the sort or display.

[ebraker]

Resurrecting this thread. To summarize, I propose a new media_relationship, "documents_cataloged_item". This would be distinct from "shows cataloged item" since by current definition, the latter refers to "picture(s) of a specimen." "Documents_cataloged_item" would be a broader category and pertain to media documenting an item, but not depicting it, such as field notes, ledgers, tags/label images, etc. This would be helpful for searching, specifically, in isolating "pictures of stuff" from "pictures about stuff."

[dustymc]

I'm still not crazy about the definitions - I think there's still too much gray area - but whatever, nobody's objected to the idea, we can tune up the documentation any time. Done.

[ebraker]

Thanks! Maybe @ArctosDB/arctos-code-table-administrators can help iron out definition.