orienteering for libraries: taking a practice trip: three problems: three solutions

Kathryn:

Hello, everyone. My name is Kathryn Harnish, principal at Leap Forward Library Consulting, and it’s my pleasure to welcome you to Taking a Practice Trip: Three Problems, Three Solutions, Use Case 1, the third Webinar in our Orienteering for Libraries & Librarians series.

As Nannette and I worked through the three use cases that demonstrate the power of the PraXis transformation engine, we came to a very clear conclusion — we have A LOT of content to share in this final presentation. There’s so much content, in fact, that we became concerned about giving the use cases short shrift by squeezing them into an hour-long session.

As a result, we’ve altered our approach to this Webinar. Rather than hosting a live session, as originally planned, we’ve broken the content up into two Webinars, an introduction to the use cases and this session, a walk-through of the first use case on Metadata Aggregation & Enrichment. And we’ll address the second two use cases, on Library as Publisher and E-resource Optimization, via white papers to be published by the end of the year, as we feel that this is the most effective way to share what is fairly complex information about these topics.

All of these materials will be posted to the IMT Website, under the Resources menu option, along with a copy of the slide deck and speaker’s notes for the first two sessions. As always, we invite questions and comments via the Talk to Us link, also on the IMT site.

Friday, December 4, 2015 Taking a Practice Trip: Use Case #1

©2015 by Information Management Team, Inc.® and Leap Forward Library Consulting™

http://imteaminc.com/resources-2/orienteering-resources/

http://imteaminc.com/resources-2/

http://imteaminc.com/talk-to-us/

Kathryn:

So, let’s kick things off with a quick round of introductions. (http://imteaminc.com/ about-

us/our-people/)

I’m joined today by my colleagues from Information Management Team —Nannette Naught, principal at IMT, and Cathy Sackmann, lead analyst.

Together we’re working on solutions to help libraries ensure ongoing visibility and viability in a Web-based world.

Nannette and Cathy bring extensive experience with product and content development, architecture, ontology, and modeling services for publishers, libraries, and their partners (http://imteaminc.com/our-story/), while I’ve spent the past 18 years in various ILS product management positions at ProQuest, OCLC, and Ex Libris. (http://www.leapforwardlibraryconsulting.com/about-me/)



Kathryn:

Let’s pickup, where the PraXis Use Case Introduction ended, with my call to Nannette to lead us through some real examples of live, working software, built with a micro-services approach, that helps libraries move forward in:

• Productive ways

• Ways that facilitate discoverability, cost control, and collaboration.

So, Nannette, Let’s Go!



http://imteaminc.com/wp-content/uploads/2015/12/TakingPracticeTripThreeProblemsThreeSolutionsIntroduction_11_2015FINAL.pdf

Nannette:

Yes, Kathryn. Let’s go! Let’s explore how PraXis helps us:• Increase Discoverability — By grabbing our appropriately packed bag,

(just the tools we need now, and nothing extra) and meeting our users where they are. (Introduction pages 15 & 16)

• Decrease Costs — By staying on the trail and guiding our data down the paths that make sense for our business cases, our individual businesses cases. (Introduction pages 17 & 18)

• Change the Way We Collaborate, not to mention with whom we collaborate — By booting up in a stylish, well supported pair of Mucks and wading into the deep waters of stewardship. (Introduction pages 18 & 19)

How, you ask? It’s simple really. Start with Commonality — or the need common to all three mandates:

Metadata Aggregation and Enrichment — PraXis Use Case 1.







Nannette:

So let’s Aggregate Metadata, rather than continue the time and cost-intensive Recreate Metadata cycle of our current cataloging and description workflows, as we discussed in detail in Orienteering for Libraries: Session 2: Definitions.

Orienteering for Libraries: Grounding Our Adventure, slide 30, available at http://imteaminc.com/wp-

content/uploads/2015/11/2015_11_10GroundingOurAdventureDefinitionalAlignment.pdf)



Nannette:

And then, let’s enhance — or to use Kathryn‘s wording from the introduction, let’s context manage for both intellectual and use contexts. (Introduction page 10)

Let’s, as shown here using my family’s extensive boot collection:• Group like Things, say by color, against a predefined classification

scheme. (Things Reference: Definitions behind PraXis page 10)

Pinks: Pink and Brown→ Pink and Black→ And the interplay of them all, as they are connected in a full circle here.

Reds: Red ← Red & Turquoise → Turquoise





http://imteaminc.com/wp-content/uploads/2015/11/Definitions_11_9_15.pdf


Nannette:

Let’s, as shown here, again using my family’s extensive boot collection:• Classify by Type or subject, against defined schemes and ontologies with or

without sub-classifications, synonyms, and related terms.

To return to those boots:→ Dress boots, Everyday boots, Casual boots

→ Favorite boots, Dorothy boots

→ Creation Technique for the boots: Stitched:

Hand stitched

Machine stitched

Extruded (or related term Molded)



Nannette:→ Leather:

Plain — Though really it is possible to go deeper here (e.g., Bull, Calf, Kid, etc.), in specialist areas, as determined by those individual business case(s) and community(s) served, as Kathryn talked about in the Introduction Plain.

For the purposes of our example, though, I’ve chosen cost as key factor in the business case, so this level of detail isn’t needed. As it adds cost without returning significant benefit to the bulk of communities served and minimal, perhaps negative, ROI — few think about these added distinctions as part of their decision making process, And worse, the added complexity may confuse and delay the decision-making process for many, sometimes causing them to walk away and choose another, “thinks more like me” discovery and delivery service.

Exotics — Big cost factor for all and visible difference most remember (like color or bindery of a book), so it meets my business case to include these added subdivisions, including:

Python

Lizard

Ostrich — With available further sub-classifications of Body (synonym: Quill)and Leg (synonym: No Quill). Again, big cost factors and visible key differences users care about and will want as options in their boot discovery and delivery experience.



Nannette:

Notice: This is a bit different approach than many current workflows. We are allowing varying levels of granularity in our enhanced boot data based on our business case to:

