Forgot password? | Forgot username? | Register
  • Index
  • » Users
  • » WillScott
  • » Profile

Posts

Posts

03-Feb-16 14:58:54
Wish list - I'd like to be ability to specify how many precoordinated terms are added from...
Forum: Thesaurus

Hi Rowena,

You might be interested to know that KE has made some progress on revisions to the Thesaurus Module, in case you are not yet aware. I recall that you provided feedback on the "Thesaurus Enhancements in EMu" thread in this forum. Some of these developments were presented at the User Group meeting, at University of Pennsylvania, in 2015. I wonder if these changes might provide a better solution than setting a limit on the number of full term organizations to be displayed.

A new left pane is available in the Thesaurus Module, based on Archives View, that shows a hierarchical/tree display of every BT-NT organization for each term. A new Hierarchy tab can be added that displays a tree view of a term's full organization. That tab includes every distinct organization for a term (BT/NT, not Alternate or Use/Used For). Both are fairly new, and have only briefly been "in the wild" for live feedback. What I have seen so far, however, looks rather promising. In the current version, the loading of these views can be a bit sluggish, especially for terms with a large number of organizations. It is still a significant improvement, however, on the previous Browse View.

My main KE/Axiell contacts related to the Thesaurus enhancements have been Ian and Brad. If you are unable to obtains details about the recent Thesaurus Module changes/developments, or if I may be of any assistance, otherwise, please let me know. 

Best,

Will

Will Scott

Will Scott Consulting, LLC
will@willscottconsulting.com
www.willscottconsulting.com

Hi Nancy,

In case no one has replied to you directly about this post, I thought I'd mention that Penn Museum has a Tab in Bibliography for this. The tab and fields were inherited in their initial design, possibly from a template client, but more likely from the standard Bib. module (as of around 2010).

Fields scoped for use include:

Type (="Web Site")
Language
Title
Abbreviated Title
Web Site Identifier
Name (Authors/Contributors)
Role (Authors/Contributors)
Publisher
Publication Date
Last Access Date
Reference Type
Reference Details

We also changed the modeling of some data at UPMAA by adding a Citation Type and Notes field to Bib. Tabs in other modules (Catalogue, etc). That allows for recording of the relationship between the object and the Bib. record on the object side, rather than fixing it in the Bibliography record. Depending on the museum's needs/use, it may be worth considering placing "[Web Site] Last Access Date" in the Bib. Tab of uses Modules, rather than in the Bibliography Module, to avoid creating duplicate records in Bibliography that only differ by Access Date. 

Based on discussions at the User Group meeting in October, 2014, I do not have the sense that URL/URI linking directly in/from fields is currently available. I know that would be desirable by a few clients, so would love to hear from you if you learn differently or if you request KE to implement links in fields. In the meantime, of course, configuring the Tools-Resources menu to pass addresses from the Web Site Identifier (or other field) to a browser might save a few clicks.

Feel free to contact me directly or reply here if I can be of any assistance.

Best wishes,

Will

Will Scott
Museum & Database Consulting

18-Dec-14 06:18:24
Need advice on fields to use with Nomenclature 3.0
Forum: Catalogue

Hi Anne,

If you only needed one set of classification terms (category, class, and object name), hierarchical Lookup Lists might be able to handle some of the need to limit lower tier values based on entries in higher levels. I do not believe that will work well with multivalued fields at each tier, however.

Have you considered looking into the EMu Thesaurus Module? It works well in multivalued fields to enforce the standard parent-child relationships, and could allow a search on Object Name for a higher-level category term to return matches for all narrower terms. It may require a minor rethinking of how the category and class appear in your Catalog module; but with some discussions with KE, I think you could display something fairly similar to what you have now.

This post may be useful, if only for contacts of others using Nomenclature with Thesaurus:

https://emu.kesoftware.com/support/emu- … menclature

I would be glad to discuss this with you further via e-mail. My address is in my forum profile.

Best wishes,

Will

Will Scott
willscottconsulting.com





19-Sep-14 16:47:44
Looking for solutions on recording pest checks against works

Hi Dave,

I would like to be part of this discussion if time permits. University of Michigan has expressed an interest in pest management solutions.

Best,

Will

29-Aug-14 11:18:15
Request for information about the use of Tulane's GEOLocate service with EMu

I am curious to know if any institutions are using Tulane's GEOLocate project/service with EMu, and if so, how it is being utilized?

A few users are interested in having it work similarly, with EMu, to how it works in Specify.

Thanks!!

Will

Will Scott
Museum & Database Consulting

29-Aug-14 11:04:53
Does anyone utilise KeEmu using a laptop?
Category: Using EMu

Melissa,

Thanks for your helpful addition to this topic. I just happened across it right as I was looking at wifi considerations for a client.

How does EMu perform over wireless there? Have you noticed any specific tasks that take an unreasonably long time?

Thanks!

Will

08-May-14 12:25:10
Category: Using EMu
Forum: Searching

Heather,

In case you have not already found a solution, write to KE support and ask them to provide instructions on joining by row number in nested grids. If that sentence does not make any sense, just copy and paste all or part of this message in your support request. I believe that there is a way, not a user-friendly one, but a way to accomplish some of the searches you described in your 10/13/2013 post using Show Search. It will require editing the query TexQL, but should work without needing to know the precise row number.

