The following warnings occurred:
Warning [2] Undefined array key "avatartype" - Line: 783 - File: global.php PHP 8.0.30 (Linux)
File Line Function
/global.php 783 errorHandler->error
/printthread.php 16 require_once
Warning [2] Undefined array key "avatartype" - Line: 783 - File: global.php PHP 8.0.30 (Linux)
File Line Function
/global.php 783 errorHandler->error
/printthread.php 16 require_once
Warning [2] Undefined variable $awaitingusers - Line: 34 - File: global.php(844) : eval()'d code PHP 8.0.30 (Linux)
File Line Function
/global.php(844) : eval()'d code 34 errorHandler->error
/global.php 844 eval
/printthread.php 16 require_once
Warning [2] Undefined array key "style" - Line: 909 - File: global.php PHP 8.0.30 (Linux)
File Line Function
/global.php 909 errorHandler->error
/printthread.php 16 require_once
Warning [2] Undefined property: MyLanguage::$lang_select_default - Line: 5010 - File: inc/functions.php PHP 8.0.30 (Linux)
File Line Function
/inc/functions.php 5010 errorHandler->error
/global.php 909 build_theme_select
/printthread.php 16 require_once
Warning [2] Undefined array key "additionalgroups" - Line: 7045 - File: inc/functions.php PHP 8.0.30 (Linux)
File Line Function
/inc/functions.php 7045 errorHandler->error
/inc/functions.php 5030 is_member
/global.php 909 build_theme_select
/printthread.php 16 require_once
Warning [2] Undefined property: MyLanguage::$archive_pages - Line: 2 - File: printthread.php(257) : eval()'d code PHP 8.0.30 (Linux)
File Line Function
/printthread.php(257) : eval()'d code 2 errorHandler->error
/printthread.php 257 eval
/printthread.php 117 printthread_multipage
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key 1 - Line: 801 - File: inc/class_parser.php PHP 8.0.30 (Linux)
File Line Function
/inc/class_parser.php 801 errorHandler->error
/inc/class_parser.php 866 postParser->mycode_parse_post_quotes
[PHP]   postParser->mycode_parse_post_quotes_callback1
/inc/class_parser.php 751 preg_replace_callback
/inc/class_parser.php 431 postParser->mycode_parse_quotes
/inc/class_parser.php 187 postParser->parse_mycode
/printthread.php 179 postParser->parse_message
Warning [2] Undefined array key 1 - Line: 820 - File: inc/class_parser.php PHP 8.0.30 (Linux)
File Line Function
/inc/class_parser.php 820 errorHandler->error
/inc/class_parser.php 866 postParser->mycode_parse_post_quotes
[PHP]   postParser->mycode_parse_post_quotes_callback1
/inc/class_parser.php 751 preg_replace_callback
/inc/class_parser.php 431 postParser->mycode_parse_quotes
/inc/class_parser.php 187 postParser->parse_mycode
/printthread.php 179 postParser->parse_message
Warning [2] Undefined array key "showimages" - Line: 160 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 160 errorHandler->error
Warning [2] Undefined array key "showvideos" - Line: 165 - File: printthread.php PHP 8.0.30 (Linux)
File Line Function
/printthread.php 165 errorHandler->error
Warning [2] Undefined array key 1 - Line: 801 - File: inc/class_parser.php PHP 8.0.30 (Linux)
File Line Function
/inc/class_parser.php 801 errorHandler->error
/inc/class_parser.php 866 postParser->mycode_parse_post_quotes
[PHP]   postParser->mycode_parse_post_quotes_callback1
/inc/class_parser.php 751 preg_replace_callback
/inc/class_parser.php 431 postParser->mycode_parse_quotes
/inc/class_parser.php 187 postParser->parse_mycode
/printthread.php 179 postParser->parse_message
Warning [2] Undefined array key 1 - Line: 820 - File: inc/class_parser.php PHP 8.0.30 (Linux)
File Line Function
/inc/class_parser.php 820 errorHandler->error
/inc/class_parser.php 866 postParser->mycode_parse_post_quotes
[PHP]   postParser->mycode_parse_post_quotes_callback1
/inc/class_parser.php 751 preg_replace_callback
/inc/class_parser.php 431 postParser->mycode_parse_quotes
/inc/class_parser.php 187 postParser->parse_mycode
/printthread.php 179 postParser->parse_message



BAJR Federation Archaeology
The next question: recording - Printable Version

+- BAJR Federation Archaeology (http://www.bajrfed.co.uk)
+-- Forum: BAJR Federation Forums (http://www.bajrfed.co.uk/forumdisplay.php?fid=3)
+--- Forum: The Site Hut (http://www.bajrfed.co.uk/forumdisplay.php?fid=7)
+--- Thread: The next question: recording (/showthread.php?tid=5111)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


The next question: recording - Tool - 19th October 2013

What makes the perfect context sheet/section drawing? If you're doing all the post-ex stuff, what sort of information do you actually want? Because I'm a sad git I've been trying to design my own record sheets, but being inexperienced have no idea what information is actually needed from the digger to enable a good record of the site. So, given a blank slate, what would you like to see from the bod with the trowel in their hand?


The next question: recording - kevin wooldridge - 19th October 2013

On a section/profile drawing I like to see properly labelled and located end points, an indication of the drawing scale, some suggestion of the attitude (e.g south facing) and the height of the section 'string' relative to OD....not so bothered about fancy shading, stippling etc. And sometimes a small location sketch if profile is one of a series.....keep it simple, but accurate is my policy.

As for recording sheets...the important thing to my mind is that it is relevant to the archaeology being recorded. I was (am) a fan of the Museum of London suite of record sheets for different purposes (timber, masonry, burial sheets etc) based on the principle, that potentially there is far too much data to go onto one single sheet. Have also personally designed sheets for very specific purposes e.g post-medieval cemetery burial location record, Roman bath-house masonry record sheets etc etc, but that fit the general precepts of the MoL single context record system.....I do remember a colleague designing and using a circular drawing template onto the MoL 5m grid plan sheets for use on the shaft excavations for the Docklands Light Railway....

.....currently using a sheet written in Norwegian, designed to replicate the input fields of the Swedish Intrasis GIS recording software. I believe the current versions of the English Heritage recording sheets do the same, but in English...

Postscript: I'd forgotten but now remember, that with a MoL colleague, we designed a context sheet for use in measuring and assessing the contents/state of completeness/significance/potential for further work of the Museum of London archaeology departments huge backlogged sites archive. It helped in making applications for post-ex funding and concentrating resources for many projects that might otherwise still be mouldering in boxes somewhere in Hackney...


The next question: recording - drpeterwardle - 19th October 2013

I would agree with that. The early context sheets were drawn up in a fashion to try and make the records ready for computerisation and an attempt to standardise what was recorded years before computers became universally available ie early 1970s for the first context sheets and late 1980s for the use of computers. Since that time IT has changed out of all recognition and what has always amazed me in the amount of duplicated information that is recorded as well as the amount of redundant information. For example why is a location needed on a context sheet ie a grid reference when there is a geo-referenced digital plan that is instantly available.

Peter


The next question: recording - barkingdigger - 19th October 2013

Wow - where do we begin? As you specifically asked about paper records, I think we need to understand why redundancy of info is important. If your records are to be examined by others long after the site is gone, they need to be intelligible and thoroughly cross-referenced so they can tell the story. And if your bosses generally work on paper rather than hi-tech methods you'll need to get in the habit of adding stuff like co-ords so you can work out where the feature was! (And even with digital mapping, the human factor means you still need redundant data to provide an independent check for those occasions when "fat fingers" hitting the wrong CXT number during data entry wind up FUBAR-ing your efficient database relationships! Or when the CXT record is typed up, but no digital or even paper outline is captured. Don't laugh - it happens!)

Now, on a paper record I like to be old-school and have a mix of atomised "measurables" and free text. So, there are five main chunks that a good sheet needs.

First, there's the basic ID stuff - boxes for Site Name, Date, Context Number, and useful dimensional stuff (L/W/H/D, shape in plan, shape in profile for Cuts, etc) as well as colour/texture/inclusions. Some of this could be found on the plans & sections, but I refer you to my first paragraph...

Next we need the all-important relationships. Not only direct strat "over/under", but also physical ones where applicable. (It can be useful to know that ditch X is cut by pit Y, even if pit Y is several phases later - the cutting could mangle the crucial relationship between ditch X and layer Z...) Then there are the relationships to other records - drawings, pics, finds, samples. Again, see above regarding the usefulness of redundancy when all doesn't go to plan in post-ex.

Third & fourth are both free-text fields, and whether they are separate boxes or one box divided by use of paragraphs is unimportant as long as site discipline is rigorous. The first bit of text is an observational description of the feature, the digging conditions, and anything else that might affect how the record is interpreted in post-ex. I like this bit to remain untrammelled by any subjective interpretation - the aim is to present in words a view of the feature and its surroundings on the dsay it was dug. Was it chucking down? (Finds recovery can be biased if the claggy spoil sticks to your tools in lumps big enough to hide a hand grenade!) Was there a dry spell? ("Concrete" soil might hinder the finding of edges...)

After a big gap (or in a separate box), it is time to wax lyrical with some good old interpretation! What did YOU think was going on? What's your guess about the function of the feature? Or its date?

Finally, on paper records it really, REALLY, helps to add sketches on the back that show not only the CXT in question, but also the ones around it that might be useful. Here's a good place to indicate where the edge was overdug, or how you think several CXTs form up to make a building. This used to be the discipline of "multi-context planning" which fell out of favour. Even though such sketches are truly redundant even in a paper system with plans and sections, I still find them very helpful when wrapping my head around a site narrative or revised matrix back at the office.

Well, these are my preferences for paper context sheets, but your mileage may vary!

As for drawings, a plan ain't a plan with anything less than three grid co-ordinate points! And a section without 3D co-ordinated endpoints marked on is just a doodle.

Let the brickbats fly...


The next question: recording - kevin wooldridge - 19th October 2013

The only brickbat I would aim at Barking's criteria is on the question as to whether it is wise to mix stratigraphic and physical relationships on the same sheet. As Barking quite rightly says these sheets may be read in years to come. My point would be, without any indication to the contrary how is that alien from planet Zog supposed to know whether you meant that layer 1 overlay layer 2 physically or straigraphically if such information is mixed on a sheet. My memory when it was first designed was that the MoL sheet was supposed to be purely stratigraphic but have noticed that its many cloned imitators over the years tend to add boxes such as 'butts' and 'butted by', clearly missing the whole point of the original DUA masterpiece!! I also have no problems with sketches, but would remind folk that in this age of mass-scanning of records it is a pain in the arse to have records on more than one side of the paper so would prefer the use of additional single sided sketching sheets.... as for the correlation between the context sheet and the digital record, I think this is a case where technology and 'handiwork' are catching each other up and in places overlapping. I wouldn't be throwing the baby out with the bathwater just yet, but I think we have to accept that there comes a point when one or the other rightly or wrongly is going to win (probably technology) and our recording procedures need to be adapted to reflect that.


The next question: recording - barkingdigger - 19th October 2013

Hi Kevin!

I understand the risks of mixing strat & physical, although frankly there are too many folk out there that can't tell 'em apart anyway, and put all manner of rubbish in even if they only get boxes for strat. (And I'm firmly of the belief that anything from Planet Zog clever enough to conquer space travel and learn our language would be bright enough to dust off a copy of the recording manual...)

I'm not so sure though that "paper vs digital" is really a battle to be won, given that both have uses and weaknesses tthat almost make 'em mutually exclusive depending on site infrastructure, resources, time pressure etc. And from what I remember of our foray into Intrasis, even the Swedes admitted that for urban stuff they filled out modified DUA-style paper forms in the trench and typed it into the database afterwards! Unless we develop Star Trek tricorders I can't see the "born digital" revolution taking over the muddy trenches anytime soon. Especially when paper & pencils are so cheap, and good old permatrace even works in the rain.

Don't get me wrong - I'm all for hi-tech. I love a good database, and am well-versed in plotting features by TST and/or GPS. I just don't see it as a case of one or the other, but not both.


The next question: recording - kevin wooldridge - 19th October 2013

Don't doubt that Swedes are creating paper records prior to entering the data into Intrasis...we do the same in Norway and EH do the same in the UK. Its what happens to the paper record after data entry that suggests a different approach.....In our case the archive is digital and the paper record a by-product. I suspect the same in Sweden as I heard earlier today that the National Antiquities Board have a project to upgrade some 800 digital archives in light of the latest release of Intrasis, so I guess the digital archive is the national standard and not paper or drawing film. Can't recall off hand what EH's latest policy is on the paper generated to feed the Intrasis monster, but suspect I will be told.....


The next question: recording - barkingdigger - 20th October 2013

My memory of it was the EH paper sheets were only temporary until the full data was in Intrasis & thoroughly cross-checked, after which they could become chip wrappers. The sketches were scanned as images, with their own existence in the database. I've got no issue with that approach, as long as the database can be preserved and used in perpetuity. However, even in its stricken state, EH can throw digital resources at projects that the commercial world can only dream of - hence the spec based on "paper only" earlier.

I agree with you on the dangers of the back side of the sheet, but where else can sketches go if you don't want to kill whole forests? The handy thing about the reverse of the sheet is that it stays with the CXT. I know EH did draw up "sketch" sheets to address the whole "lazy photocopying" problem, but sometimes I think we archsaeologists go a long way round just to avoid the unpleasant task of proper discipline! (Do any other professions go to great lengths to leave the backs of forms blank?...)

As for strat vs physical relationship mingling, there's a lot to be said for laying them out as separate well-labelled areas of the sheet to help dispell confusion, coupled with a firm eye of the supervisor.


The next question: recording - P Prentice - 20th October 2013

Tool Wrote:What makes the perfect context sheet/section drawing? If you're doing all the post-ex stuff, what sort of information do you actually want? Because I'm a sad git I've been trying to design my own record sheets, but being inexperienced have no idea what information is actually needed from the digger to enable a good record of the site. So, given a blank slate, what would you like to see from the bod with the trowel in their hand?
people have argued about the perfect context sheet/recording system for donkey's but almost all fail because they are all designed on the basis that a context can be defined, and that the given definition would be recognisable to anybody else who came across it - which is of course nonsense. There is then no such thing as a perfect context sheet, except for a copyrighted one. a better question might be - what is a context or even, what is a feature? one could for instance contend that so-called contexts are irrelevant because they are not archaeology any more than stratigraphy is. at best they are clumsy tools we use to fill out gaps in observable process. it is our bread and butter but it is almost always flawed. how many of us really have a clue where the bit of pot in the loose came from? how many of us assume that we know and that is how the record is repeated forever after? how many of us know the difference between a slumped edge and a cut? how many of us make the record say what we want it to say despite the evidence?
all recording is interpretation and it is the interpretation that is archaeology not the context and not the context sheet.
on this basis i would say the best context sheet is the one that reflects the 'conversation' between the digger, the supervisor and the report author as well as every specialist, and passer-by with an opinion. i would put the interpretation box at the top.


The next question: recording - Sith - 21st October 2013

P Prentice Wrote:On this basis i would say the best context sheet is the one that reflects the 'conversation' between the digger, the supervisor and the report author as well as every specialist, and passer-by with an opinion. i would put the interpretation box at the top.

I don't disagree, but do worry that this vital chain of conversations does not take place.