• Control Costs — By not blanket, “just in case” or “just because our standard says to” enhancing all data equally.

and

• Increase Discoverability — By meeting the needs of both those novice users and advanced users Kathryn described in the Introduction, thereby decreasing the chance they will “go around” our discovery platforms to find the answers, and boots, they desire.

Further, as we’ll see in the working example, with PraXis we are enabling business managers, those who understand both existing and future business processes, to push or publish this enhanced data to those “go around” platforms, without significantly increased costs, should they feel their individual business case(s)warrant it.




Nannette:

Let’s continue to enhance then with:• Tag for Intended Use (i.e., a good place to begin bridging the gap between

intellectual and use context) against defined controlled vocabularies that allow us to:

• Establish relationships between Classifications and Intended Use,

• Accommodate overlap and multiple uses, perhaps with percentage ranking and audience sensitivity, as we are seeing both:

Google with its knowledge vault work, and

OCLC with its linked data experiments (RDA, Linked Data, & BIBFRAME, Eric Childress, October 21, 2015, slide 45 (http://www.infodocket.com/ 2015/11/ 07/two-

presentations-about-metadata-and-linked-data-from-members-of-oclc-research/)

are doing now.

Let’s return to our boots example to explore this in a bit more detail: Riding — With or without the modifier of Spurs. Note: Spurs, a related Thingcould have classifications of its own, outside those shown for the boots. Sound like linked data? But I digress into best practice, and that is a topic for another day. For more on modifier vocabularies, see RDA Registry and Product Synchronization Analysis, page 5.




http://imteaminc.com/wp-content/uploads/2015/11/RDARegistryandProductSynchronizationAnalysis_4_2014.pdf


Nannette:Walking — Which if you are part of the right population (e.g., country), could also have a second use of Dancing. Pink camo boots are high fashion this year at local dance halls here.

Hiking — A third use of those pink camo shoes, if you don’t need ankle protection. These are Merrill’s after all! And with Identity Management in place, we can easily follow a link to Corporate Body that produced these boots and its area(s) of focus or specialization to discover more. But again, I digress to related things and though we will hit on it in the working example in a moment, this too is a topic for another day…

Dancing — Which for many audiences could easily overlap with Speaking.

Speaking — Which itself can overlap with Dancing in certain, but not all, instances. You probably wouldn’t want to wear sequined heels to speak at a professional conference. I want to point out here too, Speaking, as we’ll see in a moment, has some very specific related Subject classifications, as well. Intended Use often overlaps with other ontologies, related uses, and even intended audiences. But I am getting ahead of myself.

Let’s close out this by talking a bit about our last set of intended uses in this set of boots…




Nannette:Puddle Jumping — Which in cold climates, like mine up north, has a synonym of Wading. Not to mention a few more mundane, but common uses such as:

• Mucking out stalls — And isn’t that how this brand got it’s name after all?

• And in certain vocal, profitable (and I did say, cost was my primary business case factor in this example) audiences like Show folks, Washing Show Animals.

They keep your show pants dry on show day for those touch-ups before you head into the ring. Not to mention, make a fashion statement meant to intimidate your competitors about how much you are willing to spend on your show clothes. Nothing says you’re the real deal after all, like professional, first class tools!

We’d do well to remember both practical and status uses in our intended uses. After all, no researcher wants to use a K12 tool to get his job done. As any boot or car designer can tell you. form and function matter more than we might like to think. But I digress.



Nannette:

Let’s complete our enhancements then with:• Relate to Audience, perhaps with relationships between Groupings, Uses (like those

Puddle Jumpers), and Audiences —

And let’s look at my boot collection again, to explore the:• Style of vocabularies we need here. Vocabularies like:

Men

Women

Either — Contextual synonym here Both with related term Gender Neutral.

Vocabularies that overlap Person characteristic vocabularies that we, or better yet the individuals themselves, use to identify an individual as part of specific audience.

And yes, we could spend a lot of time, arguing the academic minutia of my term choices, but what real value in system advantage will that afford us?

• Display labels of preferred synonym — which, if we are honest, change with an uncomfortable frequency not just across audience, but within audiences over time —are easily and cost-effectively added and adjusted as appropriate to our business case in the micro-service interfaces, not the data, in PraXis.

• Added granularity or subdivisions as appropriate, individual business cases of those serving specific populations who need them are easily accommodated by the technology (federated architecture with micro-services) and part of that new type of collaboration Kathryn discussed in the Introduction.







Nannette:

• Context of vocabularies we need. Do we need to extend context to other types of users, perhaps even nonhuman users like horses? Would extending our Intended Audience and/or Intended Use vocabularies to nonhuman Things increase our visibility, ease of use, and utility in a way that positively impacts our viability? (Definitions behind PraXis pages 2 & 7)

Remember, I did say cost was the key business factor in my examples here. Let’s go back to our boots one last time and consider the possibility for a moment, using my Intended Use vocabulary from earlier.

Riding — Which in the case of horse population, unlike a human audience, almost always overlaps Walking. Though for specific Specialties would include sub-classifications like Loping, and extended related Uses like Reining. — And yes, in this population, if horses or their owners are a key community, the cost factors of increased classification depth are outweighed by the service advantages which increase visibility and viability in important ways with a key audience.

Hiking

Walking

Puddle Jumping

Treatment — Which in the case of horses, often is served by the Puddle Jumping boots, and often overlaps with the Removable shoe category






Nannette:

But, enough with the boots already, Nannette, let’s get to Library specifically and out of the analogies!

OK, but humor me for just a couple more slides. I promise I am relating it directly to Library and PraXis itself, starting right now. After all, those:

• Groupings of like Things against Predefined Classification Schemes — This sounds familiar, doesn’t it?

• Hierarchical, jointed, and full circle, with cross references that bridge or relate categories, like colors, that at first glance seem unconnected.

• Aren’t these just Browse trees with interconnects — like LCSH and Dewey. Some browse trees like Dewey straddle the boundary between Classification Scheme and Subject Ontology (as discussed briefly in Orienteering for Libraries: Session 1: Landscape survey

http://imteaminc.com/wp-

content/uploads/2015/10/2015_10_27SurveyingTheTerrainUnfamilarLandscapes.pdf, slide 53).

• Classifications by Type against Defined Ontologies — This, too, sounds somewhat familiar, doesn’t it? Especially to those metadata specialists amongst us who regularly classify with subject- or discipline-specific ontologies, often outside the cataloging interface in an XML or web tool, like Oxygen or Dreamweaver.

• True, fully documented, serialized ontologies that interrelate knowledge objects and their various parts in any number of ways, with both inheritance and containment hierarchies co-existing peacefully. Not just simple hierarchies of labels and tags with a few "see" and "see also's".



Nannette:• To me, a least, it feels like The MeSHes of the world, where

Discipline = Medicine and its sub-disciplines and related disciplines such as Insurance] Note: For more on MeSH and its connection to Intended Use in action, see Use Case 3: eResource Optimization

