Resource types list questions

[monotasker]

The current draft list of item types is here (credit but not blame for current version to Bonnie!): https://docs.google.com/spreadsheets/d/1ie6erivVoTmh2CJ2FDQNv_7qiZt_sfAlwSiGTVcNE6A/edit#gid=1816741904

There are a few questions worth hashing out around these. In no particular order:

• Some types need to be added to handle CORE deposits
  • publication:abstract
  • publication:review
  • publication:editorial
  • publication:fictionalWork
  • publication:legalComment
  • publication:legalResponse
  • publication:poeticWork
  • presentation:lectureText
  • other:catalog
  • audioVisual:videoRecording
  • audioVisual:documentary
  • audioVisual:musicalRecording
  • presentation:lectureRecording
  • publication:whitePaper (or would this be covered by "report"?)
• Should we change the "publication" section to something like "textDocument"?
  1. Publication is becoming an ambiguous concept. Is a document distributed only as a CORE upload "published"? Is a blog post "published"? A "preprint"? A "report"?
  2. The other sections are mostly divided by basic medium (image, presentation, software, audiovisual) so it would make sense to use the medium here too (text document)
  3. Some of the items may be published or unpublished without changing their basic type: "bibliography", "standard", "datapaper," etc.
• Should types be unambiguous about whether they're entire works or sections of works?
  • I'm running into problems with "interviewTranscript", "translation", "fictionalWork"
  • by podcast, do we mean the podcast as a whole or a podcast episode?
• there are some other types that I think could use more clarity
  • distinguish interviewTranscript (textDocument) from interviewRecording (audioVisual)
  • distinguish video recording of conference presentation (presentationRecording) from text of the presentation (presentationText)
  • I'm not sure what we mean by conferenceProceeding and how its different than conferencePaper
  • CORE has some deposits with the "essay" type. Should we add this? Or is that equivalent to either bookSection or journalArticle?
• There's only one item in the "poster" category. Should we treat a conference poster as a kind of presentation?
• Do we need both bookChapter and bookSection?
  • could we just have bookSection and let people use it for chapters too (like Zotero does)

Tagging @bjr70 , @stephanievaskomsu , @babaklar , @mikethicke

[monotasker]

Here's a draft of a modified list. (I didn't want to rework Bonnie's too much before we discussed.)

audiovisual*
    documentary*
    interviewRecording*
    musicalRecording*
    other*
    performance*
    podcastEpisode*
    soundRecording
    videoRecording*
dataset*
image*
    chart*
    diagram*
    figure*
    map*
    other*
    visualArt*
instructionalResource*
    curriculum*
    other*
    syllabus*
presentation*
    conferencePaper*
    conferencePoster*
    other*
    presentationText*
    slides*
software*
    3DModel*
    application*
    computationalModel*
    computationalNotebook*
    outputManagementPlan*
    other*
    service*
textDocument*
    abstract*
    bibliography*
    blogPost*
    book*
    bookSection*
    conferenceProceeding*
    documentation*
    editorial*
    essay*
    fictionalWork*
    interviewTranscript*
    journalArticle*
    legalComment*
    legalResponse*
    other*
    magazineArticle*
    monograph*
    newspaperArticle*
    onlinePublication*
    poeticWork*
    report*
    review*
    standard*
    thesis or dissertation*
    whitePaper*
other*
    catalog*
    collection* (annotation collection in Invenio?)
    event*
    interactiveResource*
    notes
    other*
    peerReview*
    physicalObject*
    workflow*

This leaves out some of Invenio's types which we so far have decided not to keep:

• data management plan
• patent
• preprint
• deliverable
• milestone
• proposal
• taxonomic treatment
• technical note
• working paper

[mikethicke]

Should each top-level category, including other, have an 'other' sub-category?

[monotasker]

Yeah. I haven't added them in all of the subcategories here, but that was the plan. I should edit it now.

[bjr70]

Ian I was going to try to map some of those existing CORE types into the types we selected. The legal stuff we probably have to carry over. I was thinking we might want to add fiction, only because we have a good number of fiction deposits. I'd love to hear other thoughts on that one.

