ontola / ontola/atomic-server

Consistent source of ontological data - default_base_models.json

Open
#552 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
1.6k
Forks
82
Avg merge
10h 34m
Merged PRs (30d)
205

Description

AtomicData.dev classes and properties live in various places:

  • On AtomicData.dev (the server), stored in the KV store of that instance
  • In populate::populate_base_models, which is used for populating the base models (to prevent infinite loop on hosting atomicdata.dev, see #60). This contains only a small number of properties - only these needed to parse default_store.json.
  • In default_store.json, containing most classes and properties.
  • default_base_models.json, which should contain the same properties as populate_base_models. I think we should remove this one.

This causes a few problems:

  • Whenever we create / update a Property or Class, we probably want to update the live version on atomicdata.dev using the GUI. That's the easiest, and it can instantly be used during development. This means that we have to update the default_store.json after that. If we forget to do this, the .json becomes outdated.
  • Contributors may update default_base_models.json without updating populate.rs

Solutions:

  • Remove default_base_models.json
  • Add a CONTRIBUTING.MD section on updating ontological data
  • Come up with a way to generate JSON-AD from atomicdata.dev. Export / serialize from ontology level?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing default_base_models.json, default_store.json, and populate.rs, especially populate::populate_base_models, to identify overlapping ontological data and how each file is used. Review the issue's proposed CONTRIBUTING.MD guidance and the handling of data on atomicdata.dev; done means the source of ontological data is consistent and contributors have clear update instructions.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
databases, documentation
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.