The Planning's of the world, where Discipline = Urban Planning and its related sciences of Architecture, GIS, Engineering (in its applicable variants such as Civil, Mechanical, Electrical, etc.), and Law (related term, Policy). But we’ll get to this in the working example in a few minutes.

The Places, of the world as Subjects, which though related to, are not necessarily actual GPSable locations. But we’ll discuss all this, in more detail, for those interested, in the Subjects supplement posted to the IMT website with these slide notes.

And all of these, like Dorothy Boots in this picture (the turquois and red ones in the center) with relationships to Intended Use — all of these point to a new type of Context Management metadata entry, something unlike the “metadata record” we are so familiar with.




Nannette:

Perhaps a display or edit interface like this.

And yes, this is perhaps: Oversimplified — More display than “data driven” — Not “standardized”!

But my purpose here, is to show you what can be, what is in a micro-service with a federated infrastructure system, today not tomorrow. And how different it is, from what we think of as library metadata records, not to mention what we see as records in monolithic system’s tightly constrained interfaces.

So let’s notice a couple things here:1. This is kind of cool. I, for one, would like to use this. It’s certainly better than what I

see on the Web in Google (or any search tool for that matter) and in today’s OPACs and Discovery interfaces.

It gives me just what I need — in ways I can easily understand — with easy-to-understand headings. And It’s simple and quick — both to use and to create.

WOW, any business person can tell you that double punch is a quick ticket to ROI. Not to mention customer loyalty! Decrease the time it takes your users to do their jobs, make them jump through fewer hoops, and BAM the “threat of Google” fades into the background very quickly. Viability is often easily achieved by providing your users with the purpose-driven tools that help them do their jobs better! In short, it’s a win-win.



Nannette:

2. This is informative. I find it helpful to see where the:Data — here in Courier — is coming straight from the data.

Display Labels — here in grey Sans Serif — have been added to help users absorb and interpret the information more readily. And I really don’t care whether these labels are explicit data field names or display labels (like those preferred synonyms for specific populations as justified by our business cases we discussed earlier). My only concern is that they are helpful and speak a language I intuitively understand. I simply want them to “think like me”.

Links — here displaying as they do in Word and the other tools I use daily to do my job — are present, sometimes with floating resource type labels that help me quickly determine which resource I want before I take the time, or if I am on my phone waste the data points, to follow the link. Just what I need to do my job better without wasting time learning new tools.

But back to those last two enhancements briefly, before we jump into PraXis’ micro-service interfaces with both feet.



Nannette:Intended Use Tagged against Defined Controlled Vocabularies — And let’s simply note, when judged against:

• Our current cataloging and description practices.

and

• All those connections between Uses, Audiences, Classifications, and Subjects we talked about earlier, as key facets of Context Management, with the boots,

We’re not sure what we’re looking at with respect to Intended Use in Library metadata at the moment. And we suspect Libraries don’t do this well in their data. Rather, they do this in person, at the Reference Desk — Using people to do what computers should do, thereby decreasing ROI and increasing costs due to a data gap. (Introduction page 18)

And we wonder, “Can PraXis can help us bridge the gap?" We’ll look at this in a bit more detail in those micro-services interfaces in a minute.






Nannette:

Intended Audience Tagged against Defined Controlled Vocabularies with Relationships between Groups, Uses, and Audiences — And let’s note that while the concept matches the spirit of RDA Intended Audience,

• Its current implementation isn’t an ideal match to the need here.

• Its defined, controlled, publically available vocabularies feel insufficient to the successful accomplishment of tasks we talked about in the boots examples.

• Its model, at the moment at least, seems poorly matched to actual, immediate library business cases like the one:

I heard outlined last year at Charleston by a Denver library administrator who described, in detail, how her library now serves a 4 year institution with several doctorate programs, area community colleges, and the public at large. Her library needs to:

• Not Only make Discovery easier for all the populations it supports (not to mention address the current Discovery platform problems Kathryn mentioned earlier), (Introduction page 16)

• But Also Promote collections and authors/researchers across Denver’s publically funded institutions to show the positive, measurable statistics necessary to ensure continued funding and demonstrate good stewardship. (For more about how funding connects to PraXis definition of Libraries, see Orienteering for Libraries: Definitional Alignment, slides, 37 to 41.)



http://imteaminc.com/wp-content/uploads/2015/11/2015_11_10GroundingOurAdventureDefinitionalAlignment.pdf



Nannette:

I experienced this in detail with the American Planning Association, as we will see in a minute. This association publisher needed to:

• Not Only make Discovery of its individual resources and product lines easier on its website, in its catalog and shopping cart, and for its distributors and collectors (such as Libraries).

• But Also Promote unpaid and resale visibility of its publications to extended audiences outside the association itself (e.g., NIMBYs, the public at large, elected officials, etc.), to show the positive, measureable statistics necessary to ensure continued funding from members, sponsors, and the board. Not to mention achieve its overarching mission of good Planning discipline stewardship.



Nannette:But before we dive into PraXis’ — Federated infrastructure that supports Aggregation and Micro-services which enable Enhancement — as implemented for the American Planning Association in 2012, let’s take just a moment to acknowledge, PraXis at APA is more than just Library Use Case 1: Aggregation and Enrichment. At APA, PraXis was:

