Feature #1748
openExtended Value Types
Description
In order to manage types, that require certain additional information I propose the following:
Idea: For e.g. radiocarbon data we need certain values that define the relation between an entity and the respective Type:
E18 physical thing (Wooden bucket) - P2 has type - Radiocarbon dating. The link itself has another property - P3 has note - E62 String
So we can document "Wooden bucket" - {"lab id": "VERA", "sample id": "VERA1234", "14C Years": 1200, "range": "30"} - Radiocarbon dating
This would apply to various cases. E.g. if you have certain measurements with a range like 500 +- 30, Or if you need to document the measuring device, its error or a certain method.
I suggest to define a new openatlas_class type to accomplish that.
When creating a new type like this (only doable by admins), the user defines a number of fields and their attributes: label + type of values (string, integer, float)
The user interface validates them when entered and displays them with the respective labels.
The information could be stored in the description field of the link. E.g. as JSON: {"label1": "string", "label 2": "string", "label 3": INT, "label 4": float}
Updated by Alexander Watzinger over 2 years ago
- Category set to Backend
Thank you for reporting, I put it on the agenda for next meeting: https://redmine.openatlas.eu/projects/uni/wiki/Meeting_2022-06-28
Updated by Alexander Watzinger over 2 years ago
- Status changed from New to Acknowledged
- Target version set to Wishlist
Although we didn't manage to discuss it in depth in yesterday's meeting, I put it on Acknowledged and Wishlist for now.
Updated by Stefan Eichert over 2 years ago
- Related to Feature #1090: Radiocarbon Dating added
Updated by Gary Hsu 9 months ago
Hi,
I would like to carry on the discussion by providing a JSON schema for the anayltical method (developed by the European Infrastructure for Hertiage Science)
{ "identifier":"e-rihs.io/88306943fea7e76f9cd5", "name":"Method", "baseUri":"https://e-rihs.io/schema/method.schema.json", "schema":{ "$schema":"http://json-schema.org/draft-07/schema#", "$id":"https://e-rihs.io/schema/method-v1.0.schema.json", "$code":"2615", "title":"Standard Method", "description":"The schema outlines the required metadata to define a standard method or protocol", "type":"object", "required":[ "preferred_label", "method_version", "creation_date", "technique", "author" ], "properties":{ "$schema":{ "type":"string", "options":{ "hidden":true } }, "id":{ "type":"string", "cordra":{ "type":{ "autoGeneratedField":"handle" } } }, "preferred_label":{ "title":"Preferred label", "description":"Preferred label", "type":"string", "minLength":3, "maxLength":100, "cordra":{ "preview":{ "showInPreview":true, "isPrimary":true } } }, "alternative_labels":{ "title":"Alternative Labels or Names", "description":"Any alternative names or labels for the method, this could be an acronym or a full text name if an acronym is used as the ", "type":"array", "items":{ "type":"string" } }, "method_type":{ "title":"Method Type", "description":"The type of method this represents", "type":"string", "examples":[ "Analysis Method", "Technical Examination", "Research Approach" ] }, "technique":{ "title":"Relevant Technique", "description":"The general technique that this Method is an application of.", "type":"string", "cordra":{ "type":{ "handleReference":{ "types":[ "Technique" ] } } } }, "method_version":{ "title":"Version", "description":"The version identifier for this method", "type":"string" }, "creation_date":{ "title":"Creation Date", "description":"The date this method was created", "type":"string", "format":"date" }, "author":{ "title":"Author", "description":"A relevant person ID, either a local database ID or an ORCID, for the creator or author of this method", "type":"string", "format":"url" }, "related_tools":{ "title":"Related Tools", "description":"The key related tools (Equipment or Software) described associated with this method", "type":"array", "items":{ "title":"Tool", "type":"object", "properties":{ "tool_pid":{ "title":"Tool PID", "type":"string" }, "tool_role":{ "title":"Tool Role", "type":"string", "examples":[ "Main Equipment", "Detector", "Data Processor", "Peak Detector" ] } } } }, "method_documentation":{ "$ref":"https://e-rihs.io/schema/document.schema.json" }, "method_parameter":{ "title":"Core Method Parameters", "description":"A list of the core or key equipment or software parameters used within this method. This does not need to be an exhaustive list and can be limited to the parameters which are used to control the activity, might influence subsequent interpretations or will be important for data comparison and discovery.", "type":"array", "items":{ "title":"Parameter", "type":"object", "properties":{ "parameter_value":{ "title":"Value", "type":"string" }, "parameter_unit":{ "title":"Unit", "type":"string", "examples":[ "none", "cm", "nm", "count" ] }, "parameter_type":{ "title":"Parameter Type", "type":"string", "examples":[ "working distance", "wavelength", "signal count" ] }, "parameter_related_tool":{ "title":"Parameter Specific Related Tool", "description":"When multiple Tools are used within a single Method defined parameters can be associated to the relevant tool. This can be left blank for single tool Methods and the assumption will be that the parameters are associated with single tool related to the Method in general.", "type":"string" } } } } } }, "javascript":"const cordra = require('cordra');\nconst schema = require('/cordra/schemas/Method.schema.json');\n\nexports.beforeSchemaValidation = beforeSchemaValidation;\n\nfunction beforeSchemaValidation(object, context) {\n object.content.$schema = schema.$id;\n return object;\n}" }
In principle, each method would have their only parameters (as controlled vocab list,preferably the SKOSMOS endpoint) and can be linked to the tool (equipment and software) and technique. There are also two schemas to describe the tool and technique, which I did not include here. I am currently working on generating the controlled list for the selected methods.
Is it something that can be achieved by the future development of OpenAltas?
Updated by Alexander Watzinger 9 months ago
I took the liberty to format the code from before. This can be done with the pre button and helps with readability.
Updated by Alexander Watzinger 9 months ago
- Related to Question #2181: Store analytical data and metadata added
Updated by Gary Hsu 9 months ago
Correct my naive idea if I am wrong.
Since OpenAtlas supports SKOMOS, can we just create one specific for analytical methods?
For example, there is one called chemcial ontology method (https://www.ebi.ac.uk/ols4/ontologies/chmo) which defines each technique (but without the parameter settings). Can I produce some sort of similar ontology and import it as a custom type?
Updated by Bernhard Koschiček-Krombholz 9 months ago
If they have a SKOSMOS API available, it should be possible. Do you know the endpoint or maybe the Swagger/OpenAPI definition?
Updated by Gary Hsu 9 months ago
One of the ontologies I want to incorporate is "Analytical methods for geochemistry and cosmochemistry" in Research Vocabularies Australia.
I think I found something similar to the Swagger but I am not completely sure whether a SKOSMOS API is provided. Do you mind briefly checking it out?
https://documentation.ardc.edu.au/rva/accessing-the-vocabulary-registry-api
That would be very helpful to include them.
Many thanks,
Gary
Updated by Gary Hsu 9 months ago
Sorry, I would like to update my question by providing swagger documention.
Chemical Ontology Method:https://www.ebi.ac.uk/ols4/swagger-ui/index.html
Research Vocabularies Australia: https://vocabs.ardc.edu.au/registry/swagger-ui/#/
Are they something you are asking for?
Updated by Bernhard Koschiček-Krombholz 9 months ago
I'm looking for a Skosmos API that looks like this: https://vocabs-api.acdh.oeaw.ac.at/
This is the example on which we adapted the vocabs import.
I will look into the links you provided.