Indexing Schema
1. Overview
-
-
- In the main table(s) where all the uploaded documents and recordings are stored (PhysicalPiece & PhysicalPieceMedia), custom make and use the PhysicalPieceID and PhysicalPieceMediaID to tag every file and create a relation based on the naming convention.
-
2. Naming Convention
-
-
- Sound/VideoRecording: styleID.artistID.mediaTypeID.albumID.songID
- Photo/OriginalDocument/Document: styleID.artistID.mediaTypeID.notesID
- Reasoning: Playback files have more detailed attributes compared to non-playback files; thus resulting in longer indexing.
-
3. Example
| MediaTypes | ID |
| Photo | 1 |
| Video | 2 |
| Sound Recording | 3 |
| Original Document | 4 |
| Document/Flyer | 5 |
| Style | ID |
| Bebop | 1 |
| Cool | 2 |
| Free | 3 |
| Fusion | 4 |
| Hard Bop | 5 |
| Artist | ID |
| John | 1 |
| Jane | 2 |
| Alex | 3 |
| Joe | 4 |
| Marry | 5 |
Imagine these tables already exist within the database, with some attributes not included. If a volunteer scans an artifact that is a document for cool style made by artist John, the sample indexing in that case would be 2.1.5.x. Now if a visitor visits this artifact on the website, we can suggest other artifacts based on the prefixes in the index. For example, we can recommend other documents from artist John within the cool style genre. Or, we can go a prefix up and recommend anything, regardless of format, that is from artist John and within the cool style.