• Executed as part of the Resource development lifecycle — It was and is integrated into this Association Publisher’s content development and aggregation cycle (as we will see in more detail in Use Case 2: Library as Publisher Support and Use Case 3: eResource Optimization). Thus, all metadata was created before release of the Resource(s) for sale and/or distribution to libraries, or any customers for that matter.

• Integrated into the Resource itself, against the same backbone as the content —Traveling with the content, as part of the Resource, from inception to final distribution — Being added to, edited, and enhanced throughout the content lifecycle, as appropriate to individual product line and organizational unit business cases. As we will see in a bit more detail in a few minutes.

• Designed for Use by non-librarians — Guided by a librarian superuser and library standards; trained to the task at hand, not necessarily the entire scheme, with minimal theory and/or technology training — to create library, publisher, and internal organizational metadata (e.g., membership and accounting system metadata, sales and shopping cart metadata, CE metadata, etc.). As with some library business cases, connection to other institutional systems was vital to long-term success. Standing alone as the only nonintegrated business unit due to silo-specific computer systems was not an option. Nor was filling in the gap with expensive human interventions.






Nannette:

For more about the APA Project, see:• Taxonomy 101: Finalizing Our Trip. A glimpse into the project plan,

timelines, and objectives. (http://imteaminc.com/wp-

content/uploads/2015/11/Taxonomy101.pdf)

• Taxonomy 201: Things Get Real. A glimpse into the implementation itself, staff training, and setup. (http://imteaminc.com/wp-

content/uploads/2015/11/TamingTaxonomy_Summer2012a.pdf)

For our purposes though, let’s begin with a quick look at that backbone.



Nannette:

A backbone that supports aggregation or the:Collection of Metadata,

of Various Kinds, Modeled in a Variety of Ways —or as sometimes desparagingly referred to in literature as Chaos Curation

Against a Federated Infrastructure — or as we fondly refer to it here at IMT, the "meaning machine", the code-cracking backbone that drives all those micro-services we keep talking about.

Seen here as a snapshot from the serialization’s documentation, for APA’s Resources this means:• Bibliographic Metadata. Probably self-explanatory to this audience. However, as we

will see in the micro-service interfaces in a minute, with good, ROI-driven reasoning, not a 100% match to MARC, AACR2, RDA, BIBFRAME, or any given cataloging template. Remember our business case-driven caveats:

For APA: Execute as part of Resource lifecycle. Integrate into Resource itself. Design for efficient, accurate use by all.

For Library: Support individual library business cases, including appropriate, cost effective delivery of needed services to key audiences.

• Authority, or more accurately Identity, Metadata. Which we’ll see in the micro-service interface, goes beyond traditional library authority metadata. Again, remember those caveats, this data exists prior to collection and library cataloging.

(Definitions behind PraXis pages 3 & 4)





Nannette:

• Subject, or more accurately classification scheme and discipline-specific ontology Metadata, as we will see in detail in the micro-service interfaces.

• Transaction, or more accurately Sales and Distribution Metadata. And I will note here there is some overlap between Bib and Transaction metadata. The distinction is drawn not along overlap between Publisher and Library metadata (e.g., ONIX vs MARC or BIBFRAME), but rather along workflow or lines of business. If it’s done in Editorial, it’s Bib; if it’s done in Marketing, it’s Transaction.



Nannette:

Dangerous overlap? Arbitrary distinctions? Perhaps to a purist. BUT, to a business person, not arbitrary at all. It makes perfect sense. Follow the money — Base distinctions on:

• Decision-making authority,

• Defined responsibilities, and

• Existent, measured performance areas, and

BAM!…ROI and accuracy automatically follow! And when they don’t…You have clear lines of accountability and rules for enforcement, no new policies required.

But Nannette, what about the technical point of view? Doesn’t machine-readable data mean, I, the human, have to do it like the computer wants it done, or else?Don’t my business processes have to conform to their constraints, rather than vice versa, as you seem to be advocating?

Well, Yes, perhaps, in those pre-SOA or service-orientated architectures Kathryn

mentioned in the Introduction. Those architectures in which our current, even next generation, systems unfortunately live. (Introduction pages 8 & 9)






Nannette:

But we’re not forced to eat cold Spaghettios out of the can. So,No, not in a bridge environment like PraXis with its federated infrastructure and micro-services approach. Like those cupcakes Kathryn mentioned in the Introduction, this approach affords libraries, and publishers, or anyone in the Resource Management lifecycle for that matter, the flexibility to:

• Customize to local needs without triggering a cascade of unintended consequences on the backend.

• Use audience-specific definitions, display labels, and formats as we saw in my Context Management display a few slides back, without disturbing the pie slices.

OK, so what’s the catch, Nannette? There’s always a catch, after all.

Well, I guess, the catch is Definitions. • All Things, intellectual, physical, or otherwise. All terms, vocabularies, and objects used

have to be defined, and defined in a usable, intelligible way, as we discussed in some detail in Orienteering for Libraries, Session 2: Definitional Alignment. And frankly, Library standards, at the moment, are lacking more than a few definitions, as we’ve mentioned previously. (Definitions behind PraXis page 7)

and

• All Definitions in all their versions (both audience and edit version), in all their translations with all their terms, with all their labels, with all their synonyms, and with all their related terms must be uniquely ID’d and interconnected. (See RDA Analysis for more detail.)





http://imteaminc.com/wp-content/uploads/2015/11/2015_11_10GroundingOurAdventureDefinitionalAlignment.pdf




Nannette:

So, in other words, Nannette, this is the justification for linked data? We at PraXis think so, yes!



Nannette:

And this is why Identity Management is so vital? (Definitions behind PraXis pages 4, 2, & 6)

Again, we at PraXis think so, yes! It’s the basis for library’s functional services groupings: (Introduction pages 9 through 13)

• Context Management.

• Rights Management.

• Inventory Management.

