pocket_archive/doc/content_model.md

Content model configuration

Note: The scope of this functional area is currently under review. Things may change.

Pocket Archive ships with some predefined content types. For some very simple archives, this may be enough to get started with little or no customization. For a setup which needs to define more numerous or complex content types in a more articulated way, additional types can be defined. Please look at the default model configuration files that come with Pocket Archive.

Each type definition is encoded in a configuration file defining a single content category type. One doesn't have to define all possible types in detail. Pocket Archive provides some basic types, e.g.: Anything (the super-class of them all), Artifact, File, Part, which should not be radically altered, because some basic functionality of the system relies on them. To add more specific definitions, subtypes can be defined. A subtype inherits all the property definitions of its broader model, and adds more specific behavior. An example classification could be: Anything -> File -> Image File -> Scientific Image. Each of the sub-types would only define the special properties of that definition, which add to, or replace, the properties of its broader definitions.

All resources in Pocket Archive must be assigned a content type. If someone has to deal with a resource that doesn't fit in any of the predefined content models, they can asign it the most specific type that they can. At worst, they can put it under Anything. Of course, if one starts dealing with many unclassifiable resources that look similar, it's probably best to define a model for them; but that is not mandatory.

Each metadata field can be specified by constraints. These constraints can be on:

• Type: the data type for the field, e.g. string, number, resource (relationship), etc.
• Cardinality: how many values can be set for a field, for each resource. These values can be adjusted to set mandatory fields, single-valued fields, etc.
• Range: the range of values allowed. How this is interpreted depends on the data type: for a number can be a min/max range, for a string a regular expression pattern, for a resource the type(s) of the resources pointed to, etc.

All of these constraints are optionals. Fields that are not defined may accept any number of values, and are optional. So it's up to the repository manager to decide how specific or how free-form their archive should be.

Note that fields that are not defined at least by a label, may be hard to understand by users browsing the discovery interface.