 Welcome to this presentation on yams.net, which is an open, community-maintained repository of terms and definitions. It's designed to help groups of people quickly reach consensus on the vocabulary they need to get their work done. Yams is not a standard, nor does it compete with standards. Instead, it's an evolving dictionary that any working group from any knowledge domain can use to share, discuss, and agree on terminology. So, who needs a vocabulary builder? The short answer is everyone who needs controlled or machine actionable terms. These are terms that occur in metadata standards in the pick list of a user interface, in spreadsheet column headers, as the nouns and verbs of an API, or in fact any jargon that needs to be machine readable. The longer answer begins with the bold claim that standardized metadata is rare in scientific and heritage institutions. That may seem strange because those institutions will readily tell you which standards they use, but not so readily tell you that they use them as inspiration and guidelines to support their own local internal operations. The old joke that the great thing about metadata standards is that there are so many to choose from is especially appropriate since so many standards have highly localized dialects, occurring at the institution, laboratory, department, and even project level. One barrier to compliance is that each standard is a big bundle. You agree not only to each of its 300 terms and definitions, but also to its grammar rules. It's not easy to unbundle things so that you can pick and choose. Professions and disciplines invest heavily in creating, complying with, and deviating from, metadata standards. With all those dialects, inter-operation is poor. This was noticed as early as 2004 when there were many fewer dialects than today. So where does the yams.net vocabulary builder fit here? Pretty much every group dealing with technology starts by creating working definitions to avoid misunderstandings and wastes of time and money. Our vocabulary builder is a crowdsourced online dictionary of draft terms and definitions, each term getting an ARC identifier permanent link. You are free to use or ignore any term in it. As a foundational substrate for recording, sharing, discussing, voting, and cherry picking, it provides enormous leverage for reaching consensus. Even though yams is only about terms and definitions, it still makes a big chunk of work much easier. Among other things, yams lets institutions come out from the shadows and disclose, with precision and persistence, the internal dialects that they are already using. The official story at institutions using metadata often hides the unofficial story. Our websites and funding proposals proclaim the metadata standards that we use. But when expert scientists, archivists, and catalogers really care about accurate description and have internal workflows to support, standards get modified for local needs. And in rapidly evolving domains, it's not that surprising. Domain models evolve rapidly and experts are the first to find and push against their flaws. Metadata standards evolve slowly and are usually based on models that are already a few years old. So all over the world, unofficial local dialects are emerging and interoperability suffers. Why don't projects, departments, and institutions feed their changes back to standards bodies? Because those bodies aren't always easy to communicate with, and it might take five years for revision to come out that might or might not reflect their institutional inputs. Meanwhile, workflows can't wait, so local dialects go forward. Why don't projects share their changes with the world? Well, maybe they're embarrassed, or maybe it's too hard. It's also hard for recipients to find changes if they're buried inside documents. There's also the unofficial story behind the drafting of metadata standards. In theory, a select group of senior experts gathers to draft a standard and share their wisdom. The reality is basically a very expensive and inefficient design by committee. I know something about this because I led publication of the first three standards to use the word metadata. They were all parts of the Dublin core specification, and every metadata standards process that I've witnessed since then follows a similar antiquated pattern. In that pattern, the committee is composed of senior experts, most of them not current practitioners. Sometimes there are workflow managers, but for many their workflow expertise may have peaked 10 to 20 years ago. That's not so useful in times of rapid change. There's little testing or evidence, just live and online discussion, plus lots of opinion, conjecture, and ego. Despite streamlining reforms that some standard bodies have made, it can still take years to get to version one, more years to version two, etc. The Dublin core aimed to be a lightweight, simple standard of just 15 elements, but it took five years. Things are often out of date as soon as they're published. It's also hard to reach consensus. Committees sometimes agree to stop disagreeing when everyone is tired. With Dublin core, we had essentially the same 15 elements after 10 months as we did after five years. Towards the end, consensus on Dublin core was very fragile. In my opinion, that explains why reasonable requests to add a few more new elements were rejected. Groups were told to go off and create their own vocabularies. That was a fateful decision. As a result, here's the metadata universe that we inherited. Lots of metadata elements, right? But when we zoom in on a given area, we find with dismay that those aren't elements, but entire vocabularies or ontologies with lots of conflicting overlapping elements inside them. Many of the overlapping elements are descended directly from Dublin core. Each point is an island of non interoperation with other points. And it's not just cross-domain vocabularies like Dublin core that spawn dialects, but also narrow domain-specific vocabularies. For example, in cryospheric science, which is all about frozen water, there's disagreement on generalized terms such as glacier and puddle, and on specialized terms such as phrasal ice. Within a narrow domain, it is easy to imagine this kind of divergence arising from institutional or project-level dialects. It happens in any domain where object experts care about accurate description in their area of specialization. These are the current expert practitioners who record and use metadata, the ones whose inputs are most relevant to any standards work. There are many, many voices, however, are not present in standards work. How can we meet these experts where they are and help showcase their inputs, comments, testing, and consensus so that better standards can emerge and evolve quickly? That's why we built yams.net. Yams is neither a standard nor an ontology. Instead, yams is a living dictionary of metadata terms and jargon, accepting all parts of metadata speech from all domains. Unlike an ontology, a dictionary welcomes unrelated terms sitting next to each other. Each term is like a proposed nano-standard. Some are upvoted, others not. Reputation-based voting, which is used in Stack Overflow, helps people, such as standards committees, choose among the best terms. Yams is a term repository that can be reliably pointed into from external sources, such as ontologies and software applications. Instead of hard-coding terms, definitions, and examples, or maintaining them in PDFs, arch-persistent identifiers can reliably reference your cherry-picked terms directly in the place where you maintain them. In this case, you might be your institution's head cataloger of physical samples, or you might be the principal editor of an international standard. This is an example screenshot from Stack Overflow. Here are the controls to use reputation-based voting in order to resist gaming and help developers choose the technical solution that works best for them. In Yams, it helps users choose the term that works best for them. So here's what the Yams interface looks like. It lets anyone look up terms to reference. You could also log in if you want to comment on other people's terms. You can also upvote or downvote terms and watch them, so you get notified if they change. This term is labeled vernacular class, which means it can be changed by the owner, but terms labeled canonical class are done changing. There are also deprecated terms, but they too will always be available because historical documents will always be with us. You can add your own term and immediately walk away with an arch-persistent identifier to reference it. There's no problem creating multiple terms with the same name string. This one has 13 alternates, but each alternate will have a unique arch concept identifier. You can also add tags to terms and import terms in bulk via a CSV file. So while Yams is crowdsourced, there are strong fences. Anyone can add a term, but then they own it completely. No one else can change it. All terms are born in the vernacular. After enough consensus and stability, vernacular terms may become canonical. That means they are much more stable. At some point, most terms will eventually be deprecated, but they never go away because history and historical documents don't go away. Depending on your risk tolerance, you may cite a balance of stable canonical terms and evolving vernacular terms, such as those controlled by you or your community. Again, every term is born with a unique persistent identifier, which stays with it through all of its life stages. This shows some Yams usage patterns for working groups. Let's say you import your group's 300 terms using a CSV file. Each term gets an arc, and you could stop there because maybe all you really wanted was persistent identifiers for each of your terms. You could also take things further by watching for comments and editing your terms and maybe adding new terms. Your group could decide its favorite terms to go forward into a standard. They could look at the votes and comments or ignore them. If you publish your standard, it can link back to Yams.net in case there will be any late-breaking changes. Each term is like a nano-standard. There are also usage patterns for individual practitioners. Whether in a working group or not, you can use Yams directly. After a term search, you might find a term you love and leave as a satisfied user. You might find a term you kind of love and add comments. You can't change someone else's term, but if it's vernacular class, you could ask the author for changes. If you find no suitable term, you can add your own. You could be anybody. Yams is democratic in that all can participate, but weaker terms may not appear very high in ranked search results. You may find a word you love but a totally unsuitable and unchangeable definition, so you could choose to enter the same term again and compete with the original. Here are some discipline-specific groups and institutions that have used Yams to publicize and get feedback about their terms. Their terms all co-mingle in Yams, but they can be viewed as separate subsets by clicking on a tag to just display terms from a given subset. In summary, yams.net is an open, collaborative vocabulary builder. It can be thought of as community-built dictionary or repository of machine-readable vocabulary terms. Anyone can add terms which they then own and edit in response to comments and voting. No one can change your terms except you, and all terms automatically get arch-persistent identifiers. Yams uses reputation-based voting in its aim to be, for metadata practitioners, what stack overflow is for developers. Anyone who has suffered through the vocabulary processes, large and small, knows how dreadful they can be. A huge chunk of those processes is reaching consensus on basic pairings of terms and definition. That's exactly what Yams is for. As a simple substrate of candidate terms with no commitment required, it's an easy place to discuss, test, and vote. When that effort is done, any working group can go forward with whichever terms it wants and only come back to Yams as needed, for example, for help with subsequent revisions. Please reach out if you would like to learn more. Thank you.