And, more to the point, all this is what we at IMT, have been working on for years, inside and outside, content; inside and outside Library. We work to see that our backbone, the PraXis Swiss Army knife, now and into the future, enables all these services and more.

For more technical detail on how we do this, this time laid out against the RDA project, see RDA Registry and Product Synchronization Analysis.

Prefer to walk through it one-on-one, with the opportunity to discuss your library’s pain points, and how PraXis fits your business case? Contact us for a "virtual coffee" walk-through or an in person chat at MidWinter in Boston. We would love to show you our work against your business case in full detail!













Nannette:

Now, let’s get off the backbone and look at those micro-services directly. Let’s get down to the cupcakes! They’re more fun and easier to understand. They’re the parts:

• All of us, even the non-code geeks among us, can touch.

• Allow us all, regardless of place on the team — technologist, cataloguer, manager, business person, work study student — to speak the same language.

So let’s use the Create Aggregated Metadata micro-service to explore this collected metadata in a bit more detail.



Nannette:

Notice, the Template starts with Resource Type. Why? Simple Workflow and ROI again!

Based on type selected, the template turns on and off, programmatically, automatically based on the organization’s, product’s, or business line’s policy :

Required• The fields or data points your record for this type of Resource will not be

valid for, if it does not include.

• Those fields APA’s internal policies will not let you Submit the metadata record for review without. Yes, as we will get to in a few slides, the idiot box is in place (unless you are one of the select superuser few who know the override code).

Why? Easy! ROI again. Get what you need, when you need it, from the person who has it. It’s that business person from a few slides back that was so happy to avoid having Spaghettios on her face.

Optional but desired or ideal, if you have time and ability to add.

Not applicable. Don’t spend time entering. Values are not allowed in these fields.



Nannette:

Thus, no collecting and deciding among Core or Optional, or Exception and the like. After all, aren’t these decisions usually made:

• By the administrating librarian,

• With tech staff input of what system needs to run well,

• BEFORE any actual creation or aggregation is done?

Why waste the time having staff consult other resources, remake decisions, or generally be confused? Why not automate?

It’s cheaper, faster, and less error prone. It’s, as Kathryn said in the Introductionand we reiterated earlier in our examples, letting the computer do what it does best; thereby freeing the people to do what only they can do.




Nannette:

Notice, Mix of Types in the drop down. Yes, we have:• Parts and wholes — aka books, chapters, appendices, in there.

• Non-like things — aka books and journals, in there,

• New content and collections (both collected and derivative) — aka book and handbook (as we will talk about a bit later in more detail), in there,

• A mess in there — if we are judging this by cataloging rules!

BUT, we aren’t judging this by cataloging rules, remember this is the micro-service, not the backbone. It is judged against ROI and workflow — business case, as we keep saying.

It is purposely designed for speed, accuracy, quality, and appropriate levels of cost and human intervention. Things can and are mixed herein to achieve these goals. Things that are easily handled in the backbone against the specified standard. Things that computers do better than people (i.e., control against a defined, serialized list, no decisions “thinking”, only mathematical mapping needed). Things that when done to serve the computer in the human interface, confuse and cause the human to make mistakes.



Nannette:

Notice, Built-in, toggle to and from Help.

Does this help screen, or the contents of it at least, look familiar?

Policy statements at the point of creation, correction, collection, anyone? Policy statements without the overhead of programming into the forms of your monolithic system or creating as stand alones?



Nannette:

And yes, you can even link to subscribed to resources and online tools like Toolkit and Cataloguer’s Desktop. Use the extension to manage who gets access to your subscription’s open seats (and when), against your own business case.



Nannette:

Think about, • Where could you take functionality like this, not just in the short-term, small

space of a metadata enhancement micro-service, but in a Discovery or Delivery of eResource service, or a usage statistics instance?

• What features could you bring back from those larger, patron-facing micro-services that develop them — but which you do not have the budget to provide similar staff services at the moment? How would this change your team’s work life? How much more time might they have to increase the visibility and viability of your library, if they could work in, rather than around, their tools?

But I jump ahead to the likes of Use Case 3: eResource Optimization. Nonetheless, it bears consideration: this is the type of thing federated infrastructures with micro-services can and do, do routinely — No pie to make sure stays together, no spaghetti to trace back. (Introduction page 8)






Nannette:

Let’s jump back to the metadata enhancement interface and continue our scroll through the aggregated and enhanced metadata. Notice: We’re grouping things again, just like the backbone; just like the boots. Groups that work for people, business cases, and their individuality. Here we have:

Book Details

Journal Details

Resource Details



Nannette:

BUT WAIT! These aren’t WEMI. These aren’t the bibliographic description categories we are used to and trained in! We can’t aggregate and enhance library metadata without them!

OK, first remember, our ground rules, we’re:1. Measuring against business case, where cost is a primary factor.

2. Targeting a librarian-led, trained to the task at hand, not necessarily the entire scheme, with minimal theory and/or technology training, non-librarian workforce.

3. Letting the computer do what it does best, to free the humans to do what they need to do to meet their business case of visibility and viability.

Second, remember as we’ve said before, we are no longer forced to eat cold Spaghettios from a can! We are in a federated infrastructure, micro-services architecture here, not the preSOA or SOA architectures of our current systems.



Nannette:

Which, as we’ve said before, allows us to do aggregation here, now, in a manner that meets the requirements of our current business cases AND still support our current systems.

Remember, PraXis is the bridge, not the new monolith, as Kathryn noted in the Introduction.

We’re dealing with cupcakes here that can and do, support WEMI, MARC, RDA, ONIX, and all those other encoding standards and rules, on the back-end, in that hidden layer I talked about in Orienteering for Libraries: Session 2, (Slides XX to XX) .

And yes, we need to show how this works and we will in Use Case 3: eResource Optimization. Want more, can’t wait for it to post? No worries, contact us for a “virtual coffee” walkthrough. We’re happy to answer all your questions in detail, at your convenience.








Nannette:

Now, back to those intuitive, user- and system-friendly groupings. A couple quick things to notice. These divisions, work,

