Project

General

Profile

Feature #1090

Radiocarbon Dating

Added by Nina Richards about 3 years ago. Updated 17 days ago.

Status:
Closed
Priority:
Normal
Category:
UI
Target version:
Start date:
2019-11-22
Estimated time:

Description

Concept for adding radiocarbon data: "laboratory + sample No.: 14C year ± range BP"

E18 (strategraphic unit) -> P2 (has type) -> E55 (Type) named "radiocarbon dating"
In the link description a JSON notation will be used, like:
{"labId": "VERA", "specId": "23432A", "radiocarbonYear": 2040, "range": 30, "timeScale": "BP"}

Implementation
  • Implement for strategraphic unit
  • Implement for other classes, e.g. find and artifact (separate issue)
  • Calibration with IOSACal (separate issue)

Related issues

Related to OpenAtlas - Feature #1748: Extended Value TypesAcknowledged2022-06-14Actions
Precedes OpenAtlas - Feature #1660: Tool - Age estimationAcknowledged2022-03-21Actions
Precedes OpenAtlas - Feature #1932: Manual: radiocarbon datingAssigned2019-11-25Actions

History

#1

Updated by Alexander Watzinger about 3 years ago

  • Status changed from New to Assigned
#2

Updated by Stefan Eichert almost 2 years ago

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.

#3

Updated by Alexander Watzinger almost 2 years ago

  • Description updated (diff)

Added IOSACal suggestion from Stefan

#4

Updated by Alexander Watzinger over 1 year ago

  • Target version changed from Wishlist to 7.4.0
#5

Updated by Alexander Watzinger 9 months ago

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.

#6

Updated by Bernhard Koschiček-Krombholz 9 months ago

  • Description updated (diff)
#7

Updated by Bernhard Koschiček-Krombholz 9 months ago

Stefan will describe the model. (E59)

#8

Updated by Stefan Eichert 9 months ago

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"}

3. Map it respectively resolve it the following way: E1 (every class in our system that can have a type) - has note P3 - E62 String "{"labId": "VERA", "specId": "23432A", "radiocarbon year": 2040, "error": 30}" - has type P3.1 - E55 radiocarbon dating "string type"

#9

Updated by Alexander Watzinger 9 months ago

  • Assignee changed from Stefan Eichert to Alexander Watzinger

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.

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

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.

#10

Updated by Alexander Watzinger 9 months ago

  • Status changed from Assigned to In Progress
  • Assignee changed from Alexander Watzinger to Nina Richards

Assigning to Nina, we will work together on it anyway but she is the specialist for this issue.

#11

Updated by Stefan Eichert 9 months ago

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.

#12

Updated by Alexander Watzinger 9 months ago

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?

#13

Updated by Alexander Watzinger 8 months ago

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?

#14

Updated by Alexander Watzinger 8 months ago

  • Target version changed from 7.4.0 to 7.5.0
#15

Updated by Stefan Eichert 8 months ago

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.

#16

Updated by Alexander Watzinger 8 months ago

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

#17

Updated by Stefan Eichert 6 months ago

#18

Updated by Nina Richards 6 months ago

  • Target version changed from 7.5.0 to 7.7.0
#19

Updated by Alexander Watzinger 5 months ago

  • Description updated (diff)
#20

Updated by Alexander Watzinger 5 months ago

  • Description updated (diff)

We updated the description and further specified the model and related information.
Stefan Eichert, you might want to take a look at it because the model suggestions differs a little from what was described in #1748. I like this model implementation more because it is "more" CIDOC conform because not using a link type.

#21

Updated by Alexander Watzinger 4 months ago

  • Target version changed from 7.7.0 to 7.8.0
#22

Updated by Alexander Watzinger 3 months ago

  • Target version changed from 7.8.0 to 7.11.0
#23

Updated by Alexander Watzinger 3 months ago

#24

Updated by Alexander Watzinger 23 days ago

  • Description updated (diff)
#25

Updated by Alexander Watzinger 22 days ago

  • Description updated (diff)

Updated the model implementation after discussing it with Nina and Stefan.

#26

Updated by Alexander Watzinger 19 days ago

  • Assignee changed from Nina Richards to Alexander Watzinger
  • Target version changed from 7.11.0 to 7.10.0

I'm taking over this one after having implemented the main functionality with Nina.

#27

Updated by Alexander Watzinger 19 days ago

#28

Updated by Alexander Watzinger 17 days ago

  • Status changed from In Progress to Closed

Also available in: Atom PDF