Thank you on behalf of the whole TMS community for sharing this Frances!

[cid:image001.png@01D16E4E.942FCC80]<http://npg.si.edu/>

Sue Garton
Data Administrator and Acting Head of
Collections Information & Research Archive
Smithsonian
National Portrait Gallery

[log in to unmask]<mailto:[log in to unmask]>  |  202.633.8554

From: The Museum System (TMS) Users [mailto:[log in to unmask]] On Behalf Of Frances Lloyd-Baynes
Sent: Tuesday, June 13, 2017 4:22 PM
To: [log in to unmask]
Subject: A Few Questions & Answers re: the new TMS Thesaurus Manager & Local Authorities

I had a few questions regarding the TMS Thesaurus Manager that I'd not been able to answer from the User Help, webinar content, or the list-serv archives, so turned to Gallery Systems directly. Since that conversation was on a private channel, I thought I would share the questions and answers in case others had similar questions/concerns.

All the best,
Frances
-------------------------------------------

‘Authorities’ (i.e. local authorities) in TMS Thesaurus Manager
1. We no longer have to put our local authorities under the ‘Authorities’ branch in the new Thesaurus Manager. What are the benefits to separating these authorities out (other than the new ability to set security access at the Concept Scheme level)?  I think the main benefit is more structured security. As well, having the concept schemes spread out can improve manual searching and slightly improve performance.
2. It appears we can only control (via security permissions) the ‘Authorities’ concept scheme as a group (in TMS 2016R2). Can we move existing local hierarchies out from under this ‘scheme’ to make them separate, independent Concept Schemes and thus control who has access to them at a more granular level? What are the implications of such a move?  Yes you can, there won't be any negative repercussions doing this.


  Attributes  (under 'Authorities' in the Thesaurus Manager)
1. Why is the Attributes hierarchy divided up by module (e.g. Objects) and module cross-reference (e.g. Object – Constituent Cross References)? (I have found no explanation as to why it was structured in this way.)  I believe this was purely organizational, a way to keep concepts specific to a module.
2. What is the impact (benefits and limitations) of having a vocabulary listed under one of these module-based Attributes sub-groups? (e.g. Attributes / Objects / Inscription Query Terms)
The attributes tree gives you a built in organizational structure, but it has limited security since all users would have the same security to all the hierarchies under Authorities.

3. Can a vocabulary be moved from its place in the current Attributes hierarchy without ill effect? (E.g. take our ‘Inscription Query Terms’ out from under 'Objects' and place it directly under ‘Attributes’)
Yes, you can cut and paste a node to any other local concept scheme. This means you won't be able to add to the AAT or TGN.

4. Can one go so far as to take a vocabulary out from under the ‘Attributes’ hierarchy as well as the ‘Authorities’ scheme and set up as its own Concept Scheme?
Yes, you will need to create a new concept scheme and assign security to it (by default, no users have security rights to a new concept scheme) then you can copy/cut and paste your Inscription Query Terms or any other concepts into the new scheme.

I believe the idea behind expanding the capabilities of the thesaurus was to provide more options for our clients, every institution can decide what is best for their specific workflows.
--
Frances Lloyd-Baynes  |  Content Database Specialist
Minneapolis Institute of Art
2400 Third Avenue South
Minneapolis, MN 55404

612-870-3189  |  [log in to unmask]<mailto:[log in to unmask]>  |  www.artsmia.org<http://www.artsmia.org/>

[http://www.artsmia.org/images/email-banners/MIA-exhibition-signature.jpg]
To unsubscribe, send an email to [log in to unmask]<mailto:[log in to unmask]> with the following commands in the body of the email:

signoff TMSUSERS

// eoj

You will receive a confirmation that your subscription has been removed.

To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

     signoff TMSUSERS

     //  eoj


You will receive a confirmation that your subscription has been removed.