Specification Overview

The ZineCore2 specification consists of four Dublin Core Application Profiles (DCAPs) that define how to describe zines, creators, holdings, and repositories using structured metadata.

What is a Dublin Core Application Profile?

A Dublin Core Application Profile (DCAP) is a formal specification that:

1. Selects metadata elements from Dublin Core and other vocabularies
2. Constrains how those elements can be used (required vs. optional, single vs. repeatable)
3. Adds domain-specific extensions where Dublin Core alone isn't sufficient
4. Documents the decisions and mappings in a machine-readable format

Think of it as a recipe: Dublin Core provides the ingredients (title, creator, date, etc.), and the DCAP provides the instructions for how to combine them for a specific purpose (in our case, describing zines).

Why Dublin Core?

Dublin Core is a globally recognized metadata standard used by:

• Library catalogs worldwide
• Digital repositories (DSpace, Fedora, Islandora)
• Cultural heritage institutions
• Government data portals
• Academic publishing platforms

By building on Dublin Core, ZineCore2 ensures interoperability with these existing systems while adding zine-specific functionality.

The Four Profiles

ZineCore2 divides zine metadata into four distinct but interconnected profiles:

1. ZineCore2 — Describing Zines

The bibliographic profile for zines and DIY publications.

Describes: Titles, creators, dates, subjects, genres, series information, physical descriptions, rights

Example: Mutate Zine #3: Abortion Stories by Judith Arcana, published 2024, genre: personal zine, subject: reproductive rights

View ZineCore2 Profile →

2. AgentCore2 — Describing Creators

The authority profile for people, collectives, and organizations involved in zine creation.

Describes: Names (display, legal, pseudonyms), agent types, roles, biographical information, identifiers (ORCID, Wikidata), websites

Example: Judith Arcana, person, roles: creator/editor, ORCID: 0000-0001-2345-6789

View AgentCore2 Profile →

3. HoldingCore2 — Describing Physical/Digital Copies

The holdings profile for specific copies held by repositories.

Describes: Which repository holds which zine, call numbers, condition, access status, circulation rules, digitization permissions

Example: UC Berkeley Library holds 2 copies of Mutate Zine #3, call number PS3551.R34 M88, Reading room only, Can digitize with permission

View HoldingCore2 Profile →

4. RepoCore2 — Describing Repositories

The institutional profile for libraries, archives, distros, and collections.

Describes: Repository names, types, locations, institutional identifiers (MARC codes, ISIL, ROR), contact information, holdings scope

Example: UC Berkeley Library, type: academic library, MARC code: CU, ISIL: US-CU, specialization: alternative press

View RepoCore2 Profile →

Why Four Separate Profiles?

You might wonder: why not one big profile for everything?

Reason 1: Normalization

Separating entities prevents data duplication. If Judith Arcana created 50 zines, we document her biographical information once in AgentCore2 and reference it from all 50 ZineCore2 records.

Reason 2: Different Use Cases

Not everyone needs all four profiles:

• A zinester cataloging their own work might use ZineCore2 only
• A library needs all four profiles to track holdings across collections
• A digital archive might use ZineCore2 + AgentCore2 without physical holdings

Reason 3: Granular Permissions

Different metadata may have different privacy requirements:

• ZineCore2 records are usually public (for discovery)
• AgentCore2 may include private information (legal names, contact details)
• HoldingCore2 tracks internal information (barcodes, condition notes)
• RepoCore2 describes public institutions

Reason 4: Independent Evolution

Each profile can be updated independently. Changes to HoldingCore2 (adding a new access status) don't affect ZineCore2 records.

How Profiles Connect

The profiles form a network of relationships:

graph LR
    Z[ZineCore2] -->|creator| A[AgentCore2]
    Z -->|contributor| A
    Z -->|publisher| A
    H[HoldingCore2] -->|zine_id| Z
    H -->|repository_id| R[RepoCore2]

These relationships enable queries like:

