RAMEN – not just a noodle soup?

The Reusable Abstraction Model for Editorial Needs (RAMEN) is a conceptual model for creating, connecting, and publishing editorial data. It describes how source materials, annotations, entities, collections, and contextual structures can be organised as parts of a digital edition – a structured, critical representation of edited material (cf. Sahle 2016).

RAMEN does not replace established standards such as TEI or IIIF, nor broader models for cultural heritage knowledge, semantic relations, or research data. It provides an editorial layer in which such standards and models can be incorporated where useful. RAMEN starts from the practical needs of editorial projects. It helps projects define which materials they work with, how these materials can be structured, where annotations express scholarly interpretation, which entities are relevant, and how these elements are connected. The aim is not to prescribe one fixed model for all editions, but to provide a reusable abstraction that serves as the conceptual foundation for tools that model, capture, link, and publish editorial data.

Digital scholarly projects often work with editorial data that is connected in practice but distributed across different representations, conventions, and tools. Texts, images, annotations, collections, entities, and connections may each be created and maintained separately, while the conceptual structure that defines their editorial roles often remains implicit. RAMEN makes this structure explicit by providing a shared conceptual model for describing what these parts are, how they function within an editorial workflow, and how they belong together, without reducing them to one format, database structure, or implementation model.

RAMEN – A Shared Conceptual Model

Figure 1. RAMEN shared abstract model

Nodes, Attributes, and Relations

In RAMEN, a node represents an editorial object. Each node has a node label, such as Collection, Content, Annotation, or Entity, and can carry attributes that describe the object more precisely. Relations connect nodes to each other and define how editorial objects are organised, annotated, or referenced.

The shared RAMEN model is built around four basic node types: Collection, Content, Annotation, and Entity. These nodes represent different kinds of editorial objects, while three basic relation types describe how they are connected: PART_OF, HAS_ANNOTATION, and REFERS_TO.

• Collection nodes provide contextual structures. They describe how parts of an edition are situated, grouped, or organised within a project. PART_OF relations express such contextual structures between collections and content objects. Collections can also have annotations through HAS_ANNOTATION and can be referred to by annotations through REFERS_TO.

• Content nodes carry editorial content. A text content node contains textual data; an image content node contains or references image data, for example through a file, URL, or encoded representation. Content nodes provide the material basis that can be captured, segmented, annotated, linked, and published. They can be situated in collections through PART_OF, annotated through HAS_ANNOTATION, and referred to by annotations through REFERS_TO.

• Annotation nodes express editorial statements about other objects. They are attached to collections, content, entities, or other annotations through HAS_ANNOTATION; they can also refer to the objects they describe through REFERS_TO. This makes annotations a central mechanism across the model: they are not limited to one area, but can be used wherever scholarly description, interpretation, classification, or commentary needs to be made explicit.

• Entity nodes represent identifiable objects of scholarly interest, such as persons, places, works, institutions, events, or concepts. Entities can have annotations through HAS_ANNOTATION and can be referred to by annotations through REFERS_TO. They provide the basis for modelling knowledge that extends beyond a single content object or collection.

Modelling Areas

The three modelling areas shown in Figure 1 describe different perspectives on these nodes and relations. Context Modelling focuses on collections and PART_OF structures that situate content within larger editorial contexts; Content Modelling focuses on content-bearing objects and their annotation; Knowledge Modelling focuses on entities, annotations, and REFERS_TO relations that make scholarly interpretation explicit. These areas overlap because content can be situated in collections, annotated, referred to, and connected to entities or other interpretive structures.

Project-Specific Refinement

RAMEN is designed as a reusable abstraction, not as a fixed model that every project has to use in the same way. Projects create their own project models by refining the abstract RAMEN node types and relations into concepts that match their editorial materials, research questions, and publication goals. For example, a project may refine Collection into Letter.

info

Refinement means specialising the shared RAMEN model through inheritance. A refined concept keeps its RAMEN base type and adds a more specific project-level type: a Letter refined from Collection is both a Collection and a Letter, so tools can use both the general RAMEN type and the specialised project type.

The formal rules for refinement, inheritance, constraints, and validation are described in the Specification.

Figure 2. Example of a project-specific refinement from the shared RAMEN model to a correspondence project model

Refinement through Inheritance

The example in Figure 2 shows how the shared RAMEN model can be specialised for a correspondence edition. General node types are refined as project-specific concepts: Witness and Letter are modelled as refinements of Collection, Text as a refinement of Content, and Person and Place as refinements of Entity. Each refined concept keeps its RAMEN base type while adding a more specific project-level meaning.

Not every node type has to be refined. A project may specialise selected concepts, keep others unchanged, or restrict their possible relations. In the example, Annotation remains the general RAMEN type, while other node types are refined.

tip

Refinement should not make a project model unnecessarily granular. Internal textual structures, such as tables, table cells, or line groups, can often remain encoded and annotated within established formats such as TEI.

They should become separate Collection or Content nodes only when they need to be addressed, linked, validated, or published as independent editorial objects.

Restricted Relations and Attributes

The relation types themselves cannot be refined. PART_OF, HAS_ANNOTATION, and REFERS_TO remain the fixed association types of RAMEN. A project model can, however, restrict where these relations may be used. If Witness is modelled as PART_OF Letter, this does not automatically allow Witness to be PART_OF any other Collection subtype. Missing relations cannot be used unless they are explicitly defined in the project model. Projects may add their own relation types, but RAMEN-based tools cannot handle them automatically unless they are explicitly implemented or mapped to RAMEN-compatible behaviour.

Some of these concepts also apply to node attributes. A refined concept keeps the attributes of its RAMEN base type, but can add project-specific attributes where needed. The formal attribute model is described in the Specification.

Project Modelling with NORI

Project-specific RAMEN models can be created with NORI. The tool stores refined node types, allowed relations, attributes, and constraints in a JSON-based model specification that can be used by other RAMEN tools.

See NORI for the modelling tool and the Specification for the technical model format.

Explore the Model Areas

The following pages introduce the three modelling areas in more detail:

• Contextual Structures explains how contextual structures situate and organise parts of an edition.
• Capturing Content explains how content-bearing objects are captured, annotated, linked, and prepared for publication.
• Modelling Knowledge explains how annotations, entities, and REFERS_TO relations make scholarly interpretation explicit.