• Not Only for Users without requiring extensive model training — Most of us know the difference between a book and a serial. Most of us would expect to find anything common to both, or used by things like Streaming Media that aren’t a book or a journal, in Resource.

• But Also for the Service, as they match to the Required/Optional/Not Applicable toggles of the user’s first choice upon entry into the enhancement form (i.e., Resource Type).

All of which, of course, gets us that magic BAM, ROI double down we mentioned earlier.

And taking this one step further, as this form is used by both the Create New and Adjust/Enhance aggregated metadata services, these groupings also allow:

• Users to quickly identify and correct errors and/or missing pieces from ONIX. Or here in the APA example, Routledge article metadata. Perhaps in library, audience- or local system-specific changes to the “master” entry downloaded or supplied from your vendor? A new, more efficient way to look at copy cataloging, perhaps?

• Services, both the Create and Enhance services, to use the same error checking routines —Remember those idiot boxes we mentioned earlier which ensure error-trapping at the least expensive point (i.e., initial data collect)? In the aggregation service, they turn on highlights in the interface to show users where data is missing or irregular (i.e., validation of the aggregated data for local use). Talk about ROI!



Nannette:

Let’s scroll down a bit further, and take a minute to acknowledge that this service• Takes the new cataloging standard’s primal rule, “Take what you see” to a new

level; it matches the Entry/Enhancement interface to what you should see in the resource. If your resource doesn’t have these things — like an ISSN, when you think you are working with a Journal article — One of two things is true, either:

1. You aren’t looking at what you thought you were, and you made the wrong choice at the very beginning.

or

2. Someone has made a mistake, and not assigned the correct things at the correct time.

Talk about error- trapping and correction at the least expensive point in your workflow (i.e., before it gets anywhere and causes problems — while it is still in the hands of the people with the knowledge, power, and responsibility metrics weighted to correct the problem)! This takes it to a whole knew level. This puts the power of the business case success in your staff’s hands now.

• Prepopulates fields like Copyright statement and language with your embedded policy statements defaults, taking all that hard, pre-data creation decision-making work, and making it active where it counts — where it increases accuracy and decreases costs directly. Of course, with an over-rideable feature, sometimes limited to superusers only, that enables easier real world policy enforcement.



Nannette:

Notice the “Do Not MicroSale” checkbox. Certainly not something you’ve probably ever seen in bibliographic metadata before. And you’d be right, if you said, “that feels very Sales and Marketing, Nannette. It should be in the Transaction wrapper.” And it is in the backbone, as it impacts how the resource associated with the metadata in this template is sold and distributed —Think DDA (Demand Driven Acquisition), if you want to purchase just the article with this metadata outside the Journal Issue or Journal wrapper, how does the system know if it’s available? Easy, this toggle at the level inside the resource (e.g., Article, Chapter, Image, etc.) But I digress, back to why this is in the Bibliographic wrapper.

Remember our earlier workflow distinction of “if Editorial Decision, then Bib” and “if Marketing Decision, then Transaction”? Workflow and decision-making authority, not cataloging standards, dictate grouping placement in the micro-service to achieve better quality, at lower cost. Or said another way, metadata is aggregated, created, edited, versioned, and/or updated at the point in the workflow where the person is who

a. Cares most about the accuracy of the piece of metadata

and

b. Has the knowledge to collect it correctly.

And for a micro-sale, this person is the Editor, or one of his/her staff. The people who know the content best — Where it can be packaged as a sensical, stand-alone unit, and where it can’t. Where there are important legal (copyright or liability) or political (stewardship or author relations impact) ramifications, and where there aren’t. More on this in Use Case 2: Library as Publisher Support. For now, take just a moment to think about what this type of information, when connected to other metadata, could do for metrics, DDA, cost evaluations, and the like. (Stewardship Reference: Slides 41 through 44 of Orienteering for Libraries Session 1)



http://imteaminc.com/wp-content/uploads/2015/10/2015_10_27SurveyingTheTerrainUnfamilarLandscapes.pdf

http://imteaminc.com/wp-content/uploads/2015/10/2015_10_27SurveyingTheTerrainUnfamilarLandscapes.pdf



Nannette:

Finally, this service meets Kathryn’s introductory requirement of collecting relationships in-stream, at the point(s) in the workflow where the people are who care, and have the knowledge and decision-making authority to collect them most accurately, and cost-effectively.

Notice Related Audience, with its drop down pulled out. Remember these drop downs are fed by the backbone with all those fully complete, interconnected definitions, with their synonyms, audience preferred terms, as we discussed in the boot analogy. Here we’re showing the base terms; but we could, as in the Contextual display earlier, easily and without significant cost or accuracy impacts, display terms and/or definitions in the preferred language, as appropriate to the specific audience of this micro-service — For a cataloguer, the standards terms. For a work study student, modern language terms they understand. For a patron, tagging Thai romance novels, categories in Thai, instead of English — and yes, this last one is a real use case. There are public libraries that do this type of thing today, though admittedly, not with a tool like this. Last time I checked, they were using Excel.

And looking at a vocabulary like this, where we see an extension of the RDA Audience vocabulary itself with Teachers, University Students, University Level Academics, Recent Grads, etc. — as we hinted was needed earlier with the boots — let’s remember that this is a 2012 interface, as I mentioned in the beginning. This type of information is in the ONIX and other preLibrary metadata records now, in the sales stream where we could, if we chose to, access it as part of our Acquisition process.




Nannette:

What could we do with this metadata in our micro-services bridge world? Say in academic libraries who have faculty specialists like those from the earlier Denver use case?

Could we easily increase our visibility to them simply with this type of metadata and micro-service Discovery interface that doesn’t suffer from the problems of our current monolithic system interfaces? (Introduction page 16)

Might something like this be a better, more cost-effective solution than continued use of current bolt-on Discovery platforms? Certainly worth some thought about the immediate business case advantages that better metadata aggregation affords us.

And, speaking of the business/use case definition that started our micro-service interface tour; one of the goals of APA was to Promote extended uses and sales opportunities. Consider for just a minute how:

