Subject term subfields

[m.gor...@gmail.com]

I'm having trouble understanding how subject heading subfields work.  I made the main entry of Foreign study.  Then I added Luxembourg as a narrower term.  I assume narrower terms are subfields like x for topic or z for geographic.  Is there no way to tell AtoM to think of Luxembourg as a geographic subfield z for the main entry Foreign study?

Then when I assign the subject string Foreign study--Luxembourg to this test collection, I need to select Luxembourg, which is a narrower term, in order to get the subject string to appear (subjects2).  How is someone supposed to know that from the list in the subjects1 image, that Luxembourg is a narrower term under Foreign study when there is nothing identifying it as such?

Thanks,

Matt G

SIU Carbondale

[Joey Denton]

Hi Matt

My workaround has been to put the parent term in parentheses after the term. It makes it a little wordier on the description page, but you can tell exactly what you're choosing from the drop-down. I do this for places and genre terms as well.

Some examples

Buildings » Commercial Buildings (Buildings) » Warehouses (Commercial Buildings)

Ceremonies » Ground-Breaking (Ceremonies)

Texas » Tarrant County (Tex.) » Fort Worth (Tex.)

Publications » Articles (Publications)

Hope this helps!

Joey

[Dan Gillean]

Hi Matt, 

Unfortunately AtoM's access point taxonomies (such as subjects, places, and genres) don't currently have MARC-like functionality for specific subfield types. It's a much simpler approach, drawn from the SKOS noticion of "concept" - you can have a narrower or a broader concept, but we don't currently have a way of adding detailed pre-coordination across different classification schemes to terms. 

I agree that, from a user experience perspective, AtoM should be able to show the inheritance in the autocomplete drop-down, so editors can be better oriented. We could likely do this fairly easily - although you do run the risk of not being able to see the full term when working with deep hierarchies, without first re-designing how adding terms is displayed in the edit interface. For cases where the terms are not extremely long and the hierarchy not too deep, that should work. Redesigning the interface to support the display of very deep hierarchies would be a more intensive development project, requiring some analysis and design. 

Another workaround, in addition to Joey's suggestion, would be to forego organizing your terms hierarchically, and manually create terms that include your subfields as you wish them to be displayed. For example, creating a literal term that is something like: 

• Coffee --- 20th century --- roasting

This doesn't allow users to see all descriptions related to the broader term (Coffee) very easily, but would in the meantime give you the control you need in the edit interface. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/eac0eb92-6f3c-460b-a619-6ab7f169046e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[m.gor...@gmail.com]

Dan,

If we did type the string manually, and AtoM later on features MARC export and functionality, do you envision that the programming would automatically be able to dissect the string and know what the main entry vs subfields are, AND correctly assign the subfield with the correct MARC code (x, y, z, v)?

Matt

[Dan Gillean]

Hi Matt, 

Given how complex MARC-based pre-coordination can be and how many different possible sub-elements in different combinations you can have, I think that adding that kind of automatic detection and migration would be.... expensive. I would have to explore MARC a bit deeper to say whether or not we could actually create regex rules that would accomplish such a transformation, but it may be possible. We would probably not add such functionality directly to AtoM in any case; we'd likely make a script available (with a lot of caveats about edge cases) for upgrading users. 

I will say as well that, given that MARC is being slowly replaced by newer standards like BIBFRAME, I think we are unlikely to include MARC import/export in AtoM at this time - perhaps MARC XML if an institution prioritizes funding it, but given that MARC is declining in use and is primarily focused on library cataloging and not archival description, I'm not sure if any current AtoM users will prioritize such development? Who knows!

Regards,  

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3e4a901e-5dca-4ea5-8889-30ac26a49df3%40googlegroups.com.

[Matt Gorzalski]

Dan,

Good points.  I do think having subfields that focus/narrow the broad "main entries" remains valuable.  AtoM makes that possible with the narrower term option within a subject term in the taxonomy, but like you said, it would be nice if that was more user friendly.  I've been looking at the online manual, and wondering, was it the designer's intention that the narrower terms function like a subfield?

Matt

You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/Pa-x-3O2ed4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ica-atom-user...@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZJP9BM3yUGeKcbjmRuD9C8rgkQ6CK6_HDyV8R7UdtOe7A%40mail.gmail.com.

[Dan Gillean]

Hi Matt, 

As I mentioned previously, the taxonomy organization was modeled against SKOS, which allows for terms to have broader, narrower, or related relationships, so it's somewhat different from and simpler than a fully coordinated vocabulary. 

Because there are separate taxonomies for place, genre, and subject in AtoM, adding subfields could somewhat confuse this - and in some ways (depending on how it was implemented in AtoM), could make the access points overly specific and therefore possibly less useful for discovering related materials. 

For example, your term "Foreign study--Luxembourg" is pretty specific - and in a taxonomy system separated by place/subject/genre, users might not be able to click just on "Luxembourg" to see other records related to that place, but not to foreign study. Instead, in the current implementation you could add a place term for Luxembourg, and a subject term for Foreign study. Users have the option to search/browse records that have both terms, or just one, depending on their interest. It's a different way of thinking about your terms and their relation to each other than classical bibliographic coordination, but many of the same benefits can be achieved by adding multiple terms.  

That said, it was also first implemented 10 years ago, and might benefit from an overhaul! Note that in any development project we undertake that changes our templates, we also have to consider existing users, and how legacy data can be upgraded to continue to work within any changes. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAPEsG%3D1vMZLFEA0Ljq9Hx%2BdCkJW4E5KZNs_QN%2B%3DB_kNu%2BpTWrQ%40mail.gmail.com.

