Download the PHP package acdh-oeaw/acdh-repo without Composer

ARCHE-core

The core component of the ARCHE Suite responsible for the CRUD operations and transaction support.

Installation

composer require acdh-oeaw/arche-core

Deployment

See https://github.com/acdh-oeaw/arche-docker

Environment for development

An environment allowing you to edit code in your host system and run all the tests inside a docker container.

• Clone this repo and enter it

• Get all dependencies

• Build the doker image with the runtime environment

• Run the runtime environment mounting the repository dir into it and wait until it's ready

  wait until you see (timestamps will obviously differ):

  then hit CTRL+c

• Enter the docker container and run tests inside it

  and then inside the container

Remarks:

• By default the development environment runs with PHP configured as an Apache mod_php module but it is also prepared to run PHP as the FPM. To adjust the config run (in the host system)

  Similarly to get back to the mod_php config:

REST API documentation

• https://app.swaggerhub.com/apis/zozlak/arche (Swagger/OpenAPI)
• Guides on https://acdh-oeaw.github.io/arche-docs/

Architecture

Database structure

The main table is the resources one. It stores a list of all repository resources identified by their internal repo id (the id column) as well as transactions handling related data (columns transaction_id and state).

Metadata are devided into three tables according to the consistency checks applying to them.

• The identifiers table stores resources' identifiers (the repository assumes every resource may have many). The table enforces global identifiers uniquness. The RDF property storing the identifier comes implicitly from the repository's config.yaml ($.schema.id) and is not explicitly stored inside the database.
• The relations table stores all RDF triples having an URI as an object. It enforces (with a foreign key check) existence of a repository resource an RDF triple points to.
• The metadata table stores all other RDF triples. This table puts no constraints on the data. Triples are stored in an RDF-like way - each row in the table represents a single triple.
  • For triple values which look like a proper number/date the value_n/value_t column stores a value casted to number/timestamp. This allows for correct comparisons which would fail against string values.
  • The index on the value column is set up only on first 1000 characters of the value. This is both for technical and performance reasons. An important consequence is that if you want to benefit from indexed search on the value column, you should state your condition as substring(value, 1, 1000) = 'yourValue'.

Supplementary tables include:

• The transactions table which stores information about pending transactions.
• The metadata_history table which stores history of metadata modification. It's automatically filled in using triggers on tables identifiers, relations and metadata.
• The full_text_search table storing a GIST index on a tokenized metadata values and resources' text content allowing for a full text search (see the Postgresql documentation).
• The spatial_search table storing vector spatial data as PostGIS geography allowing for spatial searches (see the PostGIS documentation).

Helper functions and views

• The metadata_view gathers together triples from both identifiers, relations and metadata tables.
• The get_relatives() function allows easy finding of resources related to a given one with a given RDF property. Internally it uses a recursive query which could be difficult to write correctly on you own.
• The get_neighbors_metadata() and the get_relatives_metadata() functions allow for easy fetching of metadata triples of bot a given resource and resources related to it. Either by any single-hop RDF property (get_neighbors_metadata()) or with any number of hops of a one selected metadata property (get_relatives_metadata()).