I share the frustration with KE not communicating query limitations for these fields during design. I was lucky in my last project to have Jay K. raise it as a concern early on, but it seems that other clients might not have been given a "heads up." The tabular appearance of these fields suggest relationships that do not exist. New clients, selecting field types as part of designing an EMu configuration, will naturally assume certain query functionality. Perhaps that could be addressed as part of standard initial training (prior to client template selection).

Best,

Will

08-May-14 11:48:37
Category: Using EMu
Forum: Searching

Hi Tom,

Would editing the query to include a condition that rownum=0 not work? Do you need to find the value in any column of the first row or one specific column?

[See disclaimers below, the following is not a tested solution]

You might try something like:

select all
from ecatalogue
where (<nested grid fieldname> = <query condition>) AND (rownum = 0)

Here is a partial query that Jay K. provided Penn during the design phase to describe how to join columns of a nested grid by row number. This is not a solution to your problem, but might help to inform one.

and exists
(
select all
from
(
select rownum as r1
from COLA_tab
where COLA contains 'TERMA'
),
(
select rownum as r2
from COLB_tab
where COLB contains 'TERMB'
)
where r1 = r2
)

Disclaimer 1: I do not have time to test this tonight as I am starting a new project.

Disclaimer 2: I reviewed this post fairly quickly, so please forgive me if I have overlooked anything.

All of my best to you. Hope to see you again soon.

Will

I have a couple of thoughts about Related Terms based on the proposed enhancements. I am hoping that someone who is very familiar with AAT or other standard thesauri will comment on the use of "Related Terms" for querying. My initial notes on the subject, of course, were never intended to be a full specification, but a description of certain missing functionality. Upon review, I wonder if simply offering Related Term queries, across the board as a toggled option, may not be sufficient for some clients. I am also interested to know the impact that symmetric relationships will have on ARGUS conversion clients who had the additional option of "See Also"/"See From" relationships.

Do We Need Separate Fields for Queried and Non-Queried Related Terms?
In some thesauri, RT is intended to designate an associated concept for reference only; and those terms are not always closely enough related to merit inclusion in a query. In the current proposal, such cases could be handled by turning off the "search related terms" option. However, there may be cases in which an authority or institutional thesaurus requires both the recording of broadly-related concepts (not intended to be included in EMu queries) and the creation of more direct "search also" relationships (that are to be included in queries). The "search also" relationship would allow the person organizing a Thesaurus term record to instruct EMu to always search some other term (Term B) and its narrower terms when a user queries for Term A.

Should One-Way "See Also" Relationships Be Available?
In Penn Museum's previous database/software (ARGUS), "search also" was labeled "See Also," with a reverse relationship term, "See From" or "See Also From." If Term A was queried using a Thesaurus tree search, the results included matches for Term A, Term A Alternate Terms, and Term A Narrower Terms as well as Term B, Term B Alternate Terms, and Term B Narrower Terms. This organization had a clear direction, meaning that a query for Term B would not also search Term A.

The proposal indicates that "Related Term" relationships will be symmetric (A is related to B in exactly the same way that B is related to A). Users will also be able to include them in EMu Thesaurus Queries, similarly to how narrower terms may be included in the search for a broader term. A search for related Term A (using the new feature that includes "related terms" in queries) would return matches for Term A and Term B. And, as a result of the symmetric relationship, a search for Term B would likewise return matches for Term B and Term A. There are some cases in which this type of relationship makes sense, such as for near synonyms that require separate records.

In other cases, however, it may be desirable to structure these relationships so that one term also search another term, but the other term does not also search the first term--a directional (or asymmetric) relationship as I described in the above paragraph about ARGUS. For example, the term, "cross," (organized under one branch of the Thesaurus) may be set up so that a query for "cross" also returns matches for the term, "crucifix," (organized under a different branch). It would not be desirable, in that case, to have queries for "crucifix" also return matches for "cross." What may be needed is a one-way (asymmetric, reciprocal) relationship, that is not BT/NT, but that behaves in queries like it is.

Do other Thesaurus clients, especially former ARGUS users, desire or need these one-way See Also relationships in the revised module?

Labels, Language, and Z39.19-2005:
1. The label "Related Terms" makes sense for Associative Relationships (8.4) that are not to be automatically searched. "Related Terms" should be retained as the label for this field/function.

2. When the "Related Terms" are included automatically in queries, it more closely resembles "Near Synonym" relationships (8.2.3). In that case, two terms that do not exactly express the same thing (in separate records) are treated as equivalent for the purposes of the thesaurus and querying. Use of Alternate and Preferred terms in the same record, of course, is ideal, but not always viable. This is a symmetric relationship (8.1.1) where the affiliation of A to B is the same as B to A--Term A is a "Near Synonym" of Term B and Term B is also a "Near Synonym" of Term A. If a second field is created to distinguish search-able lateral relationships from associated relationships, another label will need to be selected (perhaps, "Search Also" or "Near Synonym").

3. "See Also"/"See From" is an asymmetric relationship (8.1.1) that extends BT/NT hierarchical relationships to allow for special cases. If fields are added to handle this relationship, labels will need to be selected for an attachment and reverse attachment field. I envision these as being "See Also" and "See From" respectively.

