The current loader is association-centric; i.e. each document is a relationship between two objects. This is useful for the majority of queries.
It would also be useful to have an object-centric loader. (TBD: define yaml in monarch repo). E.g. for monarch-initiative/monarch-app#756 (one row per variant).
Here we would have only one document per object. Relationships would be loaded into a multi-valued field named after the property. This means we have a less generic schema than oban.
Example fields (core):
- id/curie
- label
- category
- type
- type_closure
- description/definition
- synomyms
This would be extended depending on the object type. E.g. for genomic features like variants we may have chrom, start, end (for simplicitly we would flatten to a single reference; for more complexity use cypher). For variants we may have a pathogenicity score. Etc.
@cmungall will define core schema, cc @nlwashington
Note that the mechanism here could be used to load ontology classes; but may as well just use owltools loader for this (cc @hdietze @kltm)
The current loader is association-centric; i.e. each document is a relationship between two objects. This is useful for the majority of queries.
It would also be useful to have an object-centric loader. (TBD: define yaml in monarch repo). E.g. for monarch-initiative/monarch-app#756 (one row per variant).
Here we would have only one document per object. Relationships would be loaded into a multi-valued field named after the property. This means we have a less generic schema than oban.
Example fields (core):
This would be extended depending on the object type. E.g. for genomic features like variants we may have chrom, start, end (for simplicitly we would flatten to a single reference; for more complexity use cypher). For variants we may have a pathogenicity score. Etc.
@cmungall will define core schema, cc @nlwashington
Note that the mechanism here could be used to load ontology classes; but may as well just use owltools loader for this (cc @hdietze @kltm)