I'm happy with changing publication to textDocument. That makes sense.

Should types be unambiguous about whether they're entire works or sections of works? I'm running into problems with "interviewTranscript", "translation", "fictionalWork". By podcast, do we mean the podcast as a whole or a podcast episode?

I don't know that we need to worry about that. Translation in our repository is generally either a translated book, poem, or article. I haven't seen a whole lot of sections. Podcast has always referred to as an episode in the current repository.

there are some other types that I think could use more clarity

• distinguish interviewTranscript (textDocument) from interviewRecording (audioVisual)
• distinguish video recording of conference presentation (presentationRecording) from text of the presentation (presentationText)
• I'm not sure what we mean by conferenceProceeding and how its different than conferencePaper
• CORE has some deposits with the "essay" type. Should we add this? Or is that equivalent to either bookSection or journalArticle?

I hesitate to get too granular for fear of making the list too unwieldy, how specific should we be? Essay should probably be included and is not necessarily equivalent to either of those. Many times essays can stand alone.

There's only one item in the "poster" category. Should we treat a conference poster as a kind of presentation?

That makes all sorts of sense to me and I like it. Other thoughts?

Do we need both bookChapter and bookSection? could we just have bookSection and let people use it for chapters too (like Zotero does)

I like just having bookSection. Having both feels redundant.

I disagree on "other." I'd prefer not to have a ton of "other" and just have folks use the top level category. Other does not help in search or in indexing. No one is likely to search for items listed as "other."

[monotasker]

Point taken. I wonder if we need a translation type at all? If a deposit is a book and has a translator listed, wouldn't they mention that in the abstract/description?

Yeah, good point! Maybe translation is one we can drop entirely.

[stephanievaskomsu]

Coming in to comment on a few things:

1. ConferenceProceedings are a type of pub (usually a collection of the abstracts and or papers from a conference), not every conference runs them like that, but IEEE for example does, so we should keep that one.
2. I'm fine with text instead of pub, as not everything is published
3. On the transcripts vs audiovisual q: do we not have oral histories as a separate thing? I err on the side of having options for both in case the physical recording is no longer viable (damaged tape, etc)
4. For a translated book/article, wouldn't translator/translated language be fields?

[bjr70]

Good point on translated language. I wonder if we allow users to add more than one language. There are cases where books are published in two languages. A good example would be this book, which is in both Anishinaabemowin and English.

Also thinking that oral histories would be a good type. I can see people searching for something like that.

[monotasker]

Thanks for weighing in @stephanievaskomsu. Would conferenceProceedings then be used for the whole volume, and individual papers inside would be bookSection?

Oral histories is an interesting suggestion. Are you thinking of that as a kind of audio recording? A kind of text document?

Invenio allows for multiple languages on a deposit. So we can definitely allow for that. With "translator" we hit the question again of how much to break things down for the user. Do we just provide "translator" as a role option under "creators" or do we provide separate fields for roles like "author" and "translator" that will be common for the given resource type?

[bjr70]

We should have both author and translator. The original author will be credited as author, with the translator being listed as translator. We should probably have that on all text resource types. Maybe also on audio/video?

[monotasker]

A couple of other questions here about types that are in Invenio by default:

• "preprint": Should we be keeping this? My vote is "no" because it's not really a resource type. The type is either a book, chapter, article, etc. "Preprint" is just the publication status. So this type muddies the metadata.
• "patent": Should we include this? If so I'd think under "other"?

[bjr70]

Hmmm, I want to reach out to some other librarians on this one. Preprint and patent may be useful for the STEM community as types. I'll reach out to some folks and get back to you.

[monotasker]

A few other questions about resource types that have come up as I'm working:

textDocument:fictionalWork

This could encompass books, short stories in books, short stories in journals, etc. That presents some challenges for things like the upload form. Do we keep this as a type, or do we instead have a custom field recording whether an item (book, chapter, etc.) is "fictional"?

textDocument:workingPaper

We had dropped this one from Invenio's default list, but it seems to be a pretty standard type in STEM. So I'd suggest we reintroduce it.

textDocument:conferenceProceeding

