Name:
The NISO Video & Audio Metadata Guidelines: Now What? Recording
Description:
The NISO Video & Audio Metadata Guidelines: Now What? Recording
Thumbnail URL:
https://cadmoremediastorage.blob.core.windows.net/549e6c45-9dbe-42d2-8385-7bc280f416c8/videoscrubberimages/Scrubber_3.jpg
Duration:
T00H40M19S
Embed URL:
https://stream.cadmore.media/player/549e6c45-9dbe-42d2-8385-7bc280f416c8
Content URL:
https://cadmoreoriginalmedia.blob.core.windows.net/549e6c45-9dbe-42d2-8385-7bc280f416c8/The NISO Video Audio Metadata Guidelines Now What-NISO Plus.mp4?sv=2019-02-02&sr=c&sig=fdvvBg09AL4W7ADqw4aULSITrYMcomaIDs09iw%2B7Po4%3D&st=2024-12-22T06%3A14%3A53Z&se=2024-12-22T08%3A19%3A53Z&sp=r
Upload Date:
2024-03-06T00:00:00.0000000
Transcript:
Language: EN.
Segment:0 .
Hi, everyone. My name is Cliff Anderson, and it's my pleasure to introduce this panel on Video and Audio Metadata Recommended Practice.
Now what? There's so much streaming audio and video content on the web. These days, but discovering and aggregating this information has proved challenging as metadata standards for describing this content have been lacking up to now. Well, not any longer. NISO's Video and Audio Metadata Guidelines aim to provide guidance for describing and sharing information about AV materials online.
The working group was "established to provide guidelines for metadata for video and audio assets, incorporating existing standards rather than creating new ones and covering the following categories of properties administrative metadata, semantic metadata, technical metadata, rights metadata, and accessibility metadata".
The chairs of this Video and Audio Metadata Guidelines working group were Barbara Chen, the retired Director of the Bibliographic Information Services and editor of the MLA International Bibliography at the Modern Language Association. Violaine Iglesias, CEO and Co-Founder of Cadmore Media and Bill Kasdorf, Principal at Kasdorf and Associates. I am pleased to introduce this panel, which features one of the three editors, along with two additional participants in the working group.
So on our panel today are Violaine Iglesias. Violaine's experience spans 17 years in professional, scholarly and trade publishing, including stints at technology provider GVPI, SAGE Publishing, Random House and Flammarion. She has led the development of digital publishing platforms and co-founded Cadmore Media to spur the growth of streaming media in scholarly and professional communication.
We also have Michelle Urberg. Michelle is an independent consultant specializing in metadata and enhancement and client and the client success manager for LibLynx. She is active in the National Information Standards Organization (NISO), the Society for Scholarly Publishing (SSP), and the Association of College and Research Libraries ( ACRL). She speaks regularly about using metadata to make the world a better place and about the importance of born digital projects in the scholarly record and better discovery for video and audio content.
She is the new North American editor for Learned Publishing. And finally, we have Robert Wheeler. Robert is the Director of Digital, Director of Publishing Technologies at ASME, the American Society of Mechanical Engineers, where he helps guide their digital strategy and publishing business with a particular focus on the standards publishing program. He is Co-chair of the NISO SSOS Standards Specific Ontology Standards working group and the NISO STS XML Standard Tag Suite standing committee.
Now I'd like to turn it over to Violaine to begin the panel itself. Thank you very much, Cliff. So hi, I'm Violaine Iglesias. I'm the CEO and Co-founder of Cadmore Media, which is a video hosting platform that is dedicated to scholarly organizations. So that's directly relevant to the work of this working group. And we're quite excited to have this resource for us to implement with some of our clients.
So I'm just going to do a quick introduction, which is going to cover a very brief overview of what this working group started when this working group started, how we went about creating these Recommended Guidelines and then where we are now. Story about the map. I was just looking for a cool history picture and I just love maps and I've been reading history books.
OK, we started in 2019. I know it's a while back, four years, but then COVID happens, so that excuses everything. A lot of work was done by relatively few people to do this, and now the practice is ready. At the time of recording, it's almost ready to be published. So we're kind of hoping that it will be by the time NISO Plus happens, but in any case, it's very, very close.
I just wanted to give credit where it's due. The people who actually did most of the work are Michelle Urberg and Bill Kasdorf. They're two co-chairs of the group. I'm mostly an advocate. I get really enthusiastic about things and then I can't do details and they did all the details. They did a ton of work for this. So I'm very grateful that they brought this to reality.
So why did we do this? It's because media is getting important, but it's still very much emerging in scholarly communications. There's not the same standards and best practices that have been established for media as have been generally for more established formats like books and journals. So what happened, and I think I've told this story many, many times, is that I went to, as I was starting this venture, this video hosting platform, I went to NISO.
I went to Todd Carpenter and Nettie Lagace and I asked them, what standards should I use for video generally? And they said, that's a great question, do you want to find out? And actually, Rob who's here also said, "Hey, do you want to start working group at NISO?" So that's how we all started doing this. Basically, we had a problem and we wanted to solve it.
So what we did is we brought together some stakeholders from the various constituents groups of NISO. So it would be libraries, publishers, vendors. And we also had some people who actually work on other standards. And what we established was that the objective was to improve the communication between these stakeholders. So what we came up with is not a standard, it is a Recommended Practice.
I'm going to let Michelle explain exactly what that means. But I just want to make clear from the start that we did not come up with a new standard. That was something we established quite early. We said we don't want to reinvent the wheel. There's a lot of standards out there. The point is, how do we make sure that people who use these different standards can communicate amongst each other.
I am going to just talk about three use cases that we kind of brought up in the beginning saying, hey, we think these people have these kinds of problems. So that inspired us to do that. So, for example, one good example that I come across all all the time in my daily job is peer-reviewed surgery video, for example. Video is very important in the field of surgery. And I'm going to read the use case that's actually in the introduction, that will be simpler.
So the use case is a medical publishing organization that includes high quality peer-reviewed surgery videos alongside its journal offering, lacks clear recommendations on how to design a rich metadata model compatible with indexing databases, publishing platforms and learning management systems, while supporting cross-linking with other content formats such as journal articles and book chapters.
So this is pure journal research, etc. iI's one type of content that needs to go into a whole bunch of systems that haven't really been adapted to video yet. Then the second use case is, Let me just go here, there you go. A discovery service that wishes to index media assets from a wide variety of content providers will have to spend considerable resources on normalizing, capturing and mapping incoming metadata.
That's the other use case where you have one system, but you have tons of content going in that comes in all kinds of different formats. So if those publishers knew what format people were using, sort of the same properties, then it might be easier for the indexing services to properly index video. And then finally, if I can, there you go.
A media librarian who manages content produced by faculty, streaming products provided by a handful of established video licensing vendors, and other expert content provided by independent publishing organizations will need to cope with a variety of metadata models that make it difficult to create an efficient discovery tool to ensure that all content can be accessed by faculty and students.
Your library catalog, you've got content coming from all over the place. It's also a very different nature, you're not building one product, you're just building a path to that content. How do you do that? So now what? Today's conversation is going to be roughly three parts. The first part is going to be an overview of the recommended practice by Wunder Co-Chair Michelle Urberg, who I'm sure I'm not pronouncing your name right, but that's a commonality with me.
And then an interview with NISO veteran (by our standards), Rob Wheeler, mostly because, you haven't been involved with this work, but you've been involved with other NISO work. And we wanted to ask you, how do we make this work now? And then an open conversation with the audience. We're going to be picking your brains about next steps. So the entire Q&A - or if you have questions for the panel, that will be great -, but otherwise, the entire Q&A session after this recording is going to be dedicated to brainstorming.
How do we go about making sure that this gets adopted? So that's it for me. I'm going to hand it over to Michelle, so I'm going to stop showing my screen. Bear with us. While we allow her to share hers. Great thank you. One second. Here share this, then I need to, I want to present.
How do we do that? Slide, Present, I'm very bad at this part of it. Is it a slideshow button that's on the upper right? Oh, my apologies. Here here we go. See that? Excellent. Thank you, Violaine Happy to be here today.
NISO Plus is always one of my favorite conferences and I've been involved with it from it's the first version a few years ago. So I've worn quite a few hats in the library and publishing industries. This is one of the many. Video discovery has been important to me actually for a number of years. When I first learned about the challenges of video discovery, I was actually working in audio discovery, for that matter, too.
For me, it started with video though, really, when I worked in the 360 Knowledge Base for Proquest, it was previously known as a serial solutions knowledge base. Sure, many people are familiar with that product. When Violaine, Bill Kasdorf and Barbara Chen opened the call for joining this working group, I leapt at the chance to participate, and I'm actually here representing the Music Library Association, who is an active member of NISO.
And I have to say, this is the first Recommended Practice that I've been a part of, but it's been a very interesting process. Let me reiterate the impact of the COVID-19 pandemic on the length of time that it has taken to finish this Recommended Practice. There were months when extended stretches when we weren't, the working group wasn't communicating or it was stalled because we all were sort of tied up with lots of other professional and personal matters, and that goes across the group.
But today we have a Recommended Practice that is detailed and full of properties that we think can be adopted by the community. And the next step will really be for community adoption to take the lead with helping us to develop this into whatever it's going to become for, maybe Recommend Practice 2.0. So the Video and Audio Metadata Recommended Practice. Violaine highlighted the difference between "recommended practice" and a "standard" in her introductions.
So when we think about standards, the first one that comes to mind, especially because I know quite a bit about knowledge bases, is KBART, right? KBART has gone through a number of iterations. It provides a clear set of guidelines that are shared across the industry and providers of primarily books and video, sorry, books and journals (but video is to be added in the third version of KBART soon), are a number of specific metadata fields to be handled in particular ways for each content type that is being distributed.
KBART is very different than this recommended practice, or any recommended practice for that matter. The recommended practice, by contrast, is yes, driven by industry input, but at this point not an adoptable standard. It provides a set of guidelines and ideally best practices that a provider of video or audio content can use to interchange metadata.
When we began working on this, we discovered all of the nooks and crannies that encompassed video and audio metadata exchange and interchange of assets. And that's another reason why this is a recommended practice and not a standard. The variety of video and audio content at this point makes it much easier for community adoption and use to have a recommended practice rather than a standard.
So to this end, what did we do? We established global properties that a company should accompany all types of inter-exchange of data, inter-meaning between companies, maybe intra, inside of a company, an organization, university, and then alongside of what we consider to be global properties, things that should be shared universally. We have to mean specific things and I'll get into those in just a bit.
Alongside of the properties, we have a set of use cases upon which these properties were built, and those use cases are very specific to domains. They helped us actually define how specific domains of sharing information are different. And I'm not going to go into most of those today, but you Violaine introduced at least three of those. We have over 40 of those inside of the recommended practice for your organization or organizations that you want to work with to follow and to use as a guide.
And then after the properties and the use cases, we have a set of tips and recommendations to actually deploy this as a recommended practice inside of your organization. Those also include some tips for handling metadata effectively. As a metadata person, I have to say as a reminder, metadata is never one and done. It's sort of a long term relationship. You need to take care and tend for it.
It's not free like a beer, it's free like a puppy. You have to take care of it. So finally, the appendices that are at the end of the recommended practice actually detail all of the properties, global and domain specific how to handle them, what standards already exist in place to use as guidelines, etc.
So let's dip in just briefly to the nuts and bolts of this practice. The global metadata properties that we identified divide into four categories of metadata. These are commonly used divisions across multiple information sharing industries and be they libraries, content providers, aggregators, etc., archivists as well.
So we have bibliographic administrative, technical and semantic properties, the global properties that we have identified and I believe there's 15 or 16 of them at this point. I can count up the numbers on the screen here. They reflect the properties that are most commonly used across the use cases that we collected. So the working group actually broke broke down into two sets of people, those working on the metadata properties and those working on the business and use cases.
And each of them sort of worked independently. And the place where we came together was following a study of standards which the properties group did, and then the business group did a study of use cases and how this could possibly be used. We merged them together and this is the work of them, of amalgamation. So we have bibliographic information of title identifier, date, language, who's creating the asset, maybe an author, but maybe not the location that is encompassed inside of the asset itself.
Who can use it for administrative properties, technical properties of the file associated with it, how do you access it? Like the URL, how long it is, and then semantic properties, for example, subject description, who is inside of the asset. Creators and people between the bibliographic and the semantic are a little bit tricky to handle. Language is also a little bit difficult because it can accompany language of the asset, translations, subtitles, etc, so all that is to say this is a work in progress.
We've done a lot of work thus far, but there are definitely steps that can be taken. Just looking at my notes here. So in addition to these global properties, we have domain specific properties. And again, this is coming out of the use cases at our business use case group developed inside of the working group.
They identified six groups, organizations, sort of, we call them domains. But fundamentally, they usually come out of a specific group, right? Libraries and archives are a kind of organization that have specific needs for sharing of metadata. Violaine hinted at that with library catalogs in her introduction, publishers. Again, a specific kind of organization that needs specific things to interchange metadata associated with video or audio content.
And then we have more broad sort of topics education, events, journalism, research. Those categories are slightly different than libraries or publishers, but they all have all six of these categories have the same characteristic of being specific, having specific metadata needs that need to be shared to make a piece of content discoverable.
So events are a type of content that are near the near and dear to Cadmore Media. Obviously, one of the reasons why I'm highlighting it here, I'm sure Violaine will have comments to add later for this. But if you are sharing an event, a conference presentation, it's the type of event you will need to have in addition to all of those global properties that we just looked at, the type, the identifier, sponsor, when it happened, if it's a conference proceeding, the citations that are associated with that recording, and then finally the date.
These are not specific metadata tags, but these are the content that you as a publisher, an aggregator, content provider, need to be able to put into a metadata record to share, to make a piece of content in this case, an event, a performance, conference, proceeding, etc., sharable. That's right.
So I've hinted at this already, but this recommended practice is for specific kinds of organizations or groups that need to interchange metadata. We're focusing here on metadata for audio and video assets. So we're interested in reaching out to providers of video and audio content, aggregators of video and audio, content publishers, library archivists, etc., anybody who is handling this data, even product people, those who are, for example, the discovery service of Violaine, EBSCO Discovery, Primo, Summon, the product people who are developing those types of discovery services, and other discovery services, need to be thinking about how their products can actually integrate video content into their current metadata schema that they're using to make their product function for end users.
So the sky is basically the limit for who is going to use this as long as you're using audio and video metadata. What was our process to do this? It was very detailed. As I indicated earlier, and Violaine also mentioned this, the COVID-19 pandemic expanded the length of time that it took to gather all the information. But one thing that we found is really tricky in all of this was understanding the needs of the stakeholders that need or want to use this recommended practice.
We have a lot of existing standards and schema that can be drawn on, but ultimately we aren't trying to reinvent the wheel. We wanted to have concrete pieces of information that can be shared across organizations that may not use the same standards. The group who is using JATS isn't necessarily going to use some of the things that you need for video content.
So what does that organization that is a journal and is using JATS wants to add video what do they need to add to their XML record to make video content in their ecosystem discoverable. So to that end, we developed use cases, that's the business use case group that I mentioned. They developed over 40 ways of interchanging metadata and those are all outlined in the recommended practice. And then alongside of that, of course, we develop properties that are based in part on what we know as industry experts and then also drawing on the expertise of, for example, people who work at IPTC.
One of our working group members works for WGBH in Boston. And so she brings a completely different perspective than I do as somebody who comes from a discovery service originally, with my knowledge of video metadata. So taking those use cases and the properties, we tested them together. And out of that really came the recommended practice with those global properties that we just looked at, the domain specific needs of each area, each of those six areas, and then within those domains identifying specific pieces of metadata that need to be appended to the global properties.
If you're, for example, as I mentioned earlier, sharing an event. So now we've come to the point where we have sought recommendations from the community at large and we received some really useful and helpful commentary that has made it a better recommended practice. We received, for example, comments about accessibility, both for modes of accessibility and also the use of language in accessibility terms.
So are we using WCAG-compliant language inside of the metadata record? So all of that has been rolled into the recommended practice. And so now that we have this feedback, we have bolded these last three items, but we are working to receive permission from NISO to release it. And then once it is released, we want people to use it. And we want to encourage community adoption so that it becomes a living and breathing practice that people can use.
And with that, I am going to stop and hand it off to Robert, who is going to talk to us about adoption and how to make it a marketable practice. So thank you. Nice segue, Michelle. I wanted to add about, the, you know, when you were describing all the testing that we did, etc., all that was done through spreadsheets and that was pretty scientific in the end.
Even the recommended practice includes a lot of spreadsheets. It was a lot of data in the end, but we are giving the underlying data alongside the recommended practice. There was some debates about it, but it's being shipped with it. It'll be there. It'll be there if people want to use it. It is a pretty document now, though.
So so you just want the pretty document, it's there for reading. Rob, how do we get the document adopted and read by everyone? Well, to be serious. First, I was hoping you could tell us a little bit about your experience doing this, not exactly this, you worked on standards, but what's been your experience after a document is ready with promoting it?
"Releasing the document" is a little anticlimactic! I mean, you're done all that work, and it's like, released. But, you know, adoption isn't something that happens suddenly. You know, it gains momentum over time. And I feel like the benefits need to outweigh the burden. And there's often a tipping point for potential users. Personally, I think one of the biggest benefits of adopting a recommended practice or standard is you acquire all that experience and knowledge and effort that went into it, and it avoids each organization doing the same thing over and over again in a slightly different way, and which really leads to interoperability.
You know, one of the things that we talked about was being mindful of adoption from the outset. And you could tell that you guys were thinking about this. With NISO STS, the XML Standards Tag Suite, we made an early decision, actually even in the work item, to remain backward compatible with ISO STS, which was being used for ISO standards and then adopted by national standards bodies.
And that made the transition from ISO STS to NISO STS much easier. And another aspect during the development was an often repeated design principle about being supportive rather than prescriptive, which can make things more complex in certain ways, but avoids shoehorning and in that context, tag abuse.
And then we provided tools. So for NISO STS, we have a whole supportive network, the non-normative site NISO STS.org that includes extensive documentation with examples, the schema downloads that can be used to parse the content against the standard and then community listserv. So those are some of the things. OK so supportive rather than prescriptive.
We can't tell people what to do, it's annoying. What, what were some barriers that you think you had to overcome? What was the hardest part about getting it out there and adopted by people? I don't know if I would put that in the past tense. I mean, these things - Wait - how long has it been since you...? I think I've been to one of the promotional events, and that was four years ago, five years ago.
Well, we just released a new version of STS, actually. But these, you know, these things are done by volunteers. We're all juggling multiple demands, and it's like any other work, trying to keep focused. What's realistically feasible or practical? Prioritizing, avoiding various scope creep, interesting ideas that may not be well defined or practical in the given moment.
I mean, something impractical today may be practical in three years. The groups I've worked with have been great. I mean, we defined the scope, the principles, objectives, the working group stood by them and used them as a filter to keep us on track and focused. And with NISO STS, we built off of the journal article tag suite JATS, which is standing on the shoulders of giants.
Seems like a tremendous understatement there. This recommended practice, we probably should have said in the introduction and quote Bill Kasdorf, we call it a Rosetta Stone. So instead of standing on the shoulders of giants. it tries to kind of interpret what the giants are saying, so it creates a vocabulary that's kind of common between all of those standards without creating the crosswalk.
And I'm sure we'll get to that in the Q&A. So tell us, what are some concrete ideas? What should we do? Should we, talk about it probably, but if so, how, and how often? And do you have ideas for where we should go with this? Yeah, I mean, it's outreach. It's building a community. You know, we presented at a number of conferences geared to our potential users like NISO Plus or JATS Con, or other SSP, other markup conferences, and also like monthly NISO teleconferences with STS.
We also had a couple events devoted to standards markup. One was at the Library of Congress in DC and another was in Geneva. That synched up with the publication of version 1.0. After a point, it's not just the working group, members communicating about a standard or recommended practice, but adopters, implementers and vendors. So, you know, really staying plugged in to and listening to that growing community.
And we're going to talk about, thinking about next steps, what could be done to facilitate awareness, use and value. Because without adoption, there really isn't an impact. And without adoption, there isn't interoperability when you get down to it. Yeah and I think that's one of the things that we're hoping is that we're hoping for, is, this group started up pretty big. and then, as I said, a lot of people contributed in the beginning, and then the actual grunt work kind of fell on the shoulders of just a few.
And I think, and I'm including myself in this because I was way more involved in the beginning, than I was when it got to actually reviewing the document again and again. But I'm pretty good advocate, though, so I can help again with the adoption phase. But I think we're hoping to recruit more people and hopefully maybe early adopters. I was thinking of potentially doing a direct outreach to some folks who we think might be interested, and not only get them to adopt the document or even enrich it - I don't know what the process is for making amendments to a document, maybe it's a good follow up question for the wider group.
But, you know, getting some fresh blood basically to help with the project. I don't know if there's going to be offshoots to this project. This is actually something that we mentioned in the recommended practice. There could be, I think, other working groups coming out of this more focused on one particular domain, one of the domains that Michelle listed, or one that could actually build the crosswalks between our vocabulary and particular standards.
We can do all of the standards, but it could be done for one, for JATS for example, if somebody wanted to say, hey, I'm going to add more metadata, video metadata to JATS, that's something that could be done. So I think we're hoping to start a conversation more than just saying, this is what you should do. So I think our document is pretty, sorry, not a document, or, I don't know what to call it now, our Rosetta Stone, that's better.
Our Rosetta Stone is really made to, it's not prescriptive at all. I think it was really built to say, all right, this is the start, this is what we've seen now, how do we make this better. And how do we make it adopted across most people I want to do this. This is NISO Plus and I kind of wanted to give a shout out to NISO and how they facilitate this. I just want to make one thing clear.
I had not done this before; without NISO, this would never have been finished. There is no way that we would have a wonderful document. Now, the process has been great because it was very educational, but also, whenever - it was Nettie Lagace mostly who helped us -, but whenever she saw that the communication started slowing down, she just brought us all together and said, OK, let's do this.
And she was very supportive throughout. So how what's been your experience working within the NISO framework? What other benefits did you get? Well, like you just said, I mean, with NISO, how you get that the support of the team and the infrastructure that they have and again the experience, you know, they've been that Nettie's been pumping out standards and recommended practices for probably well over a decade.
But in reality I think the whole, the idea of consensus standards is geared toward adoption. I mean, you get a broad and balanced mix of people together to come together and come up with a solution to a problem. The work item that you produce is vetted by a NISO topic committee and the NISO voting members. You have the public review, which you guys mentioned.
You have the ANSI and NISO announcements and the voting member review and ballot. And those two events I'd mentioned earlier, those were NISO events. So you get a stamp of approval too. Because to me this is like, if you're going to be publishing a document, you have to have a publisher and NISO is the publisher of this document.
Even though we're the authors, they're are the ones who are saying, hey, this has gone through a quality process where we tried to get all the stakeholders together, etc. So you can trust this content, right? I think it's not there's nothing critical in it. So you can trust this content because it's been done through this process. Very curious about what happens next, though?
We haven't done that yet. Any last words of advice? Generic? Specific? No I mean, you know, the tools, and facilitating use, and promoting it. Promoting it. We have to be just talking to people.
So what we're going to do next is, at the end of this recording, we're going to hopefully have some people in the audience, and we're going to try to engage in a bit of a brainstorm about what we could do. And I'm hoping that people who came to this session have an interest in audio and video. If I'm completely honest, I'm hoping we find some of those fresh recruits from the audience.
So please don't log off, still come, you don't have to do it. So we're going to be talking about how the recommended practice can be promoted. As we've mentioned, speaking engagements by stakeholders and events with NISO, direct outreach. So we would like to talk about this a little bit more detail, maybe come up with some talks that we could do together. We wanted to talk about some potential barriers to adoption and some of it might be the systems.
So I think we didn't really have the systems listed. Sorry, this is not the systems, the vendors who have the peer review systems, or any systems that the content goes through, those will need to adapt as well. So I think that there's going to be key stakeholders because of the content providers say, hey, this is great, I've got all this metadata, but I've got nowhere to put it in the systems that I use.
I do want to talk a little bit about how early video and audio is because it is despite video being around for quite a long time, it's still kind of emerging in our space. That's what we discover. So a lot of times we start from scratch with the publisher and we have to tell them yes, you don't think that this video metadata is important now, but it will be in the future for that reason.
So I do think that this is important. This recommended practice will be important for this. And then finally, will more work come out of this, the crosswalks? Do we do a schema some point, etc.? That's where we would like to talk about in the Q&A. I think that's it for our panel. So yeah, as you suggested, let's turn it over to our discussion.
And everybody can make their way over on our platform to the discussion forum. We'll take it from there. Thanks, everyone. I appreciate the conversation.