Use of Date() function for occupation span

407 views
Skip to first unread message

James Conolly

unread,
May 27, 2021, 12:42:19 PM5/27/21
to OxCal

Hi All

I'm reviewing a paper in which the authors use the function Date( ) to obtain a posterior estimate of the occupation date range of a phase. The use of Date( ) to obtain a posterior estimate (rather than a prior) seems to be based on the wiggle match example in the documentation here:


I checked the cited references (BR et al 2004, and Manning et al 2006) for the use of Date() as posterior estimates, but it is not used in either (from what I can see). In BR (2009, Fig 2), Date( ) is listed as  probability density function, but it isn't used in any of the examples to obtain posterior estimates, although of course, Boundary( ) is.

In the paper I'm reviewing, the basic structure of the use of Date( ) is:

Sequence( )
    {
     Boundary("S");
     Phase("R")
     {
      R_Date("A", 1000, 20)
      R_Date("B", 1050, 20)
      R_Date("C", 1080,20)
      };
      Date ("Date R");
      Interval ("Interval R");
     };
     Boundary("T");
    };

And if this is run, "Date R" returns AD 866-1137 (95.4%). Normally, I would just use the Boundary function to obtain an estimate of the end date of a phase (i.e., in this example, AD 991-1212 (95.4%).

I have two questions: (1) can you use "Date" to obtain posterior estimates of dates of occupation (as in the documentation example, it seems to be related to wiggle matching felling dates)?; and, if so, (2) what is this function based on?

Thanks very much for advice.

Cheers, James


James Conolly

unread,
May 27, 2021, 12:52:13 PM5/27/21
to OxCal
Apologies, my example code has a sloppy error: it should be:

Sequence( )
    {
     Boundary("S");
     Phase("R")
     {
      R_Date("A", 1000, 20);
      R_Date("B", 1050, 20);
      R_Date("C", 1080,20);
      Date ("Date R");
      Interval ("Interval R");
      };
     Boundary("T");
    };

James

Richard Staff

unread,
May 28, 2021, 4:27:52 AM5/28/21
to OxCal
Dear James,

It is absolutely acceptable to use the Date function to derive posterior ages that themselves lack any prior measurement information. Perhaps this is more intuitively understood in the context of (palaeoenvironmental) sediment cores, so tweaking some example code from the OxCal help file:

  P_Sequence(1)
  {
   Boundary();
   R_Date("A",2023,20){ z=70; };
   R_Date("B",1961,20){ z=60; };
   R_Date("C",1999,20){ z=50; };
   Date("D"){ z=40; };
   R_Date("E",1954,20){ z=30; };
   R_Date("F",1936,20){ z=20; };
   R_Date("G",1948,20){ z=10; };
   R_Date("H",1925,20){ z=0;  };
   Boundary();
  };
A-C and E-H are 14C-dated samples, and D represents a given depth that we are interested in knowing the age of (e.g., for sedimentological reasons, or palaeoenvironmental proxy reasons).

An old paper of mine (Radiocarbon 53 (3), 511-528) has a real example of this [model coding given in Appendix 1] when we were interested in the 14C-inferred ages of a specific tephra layer within our core, as well as the pollen-inferred Holocene onset. [There isn't anything special about this paper - there will be lots of other similar examples out there!]

I have also been involved in the modelling of archaeological contexts that have implemented the Date function as you have described James. However, more caution needs to be applied here. Using the Date function in this way provides a probability density function for an undated sample from the Phase, which essentially gives you a range that spans the entire Phase, and is a good way of visualising what is going on. However, by definition, the Date comes chronologically after the preceding Boundary and chronologically before the terminal Boundary. The age range on that Date function will therefore be slightly truncated compared to the full duration of the Phase, which is presumably what the authors in the paper are actually interested in? In which case, the Interval function (that is already included within the model) would give the correct duration of the Phase. Or else, the same distribution can be derived from using a Difference function.

I hope that helps!

All the best,

Richard 🙂

Dr Richard Staff
Research Fellow in Quaternary Geochronology
Scottish Universities Environmental Research Centre (SUERC)
University of Glasgow
Tel.: +44 (0)1355 270198

   Researchgate Free Icon of SuperTiny  


From: ox...@googlegroups.com <ox...@googlegroups.com> on behalf of James Conolly <jamesc...@gmail.com>
Sent: 27 May 2021 17:52
To: OxCal <ox...@googlegroups.com>
Subject: Re: Use of Date() function for occupation span
 
--
You received this message because you are subscribed to the Google Groups "OxCal" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oxcal+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/oxcal/55f129d7-06a7-44d7-963b-d9a809327543n%40googlegroups.com.

MILLARD, ANDREW R.

unread,
May 28, 2021, 4:37:21 AM5/28/21
to ox...@googlegroups.com

Hi James,

 

The Date() function in both these examples gives the posterior for the date of an event  which is not directly dated but has temporal relationships to other events expressed by the prior in the model. For the wigglematch example in the manual the prior information is precise, and this event is 5 years after the final C14-analysed ring. For your example it is the date of an event known only to fall between the boundaries S and T. This gives a vague idea of when the phase was, but it does not express our full knowledge, as its distribution is a convolution of the distributions of S and T. Any summary of Date R, like the 95% interval, appears to give exact start and end dates for the phase, but these conceal the fact that S and T are uncertain and have different uncertainties. That Date R does not represent the range of a phase can be shown by a simple model. If we know that S=1050, T=1150 then the date range of Phase R is known to be 1050-1150, and the posterior for Date R is U(1050,1150). This makes Date R’s 68.7% range 1066-1134 and its 95.4% range 1052-1148, neither of which is the known range of Phase R. In real models with greater uncertainty this problem is partly concealed by the uncertainty of the results but it is still there.

 

Best wishes

Andrew

--

Dr. Andrew Millard

Associate Professor of Archaeology, and

Designated Individual under the Human Tissue Act,

Durham University, UK

Email: A.R.M...@durham.ac.uk 

Personal page: https://www.dur.ac.uk/directory/profile/?id=160

Scottish Soldiers Project: https://www.dur.ac.uk/scottishsoldiers

Dunbar 1650 MOOC: https://www.futurelearn.com/courses/battle-of-dunbar-1650

 

 

From: ox...@googlegroups.com <ox...@googlegroups.com> On Behalf Of James Conolly
Sent: 27 May 2021 17:52
To: OxCal <ox...@googlegroups.com>
Subject: Re: Use of Date() function for occupation span

 

[EXTERNAL EMAIL]

--

Erik Marsh

unread,
May 28, 2021, 8:32:41 AM5/28/21
to OxCal
Hi James,
I have run into this, too. The Date() function is fine as part of a sequence, as in the manual example and Richard's core. But not as part of a phase! I once tried to do the same thing (and was corrected), since for a short phase it gives a date that falls in the middle and seems like a good summary date. But as Andrew describes in better detail, this is incorrect. You're right, boundaries could be used, but I would also suggest trying other queries: First, Last, and Span. A better choice for summarizing a phase would be a KDE plot. In this case, the Date() function and KDE have the same median and nearly identical shapes:

Untitled.png
So I think – someone correct me here – you could use this median to indicate the central tendency of the phase, as long as you are clear, as Andrew points out, this does not represent the phase's span or error ranges. Nor could you use the probability range of Date(R). In this example, the boundaries have large error ranges, so ignoring them seems like a bad idea. This brings us back to Bronk Ramsey's (2017:Fig 3) suggestion for summarizing phases: stack the boundaries and the KDE plot.

Untitled 2.png
Hope this helps
Erik

Christopher Ramsey

unread,
May 28, 2021, 9:11:53 AM5/28/21
to OxCal group
I think it is still fine to use it in a Phase but you just need to be clear what it means. It is certainly no guide to the length of the phase and cannot be used as a substitute for the boundaries but it does give our best estimate for the date of an undated object within that phase. It can also be a useful visual summary of the information from the boundaries (particularly if they are distinct and not overlapping) : but for this purpose you should ignore the ranges.

This is briefly covered in:

Bronk Ramsey, C. (2017) Methods for Summarizing Radiocarbon Datasets. Radiocarbon, 59(2), pp.1809-1833. doi:10.1017/rdc.2017.108

Best wishes

Christopher

> On 28 May 2021, at 13:32, Erik Marsh <erik....@gmail.com> wrote:
>
> Hi James,
> I have run into this, too. The Date() function is fine as part of a sequence, as in the manual example and Richard's core. But not as part of a phase! I once tried to do the same thing (and was corrected), since for a short phase it gives a date that falls in the middle and seems like a good summary date. But as Andrew describes in better detail, this is incorrect. You're right, boundaries could be used, but I would also suggest trying other queries: First, Last, and Span. A better choice for summarizing a phase would be a KDE plot. In this case, the Date() function and KDE have the same median and nearly identical shapes:
>
> <Untitled.png>
> So I think – someone correct me here – you could use this median to indicate the central tendency of the phase, as long as you are clear, as Andrew points out, this does not represent the phase's span or error ranges. Nor could you use the probability range of Date(R). In this example, the boundaries have large error ranges, so ignoring them seems like a bad idea. This brings us back to Bronk Ramsey's (2017:Fig 3) suggestion for summarizing phases: stack the boundaries and the KDE plot.
>
> To view this discussion on the web visit https://groups.google.com/d/msgid/oxcal/eee48944-2586-477d-8430-b4ba6c5ce70dn%40googlegroups.com.
> <Untitled 2.png><Untitled.png>

James Conolly

unread,
May 28, 2021, 9:44:08 AM5/28/21
to OxCal
Thanks all --- that's very informative. I very much appreciate your help. James
Reply all
Reply to author
Forward
0 new messages