• "Show me all zines by this collective" (AgentCore2 → ZineCore2)
• "Which libraries hold this zine?" (ZineCore2 → HoldingCore2 → RepoCore2)
• "What's in this distro's collection?" (RepoCore2 → HoldingCore2 → ZineCore2)

The Five Pillars Pattern

Each profile is published as five synchronized artifacts:

When to Use Each Artifact

• DCAP Narrative — Understanding the specification, documentation
• DC TAP Table — Crosswalking to other standards (MARC, MODS, EAD)
• JSON Schema — Validating JSON records with AJV or jsonschema libraries
• JSON-LD Context — Expanding to RDF, semantic web applications
• TypeScript Types — Type-safe development in JavaScript/TypeScript

Learn more about the Five Pillars →

Controlled Vocabularies

ZineCore2 includes eight controlled vocabularies to ensure consistency:

1. Subjects (~150-300 terms) — Topical terms for zine content
2. Genres (18+ types) — Zine format types
3. Rights Statements — Copyright and licensing
4. Agent Kinds — Person, Collective, Organization
5. Agent Roles — Creator, Editor, Illustrator, Publisher, etc.
6. Repository Kinds — Library, Archive, Distro, Personal Collection
7. Holding Access Statuses — Reading room only, Loanable, Restricted, etc.
8. Holding Distro Statuses — Can duplicate, Can digitize, etc.

All vocabularies follow the W3C SKOS standard and are available in multiple formats (JSON, JSON-LD, SKOS/Turtle, CSV).

Browse Controlled Vocabularies →

Standards Compliance

ZineCore2 aligns with established metadata standards:

Dublin Core

All profiles use Dublin Core terms (dcterms:) as their foundation:

• dcterms:title, dcterms:creator, dcterms:date
• dcterms:subject, dcterms:type, dcterms:format
• dcterms:rights, dcterms:language, dcterms:description

Profile-specific extensions use the zine:, zine-agent:, zine-holding:, and zine-repo: namespaces.

JSON-LD & Semantic Web

Every profile includes a JSON-LD context mapping field names to URIs:

{
  "@context": "https://zinecore.org/v2/zine",
  "title": "Mutate Zine",
  "creator": ["Judith Arcana"]
}

This enables integration with:

• RDF triple stores
• SPARQL queries
• Linked data platforms
• Semantic web applications

BIBFRAME

ZineCore2 aligns with BIBFRAME 2.0 concepts:

• ZineCore2 ≈ BIBFRAME Work
• HoldingCore2 ≈ BIBFRAME Item
• AgentCore2 ≈ BIBFRAME Agent
• RepoCore2 ≈ BIBFRAME Organization

Schema.org

Profile mappings to Schema.org:

• ZineCore2 → schema:CreativeWork, schema:Book
• AgentCore2 → schema:Person, schema:Organization
• RepoCore2 → schema:Library, schema:ArchiveOrganization

Versioning & Stability

ZineCore2 follows Semantic Versioning:

• Major version (v2.0.0) — Breaking changes to profiles
• Minor version (v2.1.0) — Backward-compatible additions
• Patch version (v2.0.1) — Fixes and clarifications

Current version: 2.0.0

All URIs and namespaces are versioned (/v2/) to ensure stability. Old versions remain accessible indefinitely.

Field Naming Conventions

Extensibility

While ZineCore2 provides comprehensive metadata elements, you may need to add custom fields:

Add Custom Properties

{
  "title": "Mutate Zine",
  "creator": ["Judith Arcana"],
  "custom:acquisitionPrice": "$5.00",
  "custom:donorName": "Jane Smith"
}

Use your own namespace (custom:) to avoid conflicts.

Extend Vocabularies

Controlled vocabularies can be extended locally:

{
  "subject": [
    "feminism",
    "reproductive-rights",
    "local:campus-activism"
  ]
}

Prefix local terms with local: to distinguish them from canonical terms.

Next Steps

• Profiles Overview — Learn about the Five Pillars pattern and how to read schema tables
• ZineCore2 Profile — Complete bibliographic specification for zines
• Controlled Vocabularies — Browse all eight vocabularies
• Downloads — Get schemas, contexts, and TAP tables