METADATA MATTERS

<contrib contrib-type="author">
    <name>
        <surname>Mike</surname>
        <given-names>Nason</given-names>
    </name>
    <aff>Scholarly Communications &amp; Publishing Librarian, UNB Libraries</aff>
    <aff-alternatives>Crossref &amp; Metadata Liaison, PKP</aff-alternatives>
</contrib>

we have a lot of ground to cover today...

  • what is metadata?

  • why is it important?

  • schema

  • common errors

  • style vs <syntax />

  • shortcomings

  • ojs/journal metadata

  • where does it go?

  • "better practices"

WHAT IS METADATA?

data about data

data about data a work

Descriptive metadata is descriptive information about a resource. It is used for discovery and identification. It includes elements such as title, abstract, author, and keywords.

definition(s)

Structural metadata is metadata about containers of data and indicates how compound objects are put together, for example, how pages are ordered to form chapters. It describes the types, versions, relationships and other characteristics of digital materials.

definition(s)

Administrative metadata is information to help manage a resource, like resource type, permissions, and when and how it was created.

definition(s)

some examples

apple music

& spotify

photo metadata

photo metadata

Case, Sue-Ellen. “Eve's Apple, or Women's Narrative Bytes.” Technocriticism and Hypernarrative, special issue of Modern Fiction Studies, vol. 43, no. 3, 1997, pp. 631-50. Project Muse, doi:10.1353/mfs.1997.0056.

citations
& references

WHY DOES IT MATTER?

think about how hard it is to find things when you have a poor description of what you're looking for...

garbage in

garbage out

good metadata

  • saves time

  • improves discoverability

    • better indexing
    • more eyes on the work

  • improves preservation

  • "an ounce of prevention..."

am i wrong to assume that you want things to be more easily found?

WHAT IS A SCHEMA?

a SCHEMA is what determines the content you'll describe and how you will describe it.

@article{Case1997,
  doi = {10.1353/mfs.1997.0056},
  url = {https://doi.org/10.1353/mfs.1997.0056},
  year = {1997},
  publisher = {Project Muse},
  volume = {43},
  number = {3},
  pages = {631--650},
  author = {Sue-Ellen Case},
  title = {Eve{\textquotesingle}s Apple,  or Women{\textquotesingle}s Narrative Bytes},
  journal = {{MFS} Modern Fiction Studies}
}

there are a lot of schemas to choose from! varying disciplines use different schema.

  • MODS

  • METS

  • Dublin Core

  • VRA Core

  • JATS

  • Darwin Core

  • Crossref

this should feel a little familiar

academia has not 

made things easy for themselves...

i'm not showing you this to terrify you or anything. i just think it's important to know metadata isn't even handled consistently downstream.

WHERE DO THINGS GO WRONG?

let me ask you a few questions.

when you are writing:


how would you make a title or heading in microsoft word?

when you are submitting:


a metadata field is *required*, but you don't know the information offhand or it doesn't exist. what would you do?

when you are publishing:

 

 

for years, your formerly-print journal listed all authors by first initial and full last name. you've started publishing online. how do you record name metadata?

it's not all on you...

some common issues

problem #1

users do not use ISSNs consistently (or with respect to ISSN requirements) and do not always update title-level metadata

problem #1

feat: labour/le travail

  • In my ILS (WorldCAT): Labour = Travail

  • In Canadian Periodical Index Quarterly (CPI.Q): Labour/Le Travail

  • In Academic Search Premier:
    Labour / Le Travail

  • In JSTOR Arts & Sciences V Collection: Labour / Le Travail

  • In ABI/INFORM Complete (ProQuest): Labour

  • In Canadian Business and Current Affairs (CBCA) Complete (ProQuest): Labour

  • In print: Labour / Le Travail

  • In all online branding: Labour / Le Travail

  • ISSN Registered Name: Labour

problem #2

metadata used inconsistently and, often, as a styling or theming alternative in an attempt to replicate print versions

problem #2

Users put "volume", "issue", or "year" fields in the "issue title" or "description" fields. They do this for any number of reasons, like:

  • Users may want to display their volume and issue numbers in Roman numerals (or whatever unique characters they used in print)
  • Users want to use “Volume” and “Number” instead of “Vol.” and “No.” (the OJS standard display)
  • Users may fill an issue description with any number of things that are not descriptions
  • Users may fill "issue title" with something that is not a title. Intended use of this field is for something like a "special issue title".

problem #3

sometimes poor knowledge of either OJS settings or formatting leads to problematic content in abstract fields.

problem #3

abstracts can be made optional per section of your journal

problem #4

names are very complicated.

problem #4

ORCID helps...

 

... but so will consistency

problem #5

many users either don't understand that OJS has translation features or they believe that having both languages displayed simultaneously is more important.

problem #5

titles, abstracts, keywords, and almost everything else can have translated metadata in OJS… users can pick which language they want to read

problem #6

folks jam some truly wild stuff into title fields

problem #6

i have seen the following in title fields:

  •     dois
  •     urls
  •     author names
  •     multiple languages
  •     html
  •     journal sections

 

title fields are for titles

imagine someone citing your article using citation management software

problem #7

ALL CAPS IS A BAD IDEA FOR METADATA AND IF YOU WANT STYLES IN ALL CAPS THERE ARE BETTER WAYS!

most of the these are really symptoms of the problem

MISTAKING SYNTAX FOR STYLE

when you are publishing content yourself, it is important to remember what happens to it downstream

when you want something in OJS to look a certain way, modify the themes instead of altering the metadata!

lastly, please check out the better practices in journal metadata documentation just released on the pkp documentation hub!

THANKS FOR YOUR TIME