Data model: Difference between revisions
NateParsons (talk | contribs) |
No edit summary |
||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
The Miranda Digital | == Beta Data Schema == | ||
The Miranda data schema is a work in progress as we experiment with and evolve our approach to harmonizing different kinds of digital assets into a user-friendly format that is both accurate and understandable. [[:File:Miranda Import Schema, Annotated.pdf|This is our current import schema,]] written up by the ParsonsTKO team and developed in close collaboration with Folger team members. We expect to update the schema prior to project conclusion. | |||
== Notes from the Prototype Data Model == | |||
The Miranda Digital Asset Platform prototype was designed to support an arbitrary number of different content types, each defined via a JSON schema. Each of these content type objects is stored within a NoSQL field within a postgresql table that contains a variety of other fields that help manage the data access rules around that content and provide metadata about when that content was last imported into the system from an external source or edited within the DAP. | |||
So each record consists of: | So each record consists of: |
Latest revision as of 11:48, 14 January 2019
Beta Data Schema
The Miranda data schema is a work in progress as we experiment with and evolve our approach to harmonizing different kinds of digital assets into a user-friendly format that is both accurate and understandable. This is our current import schema, written up by the ParsonsTKO team and developed in close collaboration with Folger team members. We expect to update the schema prior to project conclusion.
Notes from the Prototype Data Model
The Miranda Digital Asset Platform prototype was designed to support an arbitrary number of different content types, each defined via a JSON schema. Each of these content type objects is stored within a NoSQL field within a postgresql table that contains a variety of other fields that help manage the data access rules around that content and provide metadata about when that content was last imported into the system from an external source or edited within the DAP.
So each record consists of:
- A row within the postgresql content table
- Within that row, a field that contains the JSON for the content type
- Within that JSON,
- a set of core metadata fields specific to that content type
- a set of fields identifying connections between this record and other records
- a set of fields identifying connections between this record and any binary files managed by the system
Database Schema
Name | Type | Description |
---|---|---|
id | integer | Serial identifier in the database for relational indexes. Not for use in API. |
id_dap | uuid <guid> | Universal identifier for the DAP record across services. Used to request records by ID in API. |
date_created | datetime | On first insertion. Do not change this on updates. |
date_updated | datetime | On first insertion set to the same exact value as date_created. |
type | string | The record type allows well-indexed querying to differentiate by some top-level categorization of records. It is also a lookup identifier for record-specific configuration or logic.
Types include: content (a content item), collection (a set of content items, grouped together to demonstrate a related collection for users), container (a means of organizing a sub-set of related items as part of a larger content record. |
metadata | jsonb | The full schema-compliant metadata record. It should include everything needed for surfacing this discrete item in the API or pushing to the search index. (Excluding questions of related records.) |