NISO Discourse Discussion for this sessionhttps://discourse.niso.org/t/knowledge-bases-and-next-steps-new-and-upcoming/110NISO KBART Validator App
How can we enhance trust in the quality of KBART files? Endorsement process is one way. Automated validation could be another way.
Content providers can have their KBART files endorsed by NISO. But the endorsement process consists of manual checks and thus can be a long process, with multiple file revisions and much back-and-forth communication required. The KBART Standing Committee aims to formalize and speed up its endorsement process by automating a number of validation tasks, thus providing more time to analyze parts of the files that are trickier to check automatically. Automated validation could also occur upstream, by content providers checking their KBART files post-production, or downstream, by knowledge bases checking KBART files before ingestion. What if all these scenarios relied on a shared tool?
The NISO KBART Validator app has two goals:
* Short term : ease NISO’s endorsement process by automating file checks that can be automated
* Long term : provide the community with a common validator app
The NISO KBART Validator app is currently under development. This session will provide a demo of the tool and insights about its roadmap. We want this app to be community powered: we’ll take time in this session to discuss where you and your organization could help, with or without developers.""The Package ID: Seeking Sanity through Standards
Content providers often bundle offerings into pre-set collections by subject, year, or some other scope so libraries can select packages that best fit their needs. Publishers also sell individual journals and books, allowing libraries to select content title-by-title. These options provide an effective approach to selling content. However, they produce a confusing, ever-changing tangle in knowledgebases.
Currently, package names are used identifiers, which introduces challenges for knowledgebase providers and librarians. Marketing pages, access platforms, licenses, invoices, and knowledgebases may all use different names for the same packages. Additionally, package names change, differ on various systems, and different bundles often have very similar names.
Knowledgebase providers load the content bundles to serve as the basis for discovery, linking, and ERM processes. Using package names as the identifier complicates always uniquely identify collections. The problem also affects automatic updates to the knowledgebase, in general, or within a specific library’s holdings. Likewise, librarians have a difficult time determining which of the many similar-sounding packages matches their licensed content.
Ultimately, all parties want to ensure that the licensed content is represented and enabled in knowledgebases for discovery and linking. Consistent unique identifiers may offer a way to improve efficiency and reduce confusion.