Regarding #2 in my last post, Scott Williams made a good case for allowing objects to be returned to their permanent location when the permanent location matches the current location. In the case of an inventory this tool might be used to update the location metadata (date, done by, notes) for records, confirming that the selected objects were found at their anticipated, permanent, location. I still lean toward providing an error message, but it should be for the group (not for each object encountered) and should allow the user to tell it to continue regardless of the warning.

A version of this feature was implemented as a customization for Penn Museum. It works like the Relocate Tool, except the Location field is hidden in the Relocate dialogue box. The new location is determined by a Permanent Location field on the Location Tab for each record.

In reviewing this discussion, I did some additional testing of the Tool and found a couple of things that need to be addressed. If you have ideas on how these cases might best be handled, please post them.

1. Objects in a selected list that have no Permanent Location are simply ignored. No update is performed. I would prefer the tool fail with a useful error stating that all objects selected must have a Permanent Location. A softer approach would be to let the process complete but produce an error at completion stating which objects were not updated. I like the former option since it encourages prior review of Permanent Locations.

2. Objects with a Permanent Location that is the same as the Current Location should be checked. A prompt stating that fact along with the relevant IRNs would be helpful. Again, I prefer a stricter approach that would not allow the tool to complete until the situation is resolved. If that gets too much in the way for some institutions, the softer approach might be to provide a warning that allows the choice to continue or cancel.

3. (Added after initial post) If we want to get a bit more robust with this feature, it would be helpful to have a "block" list of locations, perhaps in the Registry or directly in the Locations Module. This would prevent an object from being returned to an "Unknown" or "Missing" type of location, for example, using Return to Permanent Locations. (Not that I have ever encountered a museum that did not know the precise location of each and every object  ;) ). There may be other uses for this option, as well, including other generic locations and deprecated locations. Those terms could be blocked from being entered into the Permanent Location field, instead of blocked by the tool, except some may come over from data conversion prior to configuring that validation or may have been entered prior. If any blocked locations are encountered, an error message should be produced.

I agree with earlier caveats about relying too heavily on the assumption that a Permanent Location is actually persistent. There is, in fact, no such thing as a truly permanent location. That said, similar features have proven useful when handled by responsible users. In ARGUS, this feature would display a list of accession numbers in a table alongside each object's permanent location. At that step, users could review that the destination locations were correct or edit the locations if they were not correct. In EMu, I think a user-customized List View showing object number, current location, and permanent location could serve the same purpose. Users could check that prior to running Return to Permanent Locations.

Will Scott
Museum & Database Consultant
New York, NY / Philadelphia, PA

19-Oct-12 07:49:56
Thesaurus query functionality, supplement to EMu Help
Forum: Thesaurus

I created this document for Penn Museum to provide additional details about current query functionality. It is somewhat geared toward their data and toward former ARGUS users, but provides a few details about querying using Thesaurus that are not available elsewhere (to my knowledge). I am posting it here as a resource for other users.

Searching-Using-the-Thesaurus-UPMAA---Will-Scott.pdf

Will Scott
Museum & Database Consulting
New York, NY / Philadelphia, PA

19-Sep-12 07:27:44
Direct relationship between Narratives and Accession Lots?
Forum: Narratives

In working on standards for the Narratives Module, I found myself desiring a direct link to the Accession Lots Module. Penn Museum uses a slightly customized version of Acc. Lots to track both accessions and deaccessions. Narratives could be useful in tracking relevant correspondence and meeting minutes that document offers, processing, and approval of the acquisition/disposal of objects. It would be more natural to relate those Narrative records directly to the Accession Lots record than to each individual object.

April posted recently about tracking accession correspondence in Narratives. For those museums who tend to acquire objects in lots more often than individually, I think a direct relationship between these two modules could be quite useful.

Does anyone have a configuration of Narratives that links directly to Accession Lots? Would others be interested in having that available?

Best wishes,

Will

Will Scott
Museum and Database Consultant
New York, NY / Philadelphia, PA

15-Sep-11 09:09:06
Are more robust "Related Term" relationships needed?
Forum: Thesaurus

A review of ANSI/NISO Z39.19-2005 supports these points. Relationships should be reciprocal; and, "near synonyms" are addressed. The selected quotes below have been extracted from that standard. Please note that, on its own, this post does not provide a full overview of the treatment of these topics in Z39.19.

A full copy in pdf format is available from Z39.19-2005 at NISO.org.

8.1.1 Indicating Relationships Among Terms
"A basic property of relationships in controlled vocabularies is that they are reciprocal; that is, each
relationship indicated between Term A and Term B must have a corresponding relationship from
Term B to Term A. This rule must be observed for all types of relationships.
The conventional abbreviations for relationship indicators are used in the examples below. Additional
abbreviations for specialized purposes are found in the following sections. (A complete list of
abbreviations used in this Standard appears in section 4.2.)
The relationship indicators are always paired operators. Some indicators are symmetric while others
are asymmetric as illustrated below:
• Related Term (RT) is symmetric:
If Term A RT Term B, then Term B RT Term A
• Preferred Term (Equivalency) – USE and UF are asymmetric:
If Term A USE Term B, then Term B UF Term A
• Hierarchical Relationships – BT and NT are asymmetric:
If Term A BT Term B then Term B NT Term A."

