Question #2181
closed
Store analytical data and metadata
Description
Hi,
I come from the background of archaeological science and wonder if the feature about analytical data and associated metadata can be stored.
For example, a sample from a ceramic pottery could have been investigated chemical (XRF) and spectroscopic (Raman) methods. There is a need to associate the analytical data and metadata (instrument settings) with an artefact.
The reason I am suggesting it is because our team is working on the metadata schema for analytical techniques for archaeological samples and the openatlas could potentially a good place to build up such a database.
cheers,
Gary
Updated by Alexander Watzinger 3 months ago
- Tracker changed from Feature to Question
- Status changed from New to Assigned
- Assignee set to Stefan Eichert
- Target version set to Wishlist
We already have a feature that I guess goes into that direction, see Radiocarbon Dating in the manual.
But because this isn't my area of expertise I assigned it to our domain expert @Stefan Eichert, kindly asking about feedback regarding this.
Updated by
Updated by Alexander Watzinger 3 months ago
This is actually an ongoing longer discussion.
My approach would be to implement needed functionality over time similar to Radiocarbon Dating so that data would be stored in a guided and standardized way. So basically creating a feature request for e.g. the spectroscopic (Raman) method, providing some specifications and tell us in case you would be interested to work together with us on this. Depending on complexity and usefulness of the desired functionality we might than implement it so that all projects can benefit of it.
If you find workarounds it may work within your project but than may be difficult to merge/compare your data with other projects.
But lets here what Stefan has to say.
Updated by Stefan Eichert 3 months ago
Updated by Alexander Watzinger 3 months ago
- Assignee changed from Stefan Eichert to Alexander Watzinger
Thank you Stefan for your feedback. I already suspected your answer to that, that's why I mentioned "an ongoing longer discussion" ;) but wanted to include you anyway.
Updated by Alexander Watzinger 3 months ago
- Related to Feature #1748: Extended Value Types added
Updated by Alexander Watzinger 3 months ago
- Status changed from Assigned to Closed
- Target version deleted (
Wishlist)
I took some time to think it through and personally I'm still in favor of implementing each analytical function to provide a guided and standardized way instead of allowing users to "click" them together somehow.
Advantage of a flexible solution- More freedom for users, they don't have to wait for implementation
- Standardized way of using them, designed and documented by domain experts
- More fine grained checks are possible, e.g. like enforcing for a certain value that a string has to be 8 characters and the first has to be a number
- Much easier comparison and merging of data from different projects
- Analytic functionality can be provided, e.g. like we did for "Sex Estimation" (Ferembach), see manual
- Possibility to export data via the API in a standardized way for e.g., use at presentation sites or output in different formats specific to that function
- Non domain expert can use them out of the box without spending a lot of time researching them
Compromise
Of course I also understand the need of users like you (Gary) and Stefan so I was thinking about some compromise and propose that individually issues are created for wished analytic functions.
When implementing the next two or three we try to do it in a way that it would be easier (standardized, modular, documented, ...) to add new functions to the software.
That way more experienced users like Stefan could add them themselves with e.g. pull requests. And after checking them on our side we can add them to OpenAtlas so that everyone can use these.
Thank you again for reporting, I will close this issues but please feel free to add new ones for specific functions or continue the discussion at #1748 about the dynamical approach.