Skip to content

Research: Should RepoCore2 kind be repeatable? #1

Description

@andrewmarconi

Context

Currently, RepoCore2's kind property is defined as non-repeatable (cardinality 1):

  • DC TAP: repeatable = FALSE
  • JSON Schema: "type": "string"
  • Django model: ForeignKey (not ManyToManyField)

Problem

Some repositories serve multiple functions and may legitimately need more than one kind:

  • A bookstore that also maintains an archive
  • A distro that also operates as a zine library
  • An infoshop that functions as both a community archive and distro
  • A library with a dedicated zine library collection

Currently, creators must choose only one primary kind, which may not accurately represent hybrid organizations.

Research Questions

  1. Use cases: How common are multi-function repositories in the zine ecosystem?
  2. Modeling options:
    • Make kind repeatable (array of values)
    • Add a secondary_kind or also_functions_as property
    • Use a hierarchical vocabulary (e.g., bookstore::with-archive)
    • Keep single kind but allow more granular values
  3. Interoperability: How do similar schemas handle this?
    • Schema.org allows multiple @type values
    • BIBFRAME uses multiple classes
    • How would this affect JSON-LD representation?
  4. Implementation impact:
    • Changes needed to all five artifacts (DCAP, TAP, Schema, Context, Types)
    • Django migration path (ForeignKey → ManyToManyField)
    • API response format changes
    • Backward compatibility

Examples from Importing Work

Real-world examples encountered:

  • Catland Books (bookstore + occult resource space)
  • McMicken FreeSpace (distro + zine library + community space)
  • Black Mosquito (infoshop + distro)
  • Sticky Institute (distro + event space)

Decision Points

  • Gather data on how many repositories in practice serve multiple functions
  • Evaluate whether existing vocabulary is granular enough or if repeatability is needed
  • Consider whether this applies to other profiles (AgentCore2 roles?)
  • Assess implementation complexity vs. real-world benefit

Recommendation Needed

Should RepoCore2 kind remain singular, become repeatable, or use an alternative approach?

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions