Featured Title:
Stones Playing Cards, great gift idea |
 |
| From Carnac to Callanish: Prehistoric Stone Rows, Aubrey Burl |
 |
| Login |
|
Don't have an account yet? You can create one. As a registered user you have some advantages like your own home page, fewer ads, and your contributions link to your page. |
| Who's Online |
There are currently, 114 guests and 1 members online.
You are a guest. To join in, please register for free by clicking here |
| |
Moderated by : Andy B , TimPrevett , sem , Klingon , coldrum , bat400 , TheCaptain , Runemage , SolarMegalith , davidmorgan
The Megalithic Portal and Megalith Map : Index >>
Portal Talking Shop >> Storing Temporal Data
|
 |
| Author |
Storing Temporal Data |
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
 OFF-Line
|  Posted 05-07-2012 at 19:14
MichaelJachan writes:
Dear Andy,
i am Michael, also an engineer (statistics). I would like to become a contributing member of megalithic.co.uk, because i would like to download your total database of sites (world-wide). I am writing my own database application, which is a spatio-temporal database. It can storte locations, and for each location it can store "Events", ie temporally tagged information about what happened on this site. Of course, i am not eager of creating yet another dataset from scratch, i would like to import your dataset into my database.
As far as i have seen, your data is without temporal info. I mean, if i view a certain article (http://www.megalithic.co.uk/article.php?sid=XXXXXXX), there is no structured info on when the site was erected. (this info could be obtained by archeologers).
Thus, i have the following question to you: Could you extend your data scheme such that you give structured temporal info? Here is an example of what i would wish (my wish is marked by ****)
Site Name: Druidsfield
Country: Scotland County:
Aberdeenshire Type: Stone Circle
Map Ref: NJ578177
Landranger Map Number: 37
Latitude: 57.248036N
Longitude: 2.700961W
*** ERECTED/ CONSTRUCTED: 1234 BC ***
I understand that you are not changing your websystem for my 10 Pounds per year. But i would like to hear your opinion on this extension of the data scheme.
PS: your site is wonderful!
Best, Michael,
[ This message was edited by: Andy B on 2012-07-06 12:37 ]
 Profile
 Email
 Reply
|
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
OFF-Line
| Posted 05-07-2012 at 19:16
Hello, we have considered adding temporal data in the past and I agree it is a good idea. We would be interested in adding this, especially if we could have some help with compiling the data.
The main problem is how to express spread or 'vague' dates, which need an indication of the level of accuracy. I think a single field with a data would become very misleading as it would imply much more accuracy than is generally known. We would need it to be input as a min date and a max date, or possibly a mean with a +/- spread. At its most complex, an archaeological date is expressed as a Bayesian date with a probability graph of the likely distribution.
I have been reading this book, which has a lot of Bayesian dates in it:
http://www.oxbowbooks.com/bookinfo.cfm/ID/90596/OnlyResult/Yes//Location/Oxbow
That is over complex for our purposes - so I would see it being stored as two fields, mean date and spread assuming a normal distribution as a simplification. Do you know of a standard notation to indicate or store this sort of temporal data?
We've not made any progress on this as it is such a massive task to start but actually adding the empty fields to be filled in is not that hard to do. We would much appreciate some help - how many sites would you be looking to add temporal data on?
Thanks
Andy
Profile
Email
Reply
|
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
OFF-Line
| Posted 05-07-2012 at 19:19
You can see an example of the sort of dating that is now being done here:
http://www.english-heritage.org.uk/daysout/properties/waylands-smithy/history-and-research/radiocarbon-dating/
http://www.english-heritage.org.uk/content/imported-docs/p-t/image1.pdf
(PDF file)
This would need significant simplification of course
Thanks
Andy
Profile
Email
Reply
|
bat400
Joined:
10-04-2006
Messages: 1349
from South Central Indiana, US
OFF-Line
| Posted 06-07-2012 at 04:35
Andy - As you say, this is quite a task, although I agree that using two fields, spread and mean date is the best idea.
Selecting a particular location ( a small area) as a first test case would be the only way I would suggest that we approach this, if we are in agreement to do it.
Profile
Reply
|
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
OFF-Line
| Posted 06-07-2012 at 12:12
Re: Re: Temporal Data
Good Morning Andy,
thx for your reply. Let me give you my opinion. Yes, the main problem is about estimated dates. You have proposed to store the mean and the standarddeviation (== Gaussian). But i think this is on the one hand too simple, on the other too complex.
ad too complex: we shall not go to the level of storing/describing a temporal distribution, because it is too complex. Second, the Gaussian model is not sufficient. i vote for entering mindate and maxdate, where both are then expressed as punctual estimates. You aseked whether i know about a standard notation of these datings. no, i dont, but i think that mindate/maxdate is very common.
ad too simple: a megalithic site can be constructed in several phases (ala Stonehenge, see wiki-article). Thus, for each phase of construction, i would like to have the above stated min/max date-fields.
In my application, i have exactly the above stated data relationship: For the Localiton Stonehenge i can have several events (phases), where for each event a time range (min/maxdate) can be entered.
Here is an example of my serialized data, ie one phase of Stonehenge. I have entered the data manually from wikipedia.
-3500
-3400
Stonehenge, UK
Phase 0: Stonehenge Cursus
I the XML-Fields and i have stored what i mean with mindate and maxdate in this email.
Do you have contact to professional archeologers (i do not, i am a hobbyist), which could review my approach of storing dates?
You further asekd: how many sites would you be looking to add temporal data on?
Well, i have to enter the data from wiki into my database. Thus, i could change my task and enter it into yours. I cannot estimate how many sites i will do per year ...
Shall we move this discussion into your forum? sorry, i have not even looked into it yet...
Many thanks for your time!
Best, Michael
Profile
Email
Reply
|
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
OFF-Line
| Posted 06-07-2012 at 12:29
Hello Michael,
Stonehenge is not a very typical example of the sites we list, however I can see the benefit of having more than one date per site. This could work in a similar way to our site visit log where I created a linked table to hold the new data and we allow more than one visit log to be added per site, and these are all displayed together.
Each date entry could also include some text and possibly a site type field and this might form a way of solving the age old problem on what to do when there is more than one type of site in a particular location.
Storing min and max is basically saying we would simplify as a rectangular distribution.
I would propose storing the dates internally as a central date and a date deviation (+/- years) which could be translated for viewing to either
3450 BC +/- 100 years (or BCE?)
or displayed as 3500 to 3400 BC
(or indeed AD / CE - we'd have to decide which dating convention to use)
We don't necessariliy have to imply a 'standard' deviation, gaussian, rectangular or otherwise just say this is an estimated date range. (although we should give some guidance for inputters as to how far down the distribution 'tail' to go when deciding on a beginning or end date)
We have professional archaeologists contributing here, perhaps someone would like to comment.
Having a 'central' date stored internally will make further analysis easier, eg for plotting maps or charts based on the dates.
I think I can implement the system to hold the dates without too much difficulty, it requires the will and interest of our contributors to turn it into a useful resource.
Perhaps this would be a good new project to re-enthuse people to contribute when just about all significant ancient sites in our core countries have already been well explored?
Would anyone else be interested in helping to contribute dates to such a system?
[ This message was edited by: Andy B on 2012-07-06 12:39 ]
Profile
Email
Reply
|
bat400
Joined:
10-04-2006
Messages: 1349
from South Central Indiana, US
OFF-Line
| Posted 06-07-2012 at 15:21
I'd be happy to add dates for North American sites (many of the existing sites already have dates as part of the site description) using a new format.
However, I'm guessing that Micheal has an interest in a particular location, and not the world wide range of sites?
What's the scope of this project? If the scope if very large (e.g. all of Europe) does the first effort in a test case need to be smaller?
Profile
Reply
|
Feanor
Joined:
11-05-2011
Messages: 319
from Cape Cod Massachusetts, US
OFF-Line
| Posted 06-07-2012 at 15:38
For what it's worth, I vote for 'BP' in the dating sequences.
Profile
Email
Reply
|
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
OFF-Line
| Posted 06-07-2012 at 17:27
BP would be slightly easier for maths purposes but remember we have 'AD' sites as well. Listing 1000AD as '1000BP' is going to confuse the hell out of most people.
Once implemented it would be a worldwide project with any logged in Portalers being able to contribute (and edit their own) dates.
Profile
Email
Reply
|
TheCaptain
Joined:
30-10-2003
Messages: 1490
from near Bristol
OFF-Line
| Posted 06-07-2012 at 17:30
I like the idea, but a massive task. But adding the ability to add dates I think would be a massive plus for all our data, and (like the fairly recent addition of positional accuracy, a couple of which I just added) these can be filled in by people as they go.
When i started reading this, after the how do we do that situation, one of my first thoughts was "what about sites with multiple phases of use?".
I suspect that there are far more of them than people would imagine. Maybe we would need a "construct" date (maybe better to just use a sort of era nomenclature), and then optional extra columns for 2nd pahe and 3rd phase usage?
It would certainly give us all something to think about !!!
Profile
Reply
|
Feanor
Joined:
11-05-2011
Messages: 319
from Cape Cod Massachusetts, US
OFF-Line
| Posted 06-07-2012 at 19:33
Quote:
|
On 2012-07-06 17:27, Andy B wrote:
BP would be slightly easier for maths purposes but remember we have 'AD' sites as well. Listing 1000AD as '1000BP' is going to confuse the hell out of most people.
|
|
Who cares about anything AD anyway?
lol
Adding more to the task, we might say: "1000 years ago", or simply use the actual date, ie: Wednesday 12 July 1142. (Old Calendar)
There, the use of AD is implied, but by convention.
I mention BP, et.al. as there is a growing number of Purists who reject 'AD/BC' as being biased to someone else's (arbitrary) faith - fair-use notwithstanding.
Neil
__________________
Profile
Email
Reply
|
MichaelJachan
Joined:
04-07-2012
Messages: 4
OFF-Line
| Posted 07-07-2012 at 10:01
Hello to all of you!
As i have written above, i have a toy-database at home, self-written
in C#, which has "Locations" as "primary data table". To each location, a List of Events can be connected. Thus, i am interested
in "downloading" the complete info from this wonderful source here
OK, in my view (from a Programmer, Statistician, but not an Archeologist) i write here how temporal information, ie prehistoric years could be added to the existing megalithic.co.uk database (which i technically do not know). The site is not only for amateurs, but also for professionals. They decide how a scientific accurate dating is given. When we speak about date-info, we mean either a year (usually far in the past) or an exact date (expressed
as Julian Day Number). They can have one of 2 different kinds of acurracy:
1) exact dates. no problem, one could add one new field to the database.
2) Archeological sites are dated mainly with radicarbon methods, which give a distribution of likeliness. This distribution usually is zero below and zero above a certain year, thus it has clear minimum and maximum. Another easy way to describe a distribution (Gaussian) using mean and stardard deviation. But as can be seen in a link from Andy, such histograms do not look very Gaussian.
PROBLEM: The most complete statistical data, ie the histogram itself, is not suited for implementaion here because it contains too much data. either max and min or mean and std could be too little.
Therefore, one could store min, max, mean, std together (4 numerical parameters)! If we would like to be more precise, we could add the median, the 5% quantile and the 95% quantile (then 7 parameters in total). Imho, in this way a scientific level of dating acurracy could be met. For this aim, it must be accepted to transform
the histograms from the radiocarbon measurements into these quantities.
Further, i pledge for the possibility to store more than 1 date per location, because each site can have been constructed in phases. I also pledge for "there is more than one type of site in a particular location" as Andy mentioned.
Next, i think that the database shall be open for many year-formats, ie common era, before CE, BP and astronomical year. Maybe the GUI can provide any field for entering/reading the year, but internally each date will be stored as astronomical year.
As i cannot judge what level of detail a professional needs, i cannot suggest what date-structure is best. But here are much people who can decide those issues.
Andy asked wheter somebody could help to enter the data. As is am not in the Field of Archeo, i could only gather the data from Wiki. But i cannot guarantee any scientific level, when i copy&paste the numbers. Somebody would need to review it! BTW: i am interested in reading some archeological research papers, but i cannot
download them. Thus, if you mail me the sources (PDF), i could also transfer some dates from papers directly, although it is a boring job. i am particularly interested in data from archeoastronomical sites, especially their angles of orientation
OK. Many thanks for your interest to my suggestion on dating.
BR, Michael
Profile
Reply
|
davidmorgan
Joined:
23-11-2006
Messages: 1620
from The New Forest
OFF-Line
| Posted 07-07-2012 at 13:28
BP is no good with exact dates (e.g. dendrochronological readings such as this). So we need some sort of calendar.
Profile
Reply
|
Feanor
Joined:
11-05-2011
Messages: 319
from Cape Cod Massachusetts, US
OFF-Line
| Posted 07-07-2012 at 15:27
Dendrochronological Dating is astonishing, yes! I was reading a bit about it yesterday. They pinned a distant historical event to within months. Fascinating stuff!
Very difficult to date an antler-pick buried under Stone with it.
Also, I realize that most people believe that as we move forward through the years the reverse-dates would have to be modified periodically.
But the basis for 'BP' is actually nailed at 1948. That's when they started blowing up lots of Hydrogen Bombs, fouling any future carbon-dating.
(Perhaps in 2,000 years they'll use: A.P. - 'After Present'! ) lol
So then we have "19 August 1165" for AD, and "2154 BP" for 154 BC.
BP also removes some of the confusion when dealing with the Meso- / Neolithic. No need to mentally add or subtract 2,000 years. I see this all the time in various places. Someone breathlessly claims: "10,000 Years BC!"
But they really mean 8,000, because their source's source forgot to 'do the math'. Gobekli Tepe was initially a perfect example of this confusion.
Also, in reviewing events that far back, the focus is more about trends than calendrical dates. Serendipitously finding an exact date, as through Dendochronology, is a welcome boon for cross-referencing events we know took place at roughly the same time. Otherwise, pinning a trend or mode to within 25 or 50 years is still pretty good over the course of 4,500 or 5,000 years.
Neil
___________
(See what you started, MichaelJachan!?) hee hee
[ This message was edited by: Feanor on 2012-07-07 15:37 ]
Profile
Email
Reply
|
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
OFF-Line
| Posted 07-07-2012 at 16:24
Deciding how we display the date is a bit of a side-show, this is just presentation of the data and can be changed later - or indeed the user given a choice of how they want it.
What we need to decide next is what the structure of the new data table to hold the dates should be
I would suggest:
SID - integer - Site ID Index - you can add mutiples of these for a particular site ID which will make for multiple dates for that site
SDate - Date / numeric integer - what a 0 equates to TBD - either 1948 (for BP) or 0AD - note that we will have some modern sites with date newer than 1948 so either way we will have some + and some - dates
Spread - Integer - Numeric (years) so 100 equals +/- 100 years (approximate rectangular distribution assumed)
Site Type - integer - Portal Type ID number - normally this would be the same as the main type ID for the site in question but could be changed to allow a sub site of a particular type and date to be registered. If you need a more precise type than one of our standard ones you'll have to give the details in the text
Reference - Text field - Reference as to where the date came from (optional)
Description - Text field for general description - probably not needed most of the time but allows special notes to be added (optional)
Is that everything we need to store a date?
Profile
Email
Reply
|
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
OFF-Line
| Posted 07-07-2012 at 16:29
...I remember Pete G asked for a 'rock type' field some time ago. Rather than add this to the main table this might be a good place to add it - although it's only specific to some types of site (ie stone ones) it's debatable whether it really needs whole field of it's own.
The rock types could actually just be stored as a note in the Visit log - ie that's what Pete G could use his visit log for
Profile
Email
Reply
|
h_fenton
Joined:
22-10-2005
Messages: 105
from OXFORDSHIRE, UK
OFF-Line
| Posted 08-07-2012 at 23:31
Most sites do not have specific dates associated with them, for date they are classified as being Neolithic or Bronze Age or Iron Age or Roman et cetera. these groups depending on where you are geographically have different date ranges. If you look back through literature published in the last 50 years you will find that the date ranges of different periods have changed too.
The classification of sites to particular date ranges can be subjective and open to argument.
lots of sites have multiple phases of use, excavations might show a site that has been in use for hundreds or thousands of years. what date are you going to put on your database for the site?
Are you going to moderate the dates that people apply to sites.
Is it easy to check dates?
I suggest you keep clear of using BP for all your dates, most people don't know what it means and it will cause confusion. depending how you write BP it means slightly different things - if you think "how many different ways are there that you can write it" -- the answer is "too many".
I suggest you just stick with BC/AD or BCE/CE as most people can understand those.
If you need to do dates I would suggest displaying generalised date ranges for sites at a faily low resolution in blocks of say 250 years.
Where there are specific dates obtained through scientific analysis you should put them in the site description and say what the dates actually relate to (and ideally reference your source).
Profile
Reply
|
juamei
Joined:
28-11-2002
Messages: 24
from Buxton
OFF-Line
| Posted 11-07-2012 at 15:42
I think the nature of the data should govern how the dates are stored. The dates (for uk sites) will come from 4 main sources presumably (other methods eg Optical dating would perhaps fall under the RC dates)
- A set of individual Radio carbon dates with associated probability and provenances.
- Accumulated RC dates using Bayesian statistical modelling (re Whittle, Bayliss & Healey)
- Dendochronology dates such as from the Sweet Track
- Comparative dating methods for sites which do not have their own dates through excavation.
The first three can be thought of as distinct to that site, but are obviously of different accuracy and hence objective value. The fourth however is subject to change dependent on research into other sites which are "similar" to the site being dated. Causewayed enclosures in the North of England will now be considered to have been used within a shorter lifespan as a result of the Bayesian work.
So perhaps the bst you can do with the fourth is to assign a site type to a site and then provide approximate dates for that type?
Profile
Reply
|
Andy B
Joined:
13-02-2001
Messages: 7043
from Surrey, UK
OFF-Line
| Posted 11-07-2012 at 19:37
I was just thinking the same thing last night Juamei, I think we need to add a field for 'type of date'. Also not made clear previously is that for radiocarbon dates, rather than 'start of use' and 'end of use' the spread is a reflection of the accuracy of the date - fundamentally you are just be indicating a single date but with limitations on accuracy, which would have to be a bit of a simplification.
We can also have 'rough' dates indicated such as 'Bronze Age' or 'Early Medieval' - these would show as the generally accepted overall 'start' and 'end' of the time period.
That would make the Date types:
Single Radiocarbon
Accumulated Bayesian RC date
Dendrochronology date
Date using comparative dating
Historical date (edited - ASB)
Other date (I'm sure there are other types we've not included)
Approximate Epoch (ie Bronze Age)
That last category would also help us get started as I could (for example) take all the Stone Circles and give them an overall approximate date of Late Neo / Early BA. The same for other types of site where this would be obvious.
A second more accurate date could then be added later - but probably not for many stone circles, which are notoriously hard to date!
On who will check these dates, they would be Wiki style user editable - by members only and with changes logged with an email to me. In other words it would be a crowd sourced project with associated possible accuracy problems, but with such knowledgeable and eagle eyed contributors these things usually work out over time.
[ This message was edited by: Andy B on 2012-07-12 16:27 ]
Profile
Email
Reply
|
Sunny100
Joined:
20-03-2010
Messages: 220
from Near Nelson, Lancashire
OFF-Line
| Posted 11-07-2012 at 22:13
Make it simple, keep AD and BC. If we get rid of AD we might as well get rid of everything, including Christianity. We have had to put up with CE - Christian Era - please do not fiddle with AD. It means after Christ Anno Domini. My Christian faith is a comfort to me, but not to others it seems. If you get rid of it, you might start to loose contributors. I for one will be using AD. 
Profile
Reply
| |
| Go to Page: 1 | 2 |
|
|
|
|
|
IMPORTANT NOTES: This site uses COOKIES. Please do not use this web site if you do not agree to our Terms and Conditions of use.
If you plan to visit ancient sites in person, please make sure you follow our Charter.
Articles, photographs and comments are the property of their respective authors or contributors, please contact them for permission to reproduce. Site design ©1997-2012 Andy Burnham.
|
Main News