OpenAtlas

Did some work on this and implemented radiocarbon dates in the THANADOS frontend using https://codeberg.org/steko/iosacal this python library.
In order to make it work properly with OpenAtlas we would need to store certain values: Date, Range and SampleNr
We created a value type for this that stores year and range separated by comma.
Maybe we discuss this in the next meeting. One idea would be value types, that also allow for strings, so the sample Number can also be stored.

Just discussed it with Nina. Basically we could use a similar strategy like with sex estimation (make a new OpenAtlas class based on E55).
We should still discuss how the UI implementation and the result should be displayed.
Using IOSACal could be implemented in a next step.

Stefan will describe the model. (E59)

For the conceptual implementation in OpenAtlas and to keep it as generic as possible I suggest:
1. define a new OpenAtlas class e.g. "string type"
2. allow for each of these type hierarchies to define parts of the string with possible validation E.g.

{"labId": "string", "specId": "string", "radiocarbon year": "integer", "error": "integer"}

Alexander Watzinger wrote:

Nina and I took a look at your suggestions and we like it.

So we would link E? -> P3 has note -> E62 String
The last part with the type connection we would skip and instead write into the String itself that it is about radiocarbon dating e.g.
[...]
That way we could use it very generic for other analyses and also don't run into problems with already used types.

Thank you for your input Stefan, assigning to me now.

I would prefer to keep the type connection, so it stays aligned with the CRM model and from within the database one can query for the type. If we implement this similar to previous type links and just add the string to the description, this can probably easily be accomplished. We however should document how to resolve this in the CRM.

Sorry, but I'm a little confused. I was thinking we make a link between some entity to a E62 entity and write the text into the description of the E62 entity.
So we would have multiple E62 entities with different descriptions and wouldn't need to write into link descriptions. Did I miss something?

I think I may have figured out why you want a type attached. Although we track what kind of text it is in the text itself, it could be cumbersome to e.g. find all texts that are related to radiocarbon dating because we would have to look at every text. Adding a type to these texts would solve this. In this case I too think we should use a link to a type instead of writing it to a link description.

Is this what you meant?

Obviously the redmine mails have been blocked as spam. Sorry for the late response. What you wrote is exactly what I mean. This way it can be resolved and further similar types we add can be distinguished better.

Thanks for the feedback and no worries about the delay. Maybe it was a good thing, to let me figure it out myself :)