I'm still fuzzy on what this is supposed to be. Is it a collected volume of conference papers as a whole? Or is it one paper contained in a volume like that? Do we really want to distinguish a conference paper in a collected volume from other "bookSection" items? The problem I can see is that a lot of volumes these days are books that originate from conferences. I don't know how often you have just a routine publishing of all of a conference's papers every year (like you used to).

[stephanievaskomsu]

That first question about fictional works makes me wonder if fiction/nonfiction is a label that you can toggle on for all the examples you mentioned? So instead of being a separate type it is a flavor of a type?

…

________________________________ From: Ian W. Scott ***@***.***> Sent: Wednesday, May 24, 2023 4:13 PM To: MESH-Research/knowledge-commons-repository ***@***.***> Cc: Vasko, Stephanie ***@***.***>; Mention ***@***.***> Subject: Re: [MESH-Research/knowledge-commons-repository] Resource types list questions (Discussion #90) A few other questions about resource types that have come up as I'm working: textDocument:fictionalWork This could encompass books, short stories in books, short stories in journals, etc. That presents some challenges for things like the upload form. Do we keep this as a type, or do we instead have a custom field recording whether an item (book, chapter, etc.) is "fictional"? textDocument:workingPaper We had dropped this one from Invenio's default list, but it seems to be a pretty standard type in STEM. So I'd suggest we reintroduce it. textDocument:conferenceProceeding I'm still fuzzy on what this is supposed to be. Is it a collected volume of conference papers as a whole? Or is it one paper contained in a volume like that? Do we really want to distinguish a conference paper in a collected volume from other "bookSection" items? The problem I can see is that a lot of volumes these days are books that originate from conferences. I don't know how often you have just a routine publishing of all of a conference's papers every year (like you used to). — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/MESH-Research/knowledge-commons-repository/discussions/90*discussioncomment-5994109__;Iw!!HXCxUKc!yu-ZFL0C6hJyZsqpDulW0wJCilLKHbJBsIblzIbiNuv3-UiPNz8q6Kq8lrnb7IIpAmJya2GQf1-uhLdjQL9dcdz2$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AXOL4UM6E7W5IEFH3XU5YXLXHZTWHANCNFSM6AAAAAAYGS3NC4__;!!HXCxUKc!yu-ZFL0C6hJyZsqpDulW0wJCilLKHbJBsIblzIbiNuv3-UiPNz8q6Kq8lrnb7IIpAmJya2GQf1-uhLdjQDdowAsF$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[monotasker]

That's actually what Bonnie and I were thinking when we talked this afternoon. Great minds!

[bjr70]

Yeah my suggestion was a question "Is this a work of fiction?" or something to that effect with a yes/no radio button. If there were no answer we'd default it to no.

[monotasker]

I've just finished a beta (alpha?) version of the actual resource_types.yaml custom vocabulary file: https://github.com/MESH-Research/knowledge-commons-repository/blob/main/app_data/vocabularies/resource_types.yaml

[monotasker]

It includes not just our vocabulary terms, but also equivalent terms (or as close as possible) in a few other ontologies: coar, datacite, schema.org. Since Invenio's existing types included German translations for all of the terms, I added German translations for our additions too.

[bjr70]

This looks great, Ian. That's interesting that there were German translations but no others. I'd have expected French, Spanish, maybe Chinese too. Not saying we should, just surprised.

[monotasker]

Yeah, I think we should add them when we look at translations generally. I think German was probably included because some of the Invenio dev was done in Germany. And I just happen to know some German! If we're doing translations, I agree that Spanish and Mandarin come to mind as the next logical ones to look at.

[kfitz]

I wanted to pop in and ping @schopie1 on this discussion -- Scott mentioned wanting to add a tipsheet to his ORCID profile recently and having to call it "other" because there was nothing else appropriate. He may have some additional suggestions for item types that might be most relevant for instructional technologists and other folks working off the tenure track.

[monotasker]

I've configured a working version of the resource types vocabulary here:
https://github.com/MESH-Research/knowledge-commons-repository/blob/main/app_data/vocabularies/resource_types.yaml

It's still open to revision, obviously, but this file is always the current version in the development repo