• This specialty vocabulary (a type of Intended Use, or at least an overlapping vocabulary) coupled with those Audiences we just looked at provides the metadata collection to service APA’s key business case needs.

• These Related Audience and Related Use taggings, coupled with the earlier Resource Type with irregular granularity designations and the micro-sale notation could meet the Discovery and Delivery needs of a University professor who is looking for new articles from a research journal to augment his textbook choice for use in his class packet (without or without Library as Publisher Support). Not to mention, extend your library’s DDA service in an effective manner with great usage statistics. How would services like this impact your bottom line and get your managers’ support in the budgeting process from key customers?






Nannette:

Consider for just a minute how: • These Related Audience and Related Use taggings, coupled with the earlier

Resource Type with irregular granularity designations and Related Resources as we see them here, could meet needs like a New Graduate who used that Textbook and class packet, is now in his first job and needs practical application, rather than classroom tools to do his job. Could they be used to recommend in a Discovery interface the handbook (aka a derivative work) based on the textbook he used in class? An extended, refuting, or supporting article to the one in the class packet, updating what was learned in class, based on current research? Let your imagination run a bit wild here. These aren’t dreams for the future. They are things we can and, I would argue should be doing today — against our live business cases — using aggregated and enhanced, currently available metadata (remember this is a 2012 interface that has been in use since then) —without upgrading our current monolithic systems — using micro-services like PraXis.

Wow, all this in just the Bib section of this PraXis micro-service. And we are getting very close to the end of our hour. So, I’ll just click through the related screens here quickly. See Related Resource Thoughts on the IMT website for more detail on the relationship stuff shown here.




Nannette:

Continuing our quick click through, with links to more detailed discussion on the IMT website — in this instance Related Authority/Identity Metadata Thoughts —let’s take a quick click-through of this micro-service’s Authority section.

Notice:• The user’s first choice here, in the entry or enhancement of Identity or Person

information is, just like in the Bibliographic section, Contributor or Relationship Type. The first question, is how is this person associated with the Resource? And just like in the Bibliographic section, this allows automation of Required, Optional, and Not Applicable, and all the other activities that help us ensure our collection and enhancement activities in the micro-service adhere to our business case and reap the desired benefits.

• Inline Definitions, fed by the backbone with all those advantages and requirements noted earlier continue.

• Micro-service is collecting things, not strings. Entities with data types and data divisions as appropriate to the information being collected with prompts/defined entry areas, as seen in Name, to ensure correct input.

• Inline support/help is extended with fly-outs where appropriate that prompt those users with minimal technical training to enter in correct format — the format validated by those idiot box functions that run upon click of the Save or Submit buttons.




Nannette:

Notice:• Corporate Body looks similar and continues the same things, in the same way

with appropriate changes like name format for the Corporate Body entity.

• We have Specialties here, as in the Bibliographic section. Remember those boots and the Merrill example earlier? Here’s the Identity Management metadata that gets things like that done.



Nannette:



Nannette:

Continuing our quick click-through, with links to more detailed discussion on the IMT website — in this instance Added Subject Metadata Details — let’s take a quick click through of this micro-service’s Subject section.

• Embedded Help continues. And it is extended with Images, where more appropriate or useful to humans than text. This matches the training that was provided, which gave users a pneumonic for how they were to encode subjects.

And a quick comment about cost here. This help image was added with minimal cost and expense, on-site, over lunch, between the morning and afternoon training sessions when it became clear that folks needed this in the interface, not in the training. And it was done in less than 1 hour — remember the graphic was done as part of the training. It just needed to be added to the micro-service and played out to all versions of the template.




Nannette:

But back to our walk-through. And as we click through these screens, you can see that what we’re really walking through is a decision-making process. Yes, we are in this interface, this micro-service, collecting subject metadata against a thought process, a discipline-specific knowledge organization scheme, that just happens to correspond to a serialized ontology like we theorized in the boots analogy.

See Added Subject Metadata Details for more on this.




Nannette:



Nannette:

Notice too, we’re collecting Place, as we mentioned in the boots analogy. And we’re collecting both against geographic vocabularies, where applicable, and as a subject itself using the same vocabularies — We’re dealing with Urban Planning remember; Place is the subject of many of their resources.

And we are using controlled vocabularies, etc. Interested in more information on all this? See IMT website’s Added Subject Metadata Details.




Nannette:



Nannette:

And in this horrendously fast run through, let’s briefly look at Transaction. And as with the other sections we ran through very fast, yes, there is an Added Transaction Metadata Details posting on the IMT website, should you be interested in further details.

Do notice, the consistency. We still have Required/Optional/Not Applicable, backbone-fed, interconnected definitions; related vocabularies; inline help; and all the features of previous sections which allow us achieve our individual business cases and reap the benefits of a federated infrastructure-based micro-services approach.





Nannette:

Notice too, the ONIX vocabularies here. We are in Sales and Distribution metadata, after all. And yes, even though this is ONIX and not a library-specific encoding format, we have all the webs, enhancements, and versioning we used earlier with these vocabularies too.

And remember, this template is in use and a couple years old. And yes, this is ONIX 3.0. Why? It was the most current standard at the time of release — and it still is. And as we will see in Use Case 3: eResource Optimization’s white paper, though the standards are not “officially” backwards compatible, and though ONIX to KBART is a “lossy” process, we can and do export back, legacy data that’s needed for your older systems — just like the WEMI data exports I mentioned earlier — in a package those systems can import, at realistic and acceptable quality levels. Sometimes actually, from exports, better quality levels of the data present in the rest of those systems. Which can, of course be its own problematic issue. And yes, we can do a customization layer to address this against your system’s specific needs and business case.

Remember, PraXis is a bridge product, not a monolithic replacement. It is meant to connect your systems and it does. See our white papers for more details. In fact, this needed level of deeper detail, is why we decided to cover Use Cases 2 and 3 as white papers, rather than webinars.




Nannette:

Notice here, we’re clearly displaying filtered ONIX data in the Trim Size field. To get to library metadata from here, we need one of those mathematical logic maps we mentioned earlier. And there is a map from Trim Size to Dimensions.

