CentreForDigitalHumanities / CentreForDigitalHumanities/EDPOP

Graph and namespace organization

Open
#156 1 comment 0 reactions 0 assignees View on GitHub
design
Dominant language
Python
Stars
1
Forks
1
PR merge metrics
No merged PRs in 30d

Description

This note is based on our discussions on February 21 and March 7 2024. It is not really a separate task, but rather an overview of the way we plan to organize the graphs in the triplestore, so that we can refer to it from other tickets. I took the liberty to fill in some details, but these can still be discussed. Names of the graphs are my own creative suggestions. `edpop:` is the common prefix of all of our IRI terms, likely something along the lines of `https://edpop.hum.uu.nl/rdf/` in production. This should be a Django setting.

## Graphs

- [ ] `edpop:catalogs` describes our catalogs.
- [ ] `edpop:records` contains the original versions of all records as we first extracted them from our catalogs.
- [ ] `edpop:record-updates` contains automated annotations that are added when a later fetch of the same record returns slightly different data.
- [ ] `edpop:collections` describes the collections that exists.
- [ ] `edpop:collection/` declares the records that are members of the collection and contains all user-created annotations that are shared with the research group.
- [ ] `edpop:user/` contains annotations that the corresponding user made for personal use, outside of the context of any particular collection. These annotations are visible but not editable for other users, similar to the option to see annotations that were made to the same record in the context of another collection.
- [ ] `edpop:user//private` contains similarly personal annotations by the corresponding user, but without the option for other users to see them, **if** we decide to implement such functionality.

## Namespaces

- [ ] Catalogs in `edpop:catalog#`. Final part is a short name.
- [ ] Collections in `edpop:collection/`. Final part is a short name. Note: collections-as-nodes go by the same IRI as the corresponding graphs that contain their declared records and annotations.
- [ ] Records in `edpop:record/`. Final part is a serial number.
- [ ] Record update annotations in `edpop:record-update/`. Final part is a serial number.
- [ ] User-created annotations in `edpop:annotation/`. Final part is a serial number.
- [ ] Users in `edpop:staff#`. Final part is the user's `username`. Users need not actually be stored in the triplestore, we can extract usernames from Django's regular PostgreSQL database and serialize to RDF on the fly.

Contributor guide

No contributing guide indexed for this repository

Research direction

No file, test, or implementation entry point is named; start by reading the proposed graph and namespace organization and the discussions from February 21 and March 7, 2024. This issue is an overview rather than a standalone task, so done means reaching agreement on the design and using follow-up tickets for implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
django, postgresql, python
Domain
backend, databases, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.