Phenoscape semantic phenotype CRUD API

[mjy]

Roughly, as a developer, or user I would like to:

Authenticate to a phenoscape knowledgbase

• use a token or credential (Github?) to gain write access to the data-store

Create, read, update or destroy a phenotype knowledgebase

• Use a (RESTful(?)) approach to CREATE new individual assertions (new semantic phenotypes)
• DESTROY phenotypes I created that seem to be otherwise unused
• UPDATE phenotypes with refinements or clarifications
• READ phenotypes that I've created (this perhaps largely exists)

Use JSON based templates for specific classes of phenotypes

• As a "intermediate" developer I don't want to use RDF, manchester, or other low level representations of semantics, but rather use "templates" (perhaps sensu @balhoff paper) to define/express classes of phenotypes that are most commonly used. For example these may include anatomical points, lines or areas, shapes colors, sizes.

• I need metadata to represent how the semantic phenotype was composed (e.g. what UI was used, was it Phenex, some web-based widget, a script, a VR helmet interface etc.), as we anticipate that interfaces will affect what can be expressed, and that this metadata will be useful in downstream analysis for comparative purposes.

Recieve URIs after POSTing new semantic phenotypes

• I plan to store non-semantic representations (or, perhaps, less semantic representations) of the phenotypes (e.g. natural language, image depictions, qualitative or quantitative phylogenetic characters) in a alternative knowledgbases. I'll need 1) a URI representing the entry point to the semantic phenotype in a phenoscape knowledgebase, and 2) new semantics (SKOS like?) to define the relationship (link) between my representation of the phenotype, and the one stored in the phenoscape knowledgbase.

Assumptions

• The tech behind phenoscape can be containerized (Containerized and reproducible phenoscape backend build #15) and used elsewhere
• Everybody has the same level of access to the knowledgbase, I'm not interested, yet in creating roles and permissions for who can do what. If you have access, you can do what everybody else can.

[mjcollin]

Another path besides opening write access to the store (and addressing who gets that access) is to openly accept annotations on existing data and providing structures to merge "approved" annotations in later and display/hide available annotations to users. TDWG has an interest group that has thought about this in the context of data aggregators: https://github.com/tdwg/annotations

[mjy]

@mjcollin I'm mostly envisioning this for an empty instance of Phenoscape, or one under "my" control, i.e. I really do want to write new data. But, you're totally right as to the "one Phenoscape" approach, maybe we could make your suggestion a new issue? I.e. "Add annotations to Phenoscape"?