We know that we need some sort of “Resource Type” value in the Codex for the purposes of limiting and filtering.
Open questions from the 7/13 MM SIG discussion of the Codex:
What are the valid values for the Resource Type element?
Where do we get this data from?
If not from the content/media/carrier fields in MARC, what is the relationship of Resource Type to that data? Do we need to include each of those fields the Codex, as well?
As you’re thinking about this . . . you should be aware that RA SIG, working with Filip, has included resource type in the criteria for loan rules. We’ve actually been calling it material type, but the label isn’t important so much as that fact that in FOLIO this field will actually have function for circ policies. Something we’ve lacked in most existing systems.
I actually think there might be a distinction between Resource type (collected at the Instance level) and Material type (collected at the Item level).
I would think that in either case we’re really talking about format (book, serial, DVD, etc.). Shouldn’t the item just inherit that from the bib??
Not sure. This is something the Codex WG needs to figure out. I was imagining Resource type as a constrained list at the instance level which all the various source records would need to map to (most source records have data that represents Resource type (book, serial, DVD etc)). Material type, on the other hand, is item-level and has been discussed (and, in fact, implemented) as a fully configurable controlled vocabulary. I’d be curious how other systems handle this and what people like/dislike about the ways it’s done.
Alma, for example, has separate “Resource type” and “Bibliographic material type” at the instance level (see documentation here). Both of those are fixed lists. Then they have a configurable (though not fully customizable) “Physical item material type” at the item level. There doesn’t seem to be a link between the instance and item-level vocabularies.
Anyway, that’s just a data point. This is definitely an area for further discussion.
Hi, Andrea…
Just want to make sure that I understand:
You’re using the resource type from the bib record – rather than a
circulation-specific “item type” – to govern loan policies? How does
that work for a reference book vs. a book shelved in the main
collection, both of which would be “books” based on the bib?
Thanks!
Kathryn
One thing that’s always driven me crazy in our current ILS is that we have a single fixed field to represent “Resource Type.” This means that resources that could be legitimately considered (by a reasonable human) either of two or more different “types” of (e.g., an electronic map, an electronic serial, a music score on microform) must still be assigned a single code. Since this code drives material type searching, both in staff and public interfaces, users have to understand cataloging rules in order to limit searches effectively. This is, in my mind, completely backward.
So I would love to see an implementation of “Resource Type” that is repeatable.
Hi Laura,
Do you basically mean repeating “tags” for resource type? So tags that could describe electronic vs tangible (physical, print, whatever makes the most sense). Other tags that could describe type of material (book, journal article, recorded music, music score, spoken word audio, video, map, etc). And maybe still other tags that would be meaningful to a particular community (e.g. not just a score, but in a music library having tags for piano score, miniature score, full score, score + parts, score + libretto, etc).
Then depending on the tags assigned to a particular instance, the search/display could take advantage of whatever mix & match the library preferred?
Yes! In MARC, the format is inextricably tied to the “primary” format of the material which drives the workform used, which fixed fields are available, etcetera. I don’t see why we need to continue that in a new model.
Hi Kathryn - I had assumed that what we’re calling resource type was being inherited from the MARC bib level material type. Cate’s suggestion that something else was being imagined is news to me. It’s not wrong and certainly could have real advantages when building circ policies, it’s just that I’m not sure how we’re going to load/map this info from our current systems if it isn’t coming from the material type.
It’ll also add another element to cataloging workflows and potentially cause issues for functions that rely on Z39.50 and NCIP based resource sharing systems since these standards wouldn’t recognize it.
Most existing systems (actually every one that I’ve seen) only allow for 3 elements to control circ rules (location, patron group and item type). That means that in practice most item types are a pretty weird hybrid of material type and circ rule. For FOLIO we’ve put in resource type as a 4th element that is separate from item type. So reserve is the item type and DVD would be the material type. How this would work given Laura’s very valid point about MARC and primary formats is a question that I hadn’t considered.
Andrea
IIRC Aleph has a 4th element that influences circ behavior - the item process status. Aleph uses location + patron status + item status + (very optionally) item process status.
I can’t recall what exactly we used item process statuses for but I remember only one or two were elements that we used in defining circ behavior.
I think it would be fruitful to gather a small group to discuss this – part of the discussion will be bringing me up to speed on the recommendations that the RA SIG has made, and part can be some brainstorming and problem-solving. I’d suggest that we convene a few folks for an initial discussion – maybe one or two people from RA and one or two from RM/MM – to make some quick progress that we can then socialize with the larger group.
I’m happy to coordinate this if it sounds like a reasonable approach…
Sounds reasonable to me