[m.gor...@gmail.com]

I like the idea of redesigning the interface to show the string of linked broader/narrower terms so that an archivist knows if s/he is selecting the correct narrower term.  Without this, the current design is a guessing game, say, if you have "Illinois" as a geographic narrow term beneath several different topics that you can't see.  But...maybe I'm thinking wrongly about these access points.  I suppose Illinois would be listed separated as a geographic access point, instead of mixing topical subjects with geographic subdivisions as MARC does.

Either way, the redesign is a good idea and hopefully and institution not pinching pennies to the extent we are can fund it.

Matt G

On Thursday, December 13, 2018 at 10:22:41 AM UTC-6, Dan Gillean wrote:

[Dan Gillean]

Hi Matt, 

One simple improvement we could make without requiring major changes would be to show the inheritance in the autocomplete dropdown, a bit like the following: 

We would have to consider several factors carefully, such as: should the autocomplete match on any term in the inheritance chain, or just the last term? How should we handle narrow view widths, such as on mobile devices? Do we wrap the full term to the next line, or add ellipses (either to the earlier/parent terms, or to part of the middle) to part of the inherited term? And so on. 

Still, this would allow for more context without significant redesign. Since SKOS does not really support subdivisions (unless you hardcode them as a single term), adding support for subdivisions would mean needing to find and replace the export formats available as well, which starts to look like a much bigger job. 

One thing I do like about the ArchivesSpace interface is that you have an option to open a modal and browse all terms while in the description edit page, and even add terms from the browse modal: 

Modals can sometimes lead to a frustrating user experience, and can be difficult to maintain (depending on how they are implemented), but a super simple and affordable option for AtoM would be to add a button above the edit fields that says "View terms," that simply opens the related taxonomy browse page in another tab. Users would not be able to add terms directly from there, but it would at least offer users the option of quickly getting to browse the terms without having to leave the edit page of the current record. 

The idea behind both of the above suggestions is primarily to find ways to enhance the usability without requiring major redesigns, thereby keeping the costs more accessible. There is certainly much more that could be done, but the more complex we get, the more those changes cascade throughout the application and require greater resources to implement. 

I would also love to hear other perspectives from our community - how could we improve term management in AtoM? What would be your priority enhancements or fixes?

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/1e70df45-3311-44f5-a86b-f0aedb0e76b8%40googlegroups.com.

[Creighton Barrett]

Hi,

Those are some great possibilities, Dan! I find ArchivesSpace's use of modal windows to be helpful at times and also painful at times. I don't know that I have a strong preference about interface design right now, but I just wanted to add some other perspectives to this thread. Term management is partly about the software and partly about local cataloging practices. When we first implemented AtoM, some members of our team that are also familiar with library cataloguing set out to add LCSH subject headings as they would do in the library catalogue. And we handled sub-divisions as Dan has described with his "coffee" example. We felt that this approach would give users the "look and feel" they are used to and that the -- characters could be used to parse the data if/when a future need arose. We also started with a medium/long-term goal of working towards a "single search" interface.

After a while, we retreated from this approach. We have mostly stopped adding new terms with sub-divisions and have been working to remove all geographic and date sub-divisions. Instead, we use more general subject headings and place a lot of emphasis on geographic place terms and quality dates of creation metadata. We came to this conclusion for a few reasons:

• We felt that we could develop tools and resources to help researchers understand advanced search functions and faceted browsing in AtoM. It felt new to our team, so it must be new to the outside world.
• We felt that our database (which has 250,000+ archival descriptions) wasn't "deep" enough to warrant thousands of subject headings. Browsing the big list was a bad user experience.
  
• The goal of developing a proper "single search" interface where users could search and browse data from our AtoM site, the library catalogue, institutional repository, etc. is still long-term.

Now, we try to be selective and relatively broad about how we add subject headings and we try to include more specific terms (like "roasting") in the text of the archival description. And we try to emphasize start date/end dates in the description. The focus is now on advanced search and faceted browsing in the AtoM application, not LCSH sub-divisions like we do in our library OPAC and not a single-search interface that we don't have. We have also limited the ability to create new subject headings to staff with "editor" or "administrator" privileges. 

So, instead of  Foreign study--Luxembourg as a subject term, we would have Foreign study as a subject term and Luxembourg as a geographic place term. It does add some extra clicks for a person with that specific interest, but it also allows all kinds of advanced search and faceted browsing options that wouldn't be possible in AtoM if we just used the Foreign study--Luxembourg term.

Not sure if this helps, but I wanted to chime in because I think the answer to Matt's last question might be that people wouldn't need to know about Luxembourg if you approached the metadata from a different perspective. They wouldn't need to know that Luxembourg is a narrower term of Foreign study if they were shown that all geographic terms were in the geographic places taxonomy rather than the subjects taxonomy. Our experience has improved since we shifted towards a more pragmatic philosophy for access points and clear procedures for creating archival descriptions and adding access points. The issue for us wasn't just about AtoM functionality, it was how we were using AtoM and how we were thinking about access services and relationships to other parts of our organization. A similar improvement happened when we decided to populate the genre terms taxonomy and begin removing related terms from the subject headings taxonomy. 

A final thought: if you are not already using the ISDF "Functions" taxonomy, you could always hijack that taxonomy to suite your purposes.

Cheers,

Creighton

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKosx%3DJnf13zbp4O%2BnwZ5V10z5qzkJoJ9j5yx7iW_hnGQ%40mail.gmail.com.