AND

8.2.3 Near-Synonyms

"Near-synonyms are terms whose meanings are generally regarded as different, but which are treated
as equivalents for the purposes of a controlled vocabulary." [...]

16-Aug-11 06:55:15
Which museums are using the Thesaurus regularly?
Forum: Thesaurus

Hi All,

I have posted a few new topics in the Thesaurus section of the KE User Group forum and would love your feedback!

http://www.kesoftware.com/emuusers-forum/thesaurus.html

Many thanks!

Will

Will Scott
Museum & Database Consultant
Philadelphia, PA / New York, NY

In most EMu searches, the NOT operator (!) is used to request everything that does not match a specific condition. For example, !Asian could be used to request only objects that do not have Asian in the Department field.

Including the exclamation mark in a query on a branch of the Thesaurus (using #+) does not produce an error, but does not provide the anticipated results. This could lead users to believe that they have retrieved a desired set of records when in fact that list does not match the intended query.

!#+Musical T&E, Percussion  -   returns no records. EMu interprets this to be a search for NOT “#+Musical T&E, Percussion” as if the #+ was part of the term.

#+!Musical T&E, Percussion  -   ignores the exclamation mark and produces the same results as #+Musical T&E, Percussion would.

Most NOT queries can be handled through Additional Search or by using #- and deselecting undesired terms. While those procedures are somewhat more cumbersome than I would prefer, I am mostly concerned that this functionality will mislead users especially in more complex queries.

Does anyone else find this to be concerning or, at least, counter-intuitive?

16-Aug-11 03:35:56
Which museums are using the Thesaurus regularly?
Forum: Thesaurus

Thanks, Mark. I would love to know more about the changes you are making to the Thesaurus Module. Is it just adding key joins like Te Papa or are you considering other development work as well? I have considered the key-join model too and wonder if it affects any existing functionality other than perhaps the ability to use Thesaurus for querying and data entry in fields that are not Thesaurus-controlled.

16-Aug-11 03:26:03
Jumping directly to a specified Thesaurus term in Browse View?
Forum: Thesaurus

In Browse View of the Thesaurus Module, the view mode that displays the terms and relationships in a "tree" structure, there is no means of jumping directly to a term within the hierarchy in order to view its broader organization. A user must search for the desired term there by clicking on whatever root term is available, then down through sub-categories/parent terms. This method works fine for very limited thesauri, or when the organization of the term is already known. In a more complex hierarchy where the full organization of a term is unknown, however, finding that overall organization seems cumbersome. Has anyone else found this to be the case?

To find the broader organization of a Bongo drum, for instance, a user needs to do the following. I am providing a simplified example, by the way, for the sake of communication.

1. Search for "Bongo" in the Thesaurus Module.
2. On the Hierarchy Tab, locate the desired broader term, in this case it is "Drum".
3. Open a new instance of the Thesaurus module by clicking on the view attachment button for the Broader Term.
4. On the Hierarchy Tab of the broader term record (Drum), review its broader terms. Here they include "Musical T&E, Percussion" (from Chenhall) and "Membranophone" (from Sachs/Van Hornbostel, a standard that groups instruments by how they make noise).

Assume, now, that the user wishes to look at everything organized under "Musical T&E, Percussion" including narrower terms of its narrower terms (to see an overall view of that branch), the most efficient way to do that would be in Browse View of the Thesaurus Module. This user may not know where to find Chenhall in the context of the full Thesaurus, however. To discover that organization, the user will need to continue the process listed above for each broader term until the root term of the Thesaurus is found, then open Browse View and traverse the hierarchy there from the top down to get to "Musical T&E, Percussion". Using this method, I often find myself having to open eight or more instances of the module.

I wonder if this could be made more efficient through a Find Term feature within Browse View, or the ability to select a term record from full view for display in Browse. The design would have to account for multiple parenting, of course, and would need to still allow clients to restrict data entry to specific branches of the Thesaurus. This seems like it would be especially useful in the organization of newly-added terms as well.

Would there be interest in working together to create a specification for development of this feature/functionality?

11-Aug-11 02:43:26
Which museums are using the Thesaurus regularly?
Forum: Thesaurus

Thank you, Leslie! Sorry. I should have spelled out the acronym. By SIG, I was referring to a Special Interest Group such as those that meet to discuss certain topics or features at the User Group events.

10-Aug-11 11:13:05
Searches on Alt. Terms do not return matches for the primary term
Forum: Thesaurus

A # query for the "primary term," the term that is located in the Term field of a Thesaurus record finds that term any any of the terms listed in the Alternates field for that same record. However, a query for any of the Alternate Terms using the # operator returns records that include the specified Alternate and any other Alternate from that Thesaurus record, but not the Primary Term. I find this somewhat counter-intuitive. Has anyone else has issues with this functionality?

It seems to me that if a user does not know whether the queried term is stored in the Term field or in the Alternates field and searches for what turns out to be an Alternate term, they will likely receive results and assume that the primary term was included when it was not.

KE Support explained this behavior by stating that users would want the ability to query only for Alternate Terms. If users were able to find all Alternates and the Primary term using the # operator, however, I think that it would make queries much more intuitive and save users the time required to look up the primary term for each search term in the Thesaurus. To find all Alternates without the Primary term, a query that is less-frequently desired, users could run Additional Search to remove all matches for the Primary Term.

In fact, I would love to have an operator (##+?) that included all Narrower Terms as well as all Alternate Terms in a query. Presently to search for both Narrower Terms and Alternates, the term must be entered twice in the query form, once with each operator (#Term | #+Term).

Will

Will Scott
Museum & Database Consulting
Philadelphia, PA / New York, NY

10-Aug-11 10:46:45
Which museums are using the Thesaurus regularly?
Forum: Thesaurus

Thanks, Susan! Was your Object Name thesaurus originally developed in the ARGUS Lexicon? I recall working with Powerhouse when I was at Questor. I would certainly be interested to know what issues you encountered in your migration to EMu, or are dealing with now. Some of the concerns I have with the EMu Thesaurus module relate to how the Lexicon was used in ARGUS and to user expectations (at Penn Museum) based on their custom Lexicon/Thesaurus built in that software.

10-Aug-11 10:31:30
Are more robust "Related Term" relationships needed?
Forum: Thesaurus

Many standard Thesauri include both vertical (broader/narrower or parent/child) relationships between terms and lateral relationships ("related terms") between terms as well as synonyms ("alternate terms"). Related Terms allows two distinct terms (separate Thesaurus records/columns) to be described separately and related as near to equal but not exactly synonymous.

Take Ch'an Buddhism and Zen Buddhism, for example. They are historically linked and quite similar in concept, but the Chinese version (Ch'an) may be considered notably different from the Japanese (Zen). From a query perspective, I may wish to search for "Zen" or for "Ch'an" specifically. But, I may also wish to allow a broader query that will include Zen when Ch'an is queried or Ch'an when Zen is queried.

While EMu offers a Related Terms field in the Thesaurus Module, it has no real query functionality. The #+ operator does not include it in Thesaurus searches and no other operator exists to include it in a search. Furthermore, the relationship created in that field is not reciprocal and no reverse attachment field seems to exist for it. If I link Ch'an to Zen as a related term, there is no indication in the record for the term Zen that Ch'an lists it as related. While I know that fully reciprocal relationships do not exist in EMu, it would be extremely useful, I think, to have some indication that a link has been made on both related records, and to have some means of including Related Terms in queries.

Has anyone else struggled with handling these relationships in the Thesaurus Module? Any suggestions for workarounds?

Many thanks!

Will

Will Scott
Museum & Database Consulting
Philadelphia, PA / New York, NY

10-Aug-11 09:53:21
Which museums are using the Thesaurus regularly?
Forum: Thesaurus

Thanks, Adrian! I plan to post a number of comments here about the Thesaurus for discussion soon. I would be thrilled to have your feedback on those.

Hi Mark,

I was doing unrelated research in LCSH and remembered your post, so ran a quick search on "deity" in the Library of Congress Subject Headings. Without digging too deeply it appeared to be a fairly robust list including most appropriate language variations (Amida, Amitabha, Amitayus) as alternate terms. I am not aware of other comprehensive standards for deities (especially for Asian religions). You may try Asia Society in New York or Asian Art Museum in San Francisco. I worked with AAMSF years ago as a consultant for Questor. ARGUS relied heavily on its Lexicon Module, so there is a good chance that they incorporated a standard or custom structured list.

Search for Deity at LCSH http://id.loc.gov/search/?q=deity&page=5[/url]

All my best,

Will

Will Scott
Museum & Database Consulting
Philadelphia, PA / New York, NY

10-Aug-11 06:36:25
Which museums are using the Thesaurus regularly?
Forum: Thesaurus

I am interested to know which museums are using the Thesaurus Module regularly. I had a discussion with KE staff recently about the possibility of creating a SIG for this module. Would there be interest?

Thanks!

Will

Will Scott
Museum & Database Consulting
Philadelphia, PA / New York, NY

10-Aug-11 06:14:11
Internal 360 degree communication mechanisms
Category: EMu Administration
Forum: User Support

Hi Dave,

When Penn Museum launched, we had a lot of the same discussions. I set up a WordPress site for them to manage and make available most of the help-desk related content. FAQ items, how to documents, data standards, and KE training guides are all linked or presented on page as "blog" posts. By going with a well-known content management system, we ensure that site maintenance and updates will be simple to implement (even long after my contract ends). WP also has a large selection of plugins available that make it simple to add new features or to change the site. Perhaps best of all, the clean look and single search field (that covers every category) make finding information less daunting than sending an e-mail to the admin.

As part of ongoing training efforts, I re-purposed some basic mailing list code I had written for another project to create a very simple EMuTips mailer. Similar to what you mentioned, these are short notifications about features available in EMu. Their primary intention is to provide ongoing training and to further user satisfaction by communicating shortcuts and other helpful basic procedures on a weekly basis. Many of the items included were also covered at training sessions, but are likely to have been forgotten in the adjustment process. Copies of each tip are included in their own category of the WordPress site as well to make them searchable alongside other documentation. A similar offering could be handled rather easily by simply using e-mail of course. I set it in a database to provide some automation and simple tracking of what items have been sent and when. Tips do get sent more than once, intentionally, if nothing new has been added and if the specified amount of time has passed since the last mailing.

We looked at Help Desk systems for tracking requests, and may do so again in the future. I have used SysAid by Ilient for tracking help desk requests for my consulting work. I like their system, but it can be a bit much to set up and to maintain. It does offer full e-mail integration. Many of the simpler systems do not capture incoming e-mails or replies (they have to be copied in). SysAid is designed more for IT support than software support but works nicely for help desk request tracking. The options that we researched seemed like they would either require more work than they were worth or did not offer enough in terms of features to make them more useful than a Google Spreadsheet. We only have a few people who handle these requests, however, and we meet regularly. If you have a large number of staff responding to various requests, it might make good sense (assuming that they all search for an existing answer in the system prior to writing a new one). Even with that, however, I much prefer good core documentation that can be sent as a link in an e-mail to re-sending e-mail communication with another user.

For now, if I receive a question and think the answer may be useful to others in the future, I create a general  (and, ideally, comprehensive) reply that gets posted to the WordPress site either as a Procedure/How-To or a FAQ item. That can then be linked or copied in any future request for similar information.
All of my best wishes,

Will

Will Scott
Museum & Database Consulting
Philadelphia, PA / New York, NY

04-May-11 10:57:51
Querying for a list of specific Object Numbers could be easier
Forum: Catalogue

Thanks, Mark!

03-May-11 06:00:46
Querying for a list of specific Object Numbers could be easier
Forum: Catalogue

Often users receive hand-written, or digital lists of Object Numbers for use by a researcher, or in an exhibition or other project. To pull all of those records up in the same result set in EMu, a user must enter each into the query form on a separate line of the Object Number field and enclose each in the relevant operators (^"2009.1.1.B"$, for example) to ensure that only those specific Object Numbers are retrieved. Furthermore, only three to five rows of Object Numbers are visible at one time in the client, making difficult a review of the list for typos or other errors. I have created a spreadsheet template that automatically formats such a list with the needed operators for copying and pasting into EMu. That process is somewhat cumbersome, however.

Some other Collections Management Systems offer a "compile a list" feature to handle this task. That feature provides a separate interface that allows for viewing of a longer list of Object Numbers at one time (without scrolling) and that acts as a query interface for only Object Numbers. It also provide validation on those IDs, indicating to a user before running the query if any Object Number included does not exist in the database. If the number does exist, it displays summary data for that object in a second column. In EMu, it would, ideally, assume a strict, full-string, search on each ID as well so the addition of operators would not be required. The results would appear simply as query results that could be manipulated as any other query result set (items removed, selection saved to a Group, etc).

This task comes up quite frequently at museums where I have worked. A more efficient means of handling such lists, I think, would save users a good amount of time. I am curious to know if other museums and users in the forum would find it to be a useful feature as well.

Best wishes,

Will

Will Scott
Museum and Computer Consultant
Philadelphia, PA / New York, NY

19-Oct-10 05:22:42
Query Mode Options to Clear Query Form and Return to Previous Results
Category: Using EMu
Forum: Searching

Hi Gerard,

Thank you for your reply. I was not aware of those options. They will be useful. I had expected to find that feature in the toolbar based on the presence of similar buttons (previous search, new search) in Edit and New Record modes. So, I still think it would be intuitive to have this option in the toolbar.

Thanks, again!

Will

18-Oct-10 12:18:37
Query Mode Options to Clear Query Form and Return to Previous Results
Category: Using EMu
Forum: Searching

Presently, Search mode in all modules feels a bit like a dead end when looking at the toolbar menu. One has the ability only to run a query or to go to New Record mode. It is not possible, without going to New Record mode, to clear all search terms from the query form. I would like to propose two new toolbar options in query mode for all modules...

1. Clear Search or New Search. It can be useful, especially for complex queries with parameters entered on multiple tabs, to be able to simply click a button to clear the search form. That would make it possible for users to completely redefine a search without leaving query mode or having to go to New Record mode to get a fresh start.

2. Return to previously retrieved results. If the last view was of query results, allow users to click a toolbar button to go back to viewing those. That would allow users to change their minds if they decide that those were actually the desired results after going to query mode or to go back to be reminded of data from those results for query revision. Ideally, this would not require rerunning the query or records retrieval as those can, in some cases, take a good amount of time.

I would love to know thoughts from other users on this topic. I still consider myself fairly new to EMu, but have seen similar features used regularly by all levels of user in other collections management software.

Best wishes,

Will

Will Scott
Museum Database Consultant
New York, NY / Philadelphia, PA

Thank you for posting this topic, Janeen. The default configuration for Catalogue attachment of Bibliography records seems to include the citation and nothing else. A number of clients that I have reviewed include, as you do, a Reference Type, Pages and Notes field. These seemed to be customizations and not defaults. If those fields are not presently standard in EMu for References Tabs/Field Sets, they should be, in my opinion. The additional fields clearly specify an object's relationship to a publication and allow users to view the exact relationships of objects in the collection to a specific text/publication. Furthermore, they will help a great deal with ARGUS conversions, as ARGUS includes the same fields for describing a link to bibliography data.

Thank you for your reply, Mark. UPMAA added Type and Notes fields on the Multimedia Tab of the Catalogue Module (and a few other Modules) that will handle the Type of relationship and additional remarks. I would like to propose that object-side typing of Multimedia be made standard in all EMu modules.

Is this affecting other institutions? Please add a comment or drop me a line directly if so. I would be interested in developing a detailed specification with other clients to propose to KE.

This issue came again to mind at the User Group meetings in MN last week. Dave Smith at Natural History London presented some of their uses of the Narratives Module, including a video project documenting the knowledge of many retiring staff members. It was an oral history of the museum, on one hand, and collections documentation on the other. Such video interviews and collections storage walk-throughs could be related to a number of objects and events (even loans, collection events, and accession lots). It would not make sense to edit the video to include a copy of each part discussing each object/event—it disrupts the narrative and is time-consuming. It would make sense to related objects and events to the video noting that Object A is referenced and Object B is discussed at length, and Event A (the curatorial video project) is related as a "result", and Event B (a past exhibition) is related as "referenced in." For that to be possible, multiple relationships need to be recordable for a single Multimedia object from any Module.

A simpler example is an installation photograph from an exhibition. It may be linked to the exhibition Event as "installation photo" and to various other objects included in the photograph with a different relationship (perhaps, “featured in group photo” or “in installation photo”). Furthermore, one object in the installation photo may be a loan object (Loan A) that could be useful in comparison to a permanent collections object (Object F), creating a “similar object” relationship between Object F and the image that includes Loan A.

I am being fairly loose with defining relationship types between Modules and Multimedia. I think that they should be fairly open and dynamic, however, and defined by institutional needs. The inability to specify attachment-side relationships leads to duplication of, perhaps the most resource-hungry type of collections data, multimedia. Although EMu is fast, and memory cheap, one should, be able to view a single Multimedia object and see how it relates to various other records in the database. The present EMu configuration does not allow for that.

As I mentioned in the original post, one of the driving forces behind this request was having the ability to determine which Multimedia objects to publish online for which records. MM A may be publishable for Object A, but not for Object B, even though MM A is related to both in EMu. It might be worthwhile to develop this even further to include web publishing options on the tabs to which Multimedia records are attached, in addition to defining the type of relationship. That would allow clients to decide manually (or by defaults) which Multimedia records to publish to the web for which objects distinct from the type of relationship. Object C may have a relation to Photo A (a group image of multiple objects) of "featured in group." Object D may have the same relationship to the same Photo A, but is less prominent in the photograph as compared to Object C. The museum wishes to publish the group photo for Object C, where the object features prominently, but not for Object D, where the object is present, but obscured. Separating the type of relationship from the internet publication setting for Multi-media objects would allow that situation to be handled without the creation of confusing duplicate Multimedia records.

That leads me to another proposal that applies to Multimedia and to EMu overall. EMu’s built-in web controls allow only a toggle—publish to web or do not publish to web—for any record. I will post this in more detail to the appropriate section of this forum, but it merits mentions in the context of Multimedia typing and web publication.

For many museums, it may be possible to make a binary decision about web publication—share it with the public or do not share it with the public. I suspect, however, that many museums are looking to publish various levels of information for access by different kinds of users. I work quite a bit with university museums, UPMAA included. End-user categories for intranet/internet publication for a university museum include not just the public, but also students, faculty, and researchers. The museum may wish to publish a larger, but less-complete, set of data to university users than to the general public. Researchers may be given access to a different set of records, more complete than the public records, via registration and login. University and non-university museums, both, may require publication categories such as general public, researchers, and educators (K-12 and university-level), internal kiosk, etc. Furthermore, special projects may require a subset of data to be published that is geared toward 3rd grade teachers, in particular.

EMu does not seem to include this sort of intranet/internet-access control in default configurations. (I know of at least two museums that are paying for more detailed controls designed in-house as customizations). Things could certainly get out of hand trying to accommodate each institutions specific needs in this area. But I think that there may be a middle ground.
In its simplest implementation, this may include 1-n levels of intranet/internet publication that could be defined by the client via a dropdown. In that scenario, users could set objects to be published to the public (www), researchers (www with approved registration), intranet (university), intranet (museum), etc. Any number of categories could be set by adding terms to the dropdown field controlling the levels of access. Clients would be largely responsible for handling which records are presenting to end users based on that field. KE may also include the field as part of its PHP Web Toolkit so clients would not have to throw broad IFs in front of the KE code.

A more complicated option would be an altered copy of the EMu Security controls that limit in-house access to records, tabs, and fields. That would allow a greater level of control. Publication of records would be based on end-user “groups” or categories.

I am interested to hear from other users how they are publishing different information to different sites and how they think EMu’s default publication options might better accommodate their needs. I would be glad to collaborate on a proposed specification for improving publication options, as well, if other clients are interested.

EMu's Locations Module does not, at present, seem to have a way of recording the Load Capacity of a storage unit. Users at UPMAA requested this addition for specific collections storage and move projects. It would not be used, realistically, for all collections and storage units, but would be quite handy for some.

The Dimensions Tab has a field group, "Characteristics," that contains fields for Weight in kg and lbs, but that seems to apply to the weight of the storage unit, not to the amount of weight a unit can hold. Is anyone using that field group to handle Load Capacity?

Are other users/clients interested in having "Load Capacity" added as a standard field group to this module? It would, by my specifications, contain two fields, weight in kg and lbs.

Will

Will Scott
Museum and Computer Consultant
Brooklyn, NY

EMu’s built-in web controls allow only a toggle—publish to web or do not publish to web—for any record. For many museums, it may be possible to make a binary decision about web publication—share it with the public or do not share it with the public. I suspect, however, that many museums are looking to publish various levels of information for access by different kinds of users. I work quite a bit with university museums, UPMAA included. End-user categories for intranet/internet publication for a university museum include not just the public, but also students, faculty, and researchers. The museum may wish to publish a larger, but less-complete, set of data to university users than to the general public. Researchers may be given access to a different set of records, more complete than the public records, via registration and login. University and non-university museums, both, may require publication categories such as general public, researchers, and educators (K-12 and university-level), internal kiosk, etc. Furthermore, special projects may require a subset of data to be published that is geared specifically toward 3rd grade teachers, for example.

EMu does not seem to include this sort of intranet/internet-access control in default configurations. (I know of at least two museums that are paying for more detailed controls designed in-house as customizations). Things could certainly get out of hand trying to accommodate each institutions specific needs in this area. But I think that there may be a middle ground.

In its simplest implementation, this may include 1-n levels of intranet/internet publication that could be defined by the client via a dropdown. In that scenario, users could set objects to be published to the public (www), researchers (www with approved registration), intranet (university), intranet (museum), etc. Any number of categories could be set by adding terms to the dropdown field controlling the levels of access. Clients would be largely responsible for handling which records are presenting to end users based on that field. KE may also include the field as part of its PHP Web Toolkit so clients would not have to throw broad IFs in front of the KE code.

A more complicated option would be an altered copy of the EMu Security controls that limit in-house access to records, tabs, and fields. That would allow an even greater level of control. Publication of records would be based on end-user “groups” or categories.

I am interested to hear from other users how they are publishing different information to different sites and how they think EMu’s default publication options might better accommodate their needs. I would be glad to collaborate on a proposed specification for improving publication options, as well, if other clients are interested.

Thanks and best wishes,

Will

Will Scott
Museum and Computer Consultant (presently working with UPMAA)
Brooklyn, NY

To begin with an example, consider that a museum has a video about an object (A) that mentions, only briefly, another collections object (B). The museum would like the video to be linked to both objects in the database, but in different ways. Perhaps the relationship for object A would be called "About" and the relationship to object B would be "Referenced In". Presently, both relationships or types can be added to the MM module, but it cannot show which Type/Relationship applies to which object. Separate MM tabs could be used in the Catalogue Module to determine the type of relationship (perhaps one Tab for "About" and one for "Referenced In", etc.), but that seems costly and confusing.

Furthermore, the museum wishes to publish the video to the internet for object A, but not for object B (because the video is not relevant enough to object B to merit linking/embedding of the video in object B's online record). To accomplish that in the current model, it seems two copies of the video would need to be created allowing one to be linked to A and publishable, and the other linked to B and not publishable.

While type, relationship, and web status (security) can be set in the MM module, there does not seem to be a way to record various types, relationships, and web statuses for many objects in relation to a single MM record. Either separate MM Tabs/Fields would need to be created in Catalogue to specify type/relationship and web status or multiple instances of the same MM item would need to be added to show the different relationships to different objects. Both solutions seem to involve a duplication of effort and/or data that is time consuming and potentially detrimental to data integrity. Would it not be better to have the ability to describe the relationship rather than just the object or MM item?

I wonder if anyone has dealt with, or come up with a solution for, describing these various relationships between Catalogue and Multimedia records. Recommendations using the default model and those requiring customization would both be quite helpful.

Many thanks!

Will

Will Scott
Museum and Computer Consultant
willscottconsulting@yahoo.com

I would like to know if any other EMu users see a need for a feature in EMu's Relocate Tool that would provide the ability to automatically return objects to their permanent locations. I am presently working with an ARGUS conversion client moving to EMu. Users had relied heavily on that feature in ARGUS; and the museum uses permanent locations consistently.

The idea would be that users could select "return objects to their permanent locations" in the Relocate Tool, then be given a list of the objects' Permanent locations to make any ad-hoc changes (accounting for exceptions in the list--perhaps, one object went to Conservation).

Would that be useful to you other EMu users?

Thanks!

Will

Will Scott
Museum and Computer Consultant

06-Dec-08 11:00:00
Category: EMu Administration

Realizing that this conversation is a couple of years old, thanks Nick for posting the MS Project plan. For future readers who may not own Project, you can open MS Project documents for review in Open Project, an open source project management solution.

It is available for free at:

http://openproj.org/

Will Scott
Museum and Database Consultant

  • Index
  • » Users
  • » WillScott
  • » Profile

Board Info

Board Stats
 
Total Topics:
601
Total Polls:
0
Total Posts:
1362
Posts today:
2
User Info
 
Total Users:
816
Newest User:
Gregory Brown
Members Online:
2
Guests Online:
179