We can and do collect Dimension information here in Transactions, as it is a Marketing decision, remembering our earlier caveat. Additionally, the data here in distribution, in ONIX, is more explicit, more detailed than bibliographic Dimensions data, so we downgrade it to RDA data in those export routines.

So I guess I want to admit here, to say out loud, that sometimes to get to library metadata, we downgrade available aggregated metadata. We eliminate things that would be helpful to our Discovery and Delivery services, but which are problematic for our current systems. Things like detailed size information and derivative works. We remove information that is better than our information, information collected from the people who have the knowledge, power, and responsibility metricsweighted for better, more accurate metadata in these areas. And this seems like a shame. This seems like a place that something like PraXIs would be most helpful.



Nannette:

Notice, that as Kathryn mentioned in the Introduction, and as I mentioned in the description of APA’s individual business case, the micro-service connects to other internal systems, like the ERP, where appropriate.




Nannette:

Let’s take just a short moment to talk about workflow and business case. And yes, • There is more than one word about this.

• All this connects to that technical backbone and the linked data justification.

All of which you can explore in more detail in our downloadable piece, Added Save, Submit, Publish Micro-Service Workflow Details. Or, if you want to see how it specifically fits into your business case, just give me a call or drop me an email. I’m happy to walk through it in detail with you at your convenience.

Suffice it to say, for our purposes here, we’ll walk through the button prompts in the micro-service. And we’ll note, these work on- and off-line, as you can see here we’re doing with Save to allow users to save their work in progress, and pick it back up after a break for lunch or an interruption.





Nannette:

It automates the submission process for Review. And it prompts on both ends of the Review cycle, Reviewee and Reviewer, that activity is needed.

And it interacts, seamlessly with APA’s internal systems — Security, Authentication, and the like. Remember, we did say, PraXis is a bridge. We didn’t need to build these systems. They exist and are used by the larger organization. We just needed to bridge to these systems and display pertinent details, and/or turn on or off application functionality based on supplied information from those systems, in our interface.



Nannette:

And as Pending shows here, we are using the same interface for all parts of the workflow. Though based on that supplied authentication information from the bridged-to-system, the Librarian superuser gets a few more tools. Tools they need to do their jobs efficiently. Tools that are displayed or hidden, just like those Require/Optional/Not Applicable automations we saw earlier.

Speaking of efficiency, it seems important to note, that though we are not showing it here, there is an alternative view for these superusers, at least one of whom is one of those metadata specialists we mentioned earlier who works in XML directly. An alternative view that allows these users to view and interact directly with the backbone data, that is traveling behind, or being viewed through, the micro-service interface we see here.

Remember, this interface is a collection tool, a display — it is not, and does not explicitly reflect, a data structure in the way interfaces in our monolithic systems do.



Nannette:

And finally, to mention that authentication piece again, when we get to Publish, Publish acts on that data, it “knows” using those mathematical maps and logic, where and how to publish that data for use. And it does it better and faster than a person.

Here in this APA example, it publishes and populates the CMSs that serve their Web products, as well as the technical service and publishing archive with all of the audit trails and versioning that serves Editorial.



Nannette:

So, one last thought before we close — a thought about Overhead, Maintenance, and costs.

First, for more detail on all this, contact us. We have:• Years of metrics and use cases by user types and work done.

• Technical and user documentation for both users and superusers. A few small pieces to which we referred earlier. Other key samples of which are posted to our website under the Resources tab.

But we have more, much more! And we are happy to share any of this with you as it meets your use cases, questions, and pain points. As the overwhelming amount of information we encountered in our use case presentation activities these past few weeks, the problem isn’t having it in our collection. The problem is finding you just what you need, at the right level of detail, to answer your questions and help you do your job better. Sound familiar?

So for now, at the end of a long hour, let’s just say, what you have seen here was and is implemented:

• In under 8 actual working weeks for the IMT team — spread across a number of months, as it worked into APA’s specific product, technology, marketing, and editorial plans, calendars, and budgets, the physical representations of their business case(s) if you will.

• With allowances for staff learning curves and knowledge transfer time.

• At a cost of less than $60,000.

• With less that 2 months post-release training and support between live release and today.



http://imteaminc.com/resources-2/

Nannette:

Yes, PraXis is • Working.

• Fast.

• Inexpensive

• Extensible

• Capable of being run fairly autonomously by people doing their normal jobs.

And Yes, PraXis is running At Scale, Now.

As we’ve said any number of times throughout this presentation, want to learn more? Just contact us. We are more than happy to talk to you. We are more than happy to respond to your questions. We are more than happy to demonstrate working components and show you how a PraXis solution moves through from inception to implementation.

Our time struggle in all these places is not, “we have to create it to show it to you.” Our time struggle is simply how to best communicate what we have — In a way that makes sense to you, the practicing members of the community. Or said in another way, how best to provide service to you. Don’t hesitate to let any of us know how we can do this better. Don’t hesitate to let us know what you need to succeed.

And with that, back to you, Kathryn.




Kathryn:

Hopefully this session on metadata aggregation and enrichment begins to make the capabilities of PraXis a bit more concrete, and to demonstrate that you don’t need to wait for someone else to start developing the solutions that will give your library visibility and viability. The time for library transformation is now…we need to get moving quickly, before the fantastic opportunities of a Web-based world pass us by forever.

Again, I hope that you’ll take some time to review the white papers on Library as Publisher and eResource Optimization, which show how PraXis can be deployed, like that Swiss Army knife, to support other library needs. These will be published to the IMT Web site by the end of the year, and we’ll notify all registrants for the November 24 Webinar of their availability.

We’re happy to discuss the needs of your individual library for metadata aggregation and enrichment, resource creation and acquisition, and e-resource optimization…to roll up our sleeves and work through the ways in which PraXis can bring value to your organization. Just reach out to us via the “Talk to Us” link on the IMT home page.

We thank you for taking time out of your schedule to view this session…and as always, we wish you visibility and viability for your library.







orienteering for libraries: taking a practice trip: three problems: three solutions

Technology