Een database structuur voor opgravingsgegevens Archol, voorjaar 2004 (Concept)

Een database structuur voor opgravingsgegevens Archol, voorjaar 2004 (Concept)

Inhoud Inleiding Veldmodule Project documentatie Vondst administratie Vonstcontext administratie Foto administratie Tekening administratie Landmeetkundige informatie Conclusies Voorbeelden van referentie tabellen Bijlage: alternatieve opgravingsmethoden

Inleiding In dit document wordt een database beschreven voor de veldgegevens bij een opgraving. De structuur is in eerste instantie ontwikkeld voor een opgraving waarbij relatief eenvoudige grondsporen met vondsten, op meerdere vlakken worden gedocumenteerd. Daarbij is er voor gekozen om een zo eenvoudig mogelijke digitale documentatie op te zetten en worden zelfs bepaalde aspecten alleen analoog gedocumenteerd. Sommige gegevens staan dus alleen op de vlak- en coupetekeningen en zijn niet ook nog eens tekstueel in de database beschreven. De hieronder beschreven oplossing, zoals die momenteel bij de veldprojecten van Archol B.V. in Leiden wordt gebruikt, is maar één van de mogelijke oplossingen. Het is zeker niet de enige oplossing, laat staan de beste structuur voor een archeologische velddatabase. Opgravingsmethode en documentatie De methode van opgravingen en documenteren zal van project tot project verschillen. Dat geldt niet alleen voor de relatief ver uiteen liggende opgravingen van een Paleolithisch kampement in een lössgroeve (individuele vondsten), een Neolithische donkopgraving (vakken) of een Romeinse opgraving in de Betuwe (sporen). Door nieuwe inzichten, andere vraagstellingen en andere technische mogelijkheden heeft en vindt er een continue aanpassing plaats van de opgravingsmethodiek. Ook instituutsof persoonsgebonden tradities spelen bij de registratie in het veld een rol. Ook nu nog gaat die ontwikkeling door: de specificaties van Dig-IT (Betuweroute), de HSL, AHR en de KNA verschillen telkens (iets). Omdat de methode van opgraving telkens verschilt, zal ook de manier waarop de gegevens gedocumenteerd worden verschillen. Afhankelijk van de onderzoeksstrategie worden veldformulieren gebruikt, waarop precies die informatie wordt vastgelegd die noodzakelijk is. Het liefst niet meer en niet minder. Zo’n papieren (analoog) veldformulier, dat met de hand wordt ingevuld, zal op zijn beurt voor de invoer van de digitale gegevens worden gebruikt. Daarbij heeft het de voorkeur het digitaal formulier op het scherm erg op het gebruikte analoge formulier te laten lijken. Zelfs als in het veld direct digitale formulieren worden gebruikt, Archol – database structuur veldmodule

1

kunnen deze beter op maat worden gemaakt voor een specifiek project. Hiervoor zijn de volgende redenen aan te voeren: - efficiëntie, het opgravingsproces moet vlot doorgang kunnen vinden, zonder een overdreven grote documentatielast - foutbeperking, om te voorkomen dat tijdens het veldwerk fouten in de documentatie ontstaan is het beter om: o kenmerken die bij deze opgraving niet worden vastgelegd, niet op het formulier te zetten. Eenvoud voor alles. o de terminologie aan te passen aan het gebruik in het veld. Gebruik op het formulier bijv. vaknummer in plaats van segmentnummer, laag in plaats van spoor als dat begripsverwarring voorkomt. o de formulieren af te stemmen op de taken die een persoon (dagelijks) in het veld verricht. De manier van graven en werken bepaalt dus in hoge mate de manier van documenteren en daarmee wordt dus ook de database structuur in hoge mate beïnvloed. Standaardisatie van alle opgravingsgegevens in één databasestructuur is op basis van het bovenstaande dan ook niet haalbaar. De bestanden mogen van project tot project ook best verschillen, zolang die digitale bestanden maar goed gedocumenteerd zijn. Als bij de bestanden een compleet metadata-document wordt gevoegd, waarin de structuur van de gegevens, variabelen en betekenis van codering wordt uitgelegd, is dat ook geen wezenlijk probleem. Natuurlijk kan er naar worden gestreefd om bij verschillende projecten in de toekomst, zoveel mogelijk eensluidende velden en coderingen te gebruiken, maar verplicht zou dat nooit mogen zijn. Liever een goede digitale documentatie, dan bijvoorbeeld een database met veel velden die niet ingevuld zijn of een database waarin variabelen en coderingen worden gebruikt die niet bij de opgraving passen. Taakgericht automatiseren Een belangrijk uitgangspunt voor de (digitale) documentatie in het veld is “taakgericht automatiseren”. In het veld hebben verschillende medewerkers, verschillende taken en verantwoordelijkheden. De documentatie die zij verzorgen is veelal slechts een onderdeel van een groter geheel. Samen wordt de complete documentatie verzorgd. Bepaalde taken in het veld gaan of moeten soms sneller gaan dan andere taken. Het is heel realistisch om zich een situatie voor te stellen waarin de grondspoordocumentatie nog even niet kan worden ingevoerd, maar men wel met de vondstverwerking of de tekeninglijst verder moet. Uiteindelijk moet een achterstand op een deelaspect natuurlijk ingelopen worden en kan de complete velddocumentatie worden afgerond. Processen vinden parallel plaats, waarbij soms de ene trein net iets harder loopt dan de andere. De verschillende verantwoordelijke personen en het verschil in onderlinge snelheid tussen de taken vormen de kern van het gekozen automatiseringsysteem. Die taken zijn min of meer onafhankelijk van elkaar. Zo kunnen we bijvoorbeeld de taken van de projectleider, putbaas, vondstverwerking, veldtekeningen en landmeters duidelijk van elkaar onderscheiden. Bij kleine(re) projecten zullen meerdere taken overigens vaak in één persoon verenigd worden. Voor elke taak zijn er aparte (digitaal) formulieren gemaakt, zonder onnodige kenmerken en met de specifieke termen van dit project. Integriteitscontroles zijn heel strikt waar het één verantwoordelijkheid betreft. Bijvoorbeeld binnen de grondspoor-

Archol – database structuur veldmodule

2

administratie zijn de digitale formulieren voorzien van uitgebreide foutcontroles. Tussen de verschillende taken zijn de controles echter aanzienlijk soepeler. Wij accepteren dat een fotolijst al kan worden ingevoerd, zonder dat de daarop zichtbare sporen al digitaal zijn geadministreerd. Wel vinden er regelmatig controle-queries plaats om te kijken hoe ver een ander deel van de documentatie achterloopt en of er nog “losse-eindjes” zijn. Redundantie en controles Vanuit het verleden, waarin we tijdens opgravingen alleen over analoge documentatie beschikten, is een traditie ontstaan om op meerdere formulieren, tekeningen en kaartjes dezelfde informatie vast te leggen. Soms om te voorkomen dat we belangrijke informatie zouden vergeten, soms om via een onderlinge controle de documentatie te kunnen controleren, soms om het onszelf makkelijker te maken bij de uitwerking. Bij de vondsten wordt een vondstkaartje gestopt, waarop naast het vondstnummer ook de vondstcontext wordt vermeld, in de vorm van één of meerdere ingevulde velden bij put-vlak-spoor-vulling-segment.

voorbeeld vondstkaatje met een beperkt aantal kenmerken

Vrijwel dezelfde informatie wordt ook vastgelegd op de vondstenlijst (vondstnummerlijst) en het vondstnummer wordt ook op veldtekening naast het grondspoor gezet. De veldtekening – de vondstenlijst – het vondstkaartje vormen een soort overlappende documentatiedriehoek die volledig moet kloppen. Dit is een (fout)gevoelige manier van documenteren. Zo’n overlap (redundantie) moet tot een minimum beperkt worden. Nog een voorbeeld: op de sporenlijst werd vaak direct in het veld al aangegeven op welke tekening de coupe van dat spoor staat. Het couperen van de sporen is echter een andere activiteit (op een ander moment, door en andere persoon) dan de primaire spooradministratie (op basis van het vlak). Omdat ook de vlaktekening, coupetekening en eventueel de vondstenlijst op datzelfde moment in overeenstemming met elkaar moeten worden gehouden, is zo’n extra documentatielast onverstandig. Achteraf wordt er, als onderdeel van de tekening-administratie, toch al beschreven wat er precies op elk tekenblad staat. Het gebruikt van de digitale database en het ontwerp van de tabellen is er op gericht om dubbel werk tot een minimum te beperken. Immers, op de vondstenlijst wordt uitgebreid geadministreerd wat de verzamelwijze, vondstcategorie, (veld)volume of vondstdatum is, terwijl op het vondstkaartje en de veldtekening alleen een minimum staat. Via een zoekopdracht (query) kan later op eenvoudige wijze voor elk spoor worden opgezocht op welke tekening deze staat. Een overbodige handeling in het


3

veld, die vaak onvolledig en dus onbetrouwbaar wordt uitgevoerd, kan zo worden voorkomen. Uiteindelijk komt de informatie van al die verschillende informatiestromen toch weer bij elkaar. Op basis van alle tabellen in de database kunnen er overzichtsformulieren worden gemaakt, waarop bijvoorbeeld per grondspoor direct zichtbaar is welke vullingen, relaties, vondsten, monster, tekeningen en foto’s op dat spoor betrekking hebben.

voorbeeld van een formulier waarop de verschillende aspecten van de opgravings-documentatie uiteindelijk (op de verschillende tabbladen) weer bijeenkomen

Zo kunnen ook actuele dozenlijsten, met inhoud en uitleenadministratie à-la-minute worden samen gesteld of vanuit de projectinformatie een Archis(I)-melding worden uitgeprint. Bij de invoer van de analoge veldformulieren vinden direct al invoer(tik)- en integriteitscontroles plaats. Voor een deel geschiedt dit na verloop van tijd/ na afloop via controle-queries. Door er naar te streven de digitale invoer zo kort mogelijk na het verzamelen van de gegevens in het veld te laten plaatsvinden, kunnen problemen en onduidelijkheden nog makkelijk, uit de herinnering, worden opgelost. Database structuur en gebruikersinterface Bovenstaande overwegingen hebben geleid tot een aantal technisch ontwerpkeuzes voor de tabellen van de velddatabase. Het is bij Archol als een soort default database structuur beschikbaar. Al naar gelang de doelstellingen van het project, wordt dit versoberd of op kleine onderdelen aangepast. Hieronder zal die structuur nauwgezet worden gedocumenteerd. De structuur is vrij beschikbaar en mag door eenieder naar wens worden gebruikt of aangepast. Bij Archol is aan de database ook een groot aantal invulformulieren, specifiek op taken van de medewerkers afgestemd, toegevoegd. Tevens worden rapporten en (controle-)queries, per project, beschikbaar gemaakt. Via een menu(formulier) worden de eindgebruikers naar de betreffende formulieren, controles en rapporten geleid.


4

voorbeeld van een (menu)formulier waaruit de splitsing van taken en tabellen nadrukkelijk tot uiting komt in de kleurvlakken

Veldmodule De hieronder beschreven tabellen vormen samen een database waarmee tijdens het veldwerk de administratie van vondsten en hun context kan worden gedocumenteerd. De tabellen zijn, ten behoeve van het overzicht, onderverdeeld in verschillende, samenhangende groepen. De groepering hangt samen met de verschillende taken en verantwoordelijkheden die veelal binnen een opgravingsteam kunnen worden aangewezen. De volgende documentatie wordt onderscheiden: 1. de algemene projectinformatie 2. de vondst administratie, met de documentatie over vondstnummers in het veld en de (verdere) vondstverwerking 3. de vondstcontext administratie, veelal in de vorm van de documentatie over putten, vlakken, grondsporen, vullingen en segmenten 4. de tekening administratie, tekenbladen (vlakken/coupes/profielen) de onderwerpen daarop 5. de foto administratie, foto’s/dia’s/digitale opnames en de onderwerpen daarop 6. de landmeetkundige informatie, met bijvoorbeeld de gegevens over vlakhoogtes en puntvondsten Elk van de documentatie aspecten wordt apart beschreven met de structuur van elke individuele tabel en van commentaar voorzien. Conventies In de onderstaande beschrijving van elke tabel worden een aantal (stijl)conventies gehanteerd. De structuur van elke tabel wordt gepresenteerd op een manier zoals die in het relationele database management Microsoft-Access gebruikelijk is. Voor andere


5

software zal wellicht een andere presentatie gelden of kleine aanpassing aan de structuur noodzakelijk zijn. Per tabel is, in de kolom Key, aangegeven wat de primaire sleutel is. Dat kan één veld zijn (enkelvoudige sleutel) of de combinatie van een aantal velden (samengestelde sleutel). De velden van de primaire sleutel, vet lettertype, moeten verplicht worden ingevuld en zijn (samen) voor elke waarneming (record) uniek. Onderaan elke tabel wordt de primaire sleutel nogmaals herhaald. Per tabel is, in de kolom Required, aangegeven welke velden eigenlijk altijd ingevuld zouden moeten worden. Dat betreft vanzelfsprekend de velden die de primaire sleutel vormen, maar ook velden die volgens de gangbare archeologische kwaliteitsnormen (KNA) minimaal geadministreerd zouden moeten worden. Sommige velden zijn bij de (eerste) invoer nog niet beschikbaar en kunnen pas later worden aangevuld. Zo is bijvoorbeeld in de tabel vlak de begindatum verplicht en controleert het formulier de invoer. Pas na voltooiing van het vlak kan de einddatum worden ingevoerd. Hierop kan uitsluitend achteraf, via een controle-query, worden gecontroleerd. Per tabel zijn er een aantal velden in het grijs afgebeeld. Deze variabelen zijn minder gangbaar of dienen een specifiek doel. Hier wordt bijvoorbeeld, bij elke tabel, automatisch bijgehouden door wie en wanneer de invoer van een waarneming (record) wordt verricht. Dit maakt het navragen van onduidelijkheden mogelijk. Het is echter specifiek geprogrammeerd voor de gebruikte invoermodule. Per tabel wordt via een korte inleiding telkens de inhoud en het doel van de tabel beschreven. Daar waar, door de gevolgde opgravingsmethodiek, specifieke eisen of kenmerken voor een tabel of veld gelden, wordt dat voorafgaand of bij de alternatieven kort vermeld. Voor een bredere discussie tussen opgravingsmethodiek en de analoge en digitale documentatie wordt hier verwezen naar de paragraaf Andere opgravingsmethoden. Per tabel is aangegeven welke relaties er met andere tabellen bestaan. Bij de samenhangende tabellen van één taak zijn de relaties gedefinieerd met een gedwongen referentiële integriteit (“enforced referential entigrity”). De mogelijkheden van Access om bij wijzigingen automatisch de sleutelvelden in onderliggende tabellen bij te werken (“Cascading update”) of om bij verwijderingen automatisch waarnemingen in onderliggende tabellen te wissen (“Cascading delete”) worden momenteel nog niet gebruikt. Op de afgebeelde voorbeeld formulieren zijn de grijze velden, op dat moment, voor de eindgebruiker niet veranderbaar. Alle hieronder gebruikte namen zijn optioneel. Dit geldt zowel voor de naamgeving van de tabellen, de variabelen als de coderingen (referentie tabellen). Ook de lengte van de velden kan, daar waar gewenst, eventueel worden aangepast. 1. Project documentatie De algemene vindplaats documentatie bestaat in principe uit slechts één tabel (project) met één waarneming. Als tijdens het onderzoek een lokaal meetsysteem wordt


6

gebruikt om de ruimtelijke locaties te documenteren is ook een tweede tabel, met de coördinaten van de referentiepunten hier op zijn plaats. Deze algemene informatie over de gehele vindplaats valt in principe onder de verantwoordelijkheid van de (dagelijks) projectleider. Project In deze tabel wordt de algemene informatie over het onderzoek/ de opgraving vastgelegd. Het dient tevens ter voorbereiding van de Archis(I)-melding Er is altijd maar één waarneming in deze tabel, voor het huidige (opgravings)project. project Key Fieldname yes proj_code project provincie gemeente gem_code plaats toponiem instelling proj_leider

Type Length Required Description Character 5 yes projectcode (Site Identificatie Code) Character 80 yes projectnaam Character 2 2-lettercode (ref_prov) Character 25 yes gemeentenaam Character 4 gemeentecode Character 25 plaatsnaam Character 25 locale gebiedsaanduiding Character 4 yes naam van opgravende instelling (ref_inst) Character 20 yes naam van projectleider of dagelijks wetenschappelijk leider adres Character 50 adres van opgravende instelling (straat, postcode, plaats) inst_code Character 5 projectcode opgravende instelling datum_begin Date 8 datum start onderzoek datum_einde Date 8 datum einde onderzoek kaartblad Character 3 kaartblad volgens indeling topografische kaart 1:25.000 x_rd Numeric Double yes x-coördinaat in RD in km. y_rd Numeric Double yes Y-coördinaat in RD in km. precisie Numeric Byte nauwkeurigheid van de coördinaten (ref_precisie) nap Numeric Single NAP-hoogte maaiveld in m. lengte Numeric Integer omvang vindplaats (grootste lengte in m.) breedte Numeric Integer omvang vindplaats (grootste breedte in m.) verwerving Character 3 onderzoeksmethode (ref_verwerv) maaiveld Character 3 landgebruik (ref_maaiveld) geomorfologie Character 3 landschappelijke ligging (ref_geomorf) ROB_nr Numeric Integer ROB projectnummer (Art. 41) CAA_code Character 20 CAA code () CMA_code Character 20 CMA code prosp_instelling Character 5 naam van prospecterende instelling (ref_inst) prosp_code Character 20 projectcode prospecterende instelling per_begin Character 7 oudste datering (ref_dat) per_einde Character 7 jongste datering (ref_dat) cultuur Character 3 culturele toewijzing (ref_cultuur) complex Character 4 functionele interpretatie (ref_complex) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon


7

De grijze velden zijn optioneel. Primaire sleutel: proj_code Relaties: geen Referentietabellen: ref_prov, ref_inst, ref_precisie, ref_verwerv, ref_maaiveld, ref_geomorf, ref_dat, ref_cultuur en ref_complex Alternatieven: met de komst van Archis II zullen de betreffende velden en bijbehorende referentietabellen moeten worden aangepast. Zo worden bijvoorbeeld de RD-coördinaten in Archis II in meters vastgelegd. Het veld adres kan hier worden weggelaten als dezelfde informatie ook via de tabel inst_adres wordt vastgelegd.

voorbeeld van een ingevuld formulier voor de tabel project


8

Coordinaten Indien de opgraving gebruikt maakt van een lokaal meetsysteem in plaats van RDcoördinaten, dient deze tabel te worden opgenomen. Hierin wordt voor minimaal 3 referentiepunten (records) aangegeven hoe de locale coördinaten overeenkomen met de RD-coördinaten. De referentiepunten dienen ruimtelijk zo ver mogelijk uiteen te liggen. coordinaten Key Fieldname yes referentie x_lokaal y_lokaal x_rd Y_rd opmerking INV_DAT INV_PERS

Type Number Number Number Number Number Character Date Character

Length Required Description Integer yes nummer van het referentiepunt Double yes x-coördinaat in het lokale meetsysteem (in m.) Double yes y-coördinaat in het lokale meetsysteem (in m.) Double yes x-coordinaat in het RD-systeem (0 - 300000 m.) Double yes y-coördinaat in het RD-systeem (300000 - 625000 m.) 80 8 invoer datum en tijd 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: referentie Relaties: geen Referentietabellen: geen Alternatieven: de ruimtelijke locaties direct in de coördinaten van het RD-systeem vastleggen. 2. Vondst administratie De vondstadministratie bestaat uit een aantal afzonderlijke, maar samenhangende tabellen, te weten: - de vondstcontext in het veld (vondst_v) - de (primaire) vondstverwerking: tellingen en weging (vondst_s) - vervallen vondstnummers (vondst_null) - de vondstopslag en doosadministratie (doos) - de (onderzoeks)instellingen (inst_adres) De verantwoordelijkheid over de documentatie van de context van de vondsten ligt in het veld veelal bij de putbaas. Daarentegen draagt bij de meeste opgravingen een ander persoon de zorg voor de (verdere) vondstverwerking. Een goede samenwerking en taakafstemming is hier op zijn plaats. Voor een effectieve vondstadministratie is besloten om de bovenstaande tabellen niet altijd met een één-op-één formulier toegankelijk te maken. Er zijn formulieren specifiek toegespitst op de verschillende activiteiten: specifieke velden zijn soms wel of soms niet vermeld, velden staan op alleen-lezen en gerelateerde tabellen zijn direct of indirect, via een knop, toegankelijk. Vondstcontext In deze tabel wordt voor elk vondstnummer gedocumenteerd waar en hoe deze vondst is gedaan. Het is de informatie die traditioneel op het vondstkaartjes wordt vastgelegd. Een analoge vondstenlijst (vondstnummerlijst) dient meestal als basis voor de invoer. (zie ook discussie bij redundantie). Monsters worden hier op precies dezelfde wijze behandeld als vondsten. Er is dus geen aparte monsternummering of monsterlijst. Alle


9

monsters krijgen een regulier vondstnummer en via het veld categorie wordt aangeven dat het om een monster gaat en voor welk doel het verzameld is. Bij grondmonsters kan bij veldvolume de omvang van het monster worden geadministreerd. vondst_v Key Fieldname Type Length Required Description yes vondstnr Numeric Long yes vondstnummer put Numeric Integer yes putnummer vlak Numeric Integer yes vlak- of profielnummer vak Numeric Integer vaknummer spoor Numeric Long spoornummer vulling Numeric Integer vullingnummer segment Numeric Integer segmentnummer verzamel Character 4 yes verzamelwijze (ref_verz) categorie Character 4 vondst- of monstercategorie (ref_cat) veldvolume Numeric Single volume van het verzamelde (grond)monster (in dm3 = liter) datum Date 8 vondstdatum opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

Grijze velden zijn optioneel. Primaire sleutel: vondstnr Relaties: 1-op-meer relatie met vondst_s, 1-op-1 relatie met vondst_loc, 1-op-1 relatie met vondst_vak en 1-op-1 relatie met vondst_null. Referentietabellen: ref_verz en ref_cat Alternatieven: als de monsters toch apart geadministreerd worden, met een eigen monsternummering, dan heeft dat gevolgen voor de verdere administratie. Het opsplitsen (zie vondstverwerking) van een monster kan achterwege blijven, maar voor de registratie van de opslag (in dozen) is een aparte tabel noodzakelijk.

voorbeeld van een formulier voor de tabel: vondst_v


10

Vondstverwerking Nadat de vondsten gewassen, gedroogd en genummerd zijn worden de vondsten, die veelal uit verschillende categorieën bestaan, opgesplitst. De botten, vuursteen, steen en aardewerk worden afzonderlijk opnieuw verpakt (gesplitst). Daarbij wordt direct geteld en/of gewogen om hoeveel vondsten het per categorie gaat. Elk nieuw vondstzakje bevat, naast de vondsten uit slechts één categorie, ook een nieuw vondstkaartje. Daarop staat de unieke combinatie van het vondstnummer en de materiaalcategorie vermeld. Bij de vondstverwerking vinden dus twee verschillende taken plaats, te weten: - het tellen/wegen van de gesplitste vondsten en - het opslaan daarvan in dozen De weerslag van beide activiteiten wordt vastgelegd in de tabel vondst_s. vondst_s Key Fieldname Type Length Required Description yes vondstnr Numeric Long yes yes categorie Character 4 yes vondstcategorie (ref_cat) aantal Numeric Integer aantal vondsten gewicht Numeric Double gezamenlijk gewicht in gram doos Character 5 doos identificatie opmerking Character 80 INV_DAT Date 8 INV_PERS Character 20

De grijze velden zijn optioneel. Primaire sleutel: vondstnr-categorie Relaties: zie vondst_v en doos Referentietabellen: ref_cat Alternatieven: de documentatie van de inhoud van de dozen, kan eventueel ook via een aparte tabel worden opgelost. Gebruik dan bijvoorbeeld een tabel doos_inhoud, met alleen de variabelen vondstnr, categorie en doos, die dan een “vondst_s”vondstnummer aan een doosnummer koppelt. De variabele doos verdwijnt dan uit de bovenstaande tabel. Alleen een vondstzakje van een gesplitst vondstnummer kan in een doos worden opgeborgen (veld doos, in de tabel vondst_s). Dit gebeurt via een apart formulier waarin de tabellen doos en vondst_s zijn gecombineerd. Dit betekent overigens ook dat elk (grond)monster door de vondstverwerking moet. Daarbij zal het vaak zo zijn dat één vondstnummer (vondst_v) gesplitst wordt in één vondstnummer-categorie (vondst_s).


11

voorbeeld van een formulier voor (primaire) vondstverwerking (vondst_s)

Bij Archol is het splitsen van de vondsten vergaand geautomatiseerd. Het gebruik van barcodes op de vondstkaartjes en de beschikbaarheid van een zogenaamde Splitsmodule maken dit tijdrovende werk makkelijker. Het gewicht wordt, gecorrigeerd voor het leeg gewicht van de minigrip zakjes, direct uitgelezen uit de digitale weegschaal en een nieuw vondstkaartje op de barcodeprinter afgedrukt. De informatie in vondst_s wordt dus direct digitaal verzameld, zonder tussenkomst van een analoog formulier. Vervallen vondstnummers Tijdens de opgraving worden in het veld soms vondstnummers uitgegeven aan, wat later bij de vondstverwerking geen artefact(en) blijkt te zijn. Zo’n vondstnummer kan feitelijk komen te vervallen, maar opdat het op de vondstenlijst en daarmee in de tabel vondst_v voorkomt, wordt het apart geadministreerd. De “lege” vervallen vondstnummers komen voor controle doeleinden in de tabel vondst_null. vondst_null Key Fieldname Type Length Required Description yes vondstnr Numeric Long yes vondstnummer INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: vondstnr Relaties: zie vondst_v Referentietabellen: geen Alternatieven: deze tabel kan volledig achterwege worden gelaten, maar dan is het niet meer mogelijk om te controleren of alle uitgegeven vondstnummer in het veld ook daadwerkelijk door de vondstverwerking zijn afgehandeld.

voorbeeld van een formulier voor de tabel vondst_null


12

Vondstopslag en -uitleen Vondstdozen In deze tabel wordt bijgehouden welke opslagdozen er bij de opgraving zijn. Elke doos heeft een eigen uniek doosnummer, dat vooraf wordt gegaan door de letter “D”. Dit is niet noodzakelijk, maar hiervoor is gekozen ten behoeve van de controle bij de geautomatiseerde verwerking van de doosinhoud. Door het gebruik van barcodes op alle dozen en gesplitste vondstkaartjes kunnen de unieke nummers snel en foutvrij worden ingelezen. Alle zakjes die in een doos zitten worden even allemaal met de barcode scanner “gebleept” en automatisch wordt voor de vondsten vastgelegd dat ze zich in deze doos bevinden (zie tabel vondst_s).

Ten behoeve van een controlemogelijkheid worden hierbij alleen gesplitste vondstnummers geaccepteerd: met vondstnummer en een categorie. Tevens worden de vondstnummers op de vondstkaartjes (en in de barcode) voorafgegaan met de letter “V” en de doosnummer met een “D”. Bij het scannen van een barcodes controleert het formulier dan of er niet per ongeluk een doos in vondstenzakje of een doos in andere doos worden gebleept.

voorbeeld van een formulier voor de opslag van de gesplitste vondsten (vondst_s)


13

doos Key Fieldname Type Length Required Description yes doos Character 5 yes doos identificatie (D####) categorie Character 4 vondstcategorie (ref_cat) bewaar Character 8 bewaarcondities in depot (ref_bewaar) gewassen Boolean 1 alle vondsten zijn gewassen genummerd Boolean 1 alle vondsten zijn genummerd instelling Character 6 locatie waar de doos zich bevindt (ref_inst) contact Character 20 contactpersoon (voor adresinformatie zie inst_adres) dat_weg Date 8 uitleen datum dat_terug Date 8 verwachte datum retour opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

Grijze velden zijn optioneel. Primaire sleutel: doos Relaties: 1-op-meer relatie met de tabel vondst_s en 1-op-1 relatie met de tabel inst_adres. Referentietabellen: ref_cat, ref_bewaar en ref_inst Alternatieven: de bewaarcondities zijn hier opgenomen om een controle mogelijk te maken of de dozen voldoen aan de eisen van het provinciaal depot. In de referentietabel ref_cat (vondstcategorie) is daarvoor tevens een extra veld toegevoegd. Deze mogelijkheid is optioneel.

voorbeeld van een formulier voor tabel doos (doosuitleen)

Adresgegevens Deze tabel wordt gebruikt om de locatie van de vondstdozen bij te kunnen houden. Per door wordt aangegeven bij welke instelling de doos zich bevindt: “opgravingslocatie” of uitgeleend aan. In de tabel inst_adres worden éénmalig de contactgegevens vastgelegd van de betrokken (archeologische) instellingen.


14

inst_adres Key Fieldname Type Length Required Description yes instelling Character 6 yes instellingscode naam Character 60 yes naam van de instelling of organisatie straat Character 30 yes straatnaam nummer Character 6 yes nummer (incl. bijv. a/b/h/bis) postcode Character 8 yes postcode plaats Character 30 yes plaatsnaam telefoon Character 11 telefoonnummer fax Character 11 e_mail Character 30 algemeen e-mail adres INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: instelling Relaties: zie doos Referentietabellen: ref_inst

voorbeeld van een formulier met adresgegevens voor de doosuitleen (inst_adres)

3. Vondstcontext administratie De contact administratie bestaat uit een groot aantal min of meer samenhangende tabellen. De beschrijving van de (vondst)context is heel sterk afhankelijk van de manier waarop wordt opgegraven. Het gebruik van begrippen als vakken, sporen, lagen, segmenten en vullingen verschilt van opgraving tot opgraving, van opgravende instantie tot instantie. Dit heeft consequenties voor het ontwerp van de tabellen en gebruikte formulieren (zie ook de paragraaf Alternatieve opgravingsmethoden). Grondsporen kunnen heel eenvoudig zijn, met één homogene (op)vulling, maar in veel veldsituaties is de beschrijving en documentatie van een grondspoor zeer complex. Een spoor wordt soms in delen (coupes, segmenten) opgegraven, er worden verschillende (op)vullingen onderscheiden, vullingen hebben een vlekkerige, heterogene textuur en kleur met verschillende insluitsels. Dit zorgt er voor dat er, soms zelfs per opgraving, voor verschillende documentatie vormen wordt gebruikt. In dit databaseontwerp is gekozen voor een documentatie met de volgende terminologie en hiërarchie: put-vlak-spoor-vulling-segment.


15

De tabel put vormt de eerste tabel van een aantal samenhangende tabellen, waarin de (vondst)context wordt beschreven. Bij de invoer van onderliggende tabellen vindt telkens een controle op de integriteit plaats. Zo worden bijvoorbeeld de tabellen put en vlak gebruikt om te voorkomen dat (grond)sporen met een (nog) niet gedocumenteerd/bestaand vlak kunnen worden ingevoerd. Put Deze tabel vormt samen met de tabel vlak de (basis)administratie van de aangelegde putten en vlakken. put Key Fieldname yes put opmerking INV_DAT INV_PERS

Type Numeric Character Date Character

Length Required Description Integer yes putnummer 80 8 invoer datum en tijd 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: put Relaties: 1-op-meer relatie met de tabel vlak Referentietabellen: geen Alternatieven: geen Vlak In deze tabel wordt bijgehouden welke vlakken er per put zijn aangelegd. Er zijn altijd één of meer vlakken per put. De begindatum van het eerste vlak en de einddatum van het laatste vlak beschrijven wanneer de gehele put is opgegraven. Profielen worden hier beschouwd als verticale vlakken en krijgen “gewoon” een vlaknummer. Bij het type wordt aangegeven of het om een vlak of profiel gaat. vlak Key Fieldname yes put yes vlak type begin einde opmerking INV_DAT INV_PERS

Type Numeric Numeric Character Date Date Character Date Character

Length Integer Integer 4 8 8 80 8 20

Required Description yes putnummer yes vlak- of profielnummer vlak of profiel (=verticaal vlak) (ref_vlak) yes startdatum opgraven van dit vlak/profiel yes einddatum opgraven van dit vlak/profiel invoer datum en tijd invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: put-vlak Relaties: 1-op-meer relatie met de tabel spoor en zie put Referentietabellen: ref_vlak Alternatieven: de profielen kunnen ook in een aparte tabel worden geadministreerd met een eigen profielnummering. Het veld type is dan niet meer nodig. Consequenties: Indien de profielen apart worden geadministreerd ontstaat bij de (grond)spoor documentatie een gecompliceerdere situatie. De grondsporen die in de


16

profielen zijn waargenomen, zijn uniek op basis van de combinatie put-profiel-spoor, terwijl in de vlakken dit de combinatie put-vlak-spoor is. Door de sporen niet op elk vlak opnieuw te nummeren, maar per put door te nummeren, kan dit probleem weer worden ondervangen. Zo’n andere primaire sleutel in de tabel spoor (put-spoor) zal dan ook in de onderliggende tabellen moeten worden aangepast.

voorbeeld van een ingevuld formulier voor de tabellen put en vlak

Spoor De tabel spoor beschrijft alle kenmerken van de (grond)sporen in de opgraving. De grondsporen worden hier in principe per vlak geadministreerd. Lagen worden op dezelfde wijze behandeld als grondsporen. Een bewoningslaag (niveau) is feitelijk en heel groot grondspoor, dat gewoon een spoornummer krijgt en bijvoorbeeld in segmenten van 1 bij 1 m. wordt opgegraven. De NAP-hoogte van de bovenzijde van het spoor kan (automatisch) worden toegevoegd vanuit de landmeetkundige gegevens of vanuit de vlaktekening worden afgeleid en ingevoerd. De variabele datering wordt tijdens het veldwerk als een voorlopige indicatie gebruikt. Een groep grondsporen vertoont een grote gelijkenis in hun vorm, begrenzing en/of vulling (kleur, textuur) en zouden chronologisch bij elkaar kunnen horen. Ze worden zodanig als een groep “neolithisch”, “fase 3” of “groep geel” gedocumenteerd. spoor Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlak- of profielnummer yes spoor Numeric Long yes spoornummer type Character 3 aard van het grondspoor (ref_spr) vorm Character 3 vorm in het opgravingsvlak (ref_vorm) contour Character 4 begrenzing van het grondspoor (ref_cont) gecoupeerd Boolean 1 is het grondspoor gecoupeerd nap Numeric Single yes nap bovenzijde van het spoor diepte Numeric Integer yes diepte onder het opgravingsvlak (in cm.) datering Character 7 Archis codering (ref_dat) of relatieve fasering structuur Character 10 structuur identificatie opmerking Character 80 INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon


17

De grijze velden zijn optioneel. Primaire sleutel: put-vlak-spoor Relaties: 1-op-meer relatie met de tabel vulling, 1-op-meer releatie met spoorrel en zie vlak en structuur Referentietabellen: ref_spr, ref_vorm, ref_cont en ref_dat Alternatief: hoewel de sporen in principe per vlak worden geadministreerd, kan er toch voor worden gekozen om de (grond)sporen door te nummeren per put of zelfs voor de gehele opgraving. Dit biedt bijvoorbeeld de mogelijkheid om, zonder dat er uitgebreide spoorrelaties worden gedocumenteerd, af te leiden dat het bij 12-2-35 (put-vlak-spoor) en 12-3-35 om hetzelfde spoor gaat dat op twee opeenvolgende vlakken is geconstateerd.

voorbeeld formulier van de tabel spoor, met gerelateerde vulling(en) en relatie(s)

Structuren Zowel tijdens het veldwerk als bij de analyse van de grondsporen kunnen individuele sporen aan een structuur (huis, spieker, hek) worden toegewezen. Op basis van de ligging, vorm, vulling en/of gelijke (vondst)datering wordt aangenomen dat ze een structuur hebben gevormd. Bij elk grondspoor kan worden aangegeven tot welke structuur deze vermoedelijk heeft behoord. Dit geschiedt op basis van de tabel structuur. Deze tabel functioneert tevens als een soort referentie tabel (keuzemogelijkheden) voor de eindgebruiker. structuur Key Fieldname Type Length Required Description yes structuur Character 10 yes structuur identificatie type Character 5 structuur beschrijving (ref_stru) opmerking Character 80 INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: structuur Relaties: 1-op-meer relatie met de tabel spoor Archol – database structuur veldmodule

18

Referentietabellen: ref_stru Alternatieven: geen Spoorrelaties Bij de spoorrelaties wordt aangegeven dat grondsporen elkaar oversnijden, bij elkaar horen of identiek zijn. Grondsporen zijn identiek als ze bijvoorbeeld in twee (aangrenzende) putten zijn waargenomen. Het is in principe aan de gebruiker om er zorg voor te dragen dat als het spoor 12-3-35 (put-vlak-spoor) het spoor 12-3-89 oversnijdt, dit bij beide grondsporen (dus twee keer) wordt ingevoerd: - 12-3-35 oversnijdt (jonger dan) 12-3-89 - 12-3-89 wordt oversneden door (ouder dan) 12-3-35 Er zijn hiervoor overigens ook geautomatiseerde oplossingen denkbaar. spoorrel Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlak of profiel identificatie yes spoor Numeric Long yes spoor identificatie yes relatie Character 6 yes samenhang tussen sporen (ref_sprel) yes rel_put Numeric Integer yes gerelateerd spoor: putnummer yes rel_vlak Numeric Integer yes gerelateerd spoor: vlak identificatie yes rel_spoor Numeric Long yes gerelateerd spoor: spoor identificatie opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

Grijze velden zijn optioneel. Primaire sleutel: put-vlak-spoor-relatie-rel_put-rel_vlak_rel_spoor Relaties: zie spoor Referentietabellen: ref_sprel Alternatieven: geen Vullingen en segmenten In onze opgravingsmethodiek worden de segmenten als ondergeschikt geschouwd aan de vullingen. De vullingen zijn “natuurlijke” eenheden waarin de archeologische vondsten zijn terecht, terwijl de segmenten de door ons “arbitrair” aangelegde coupes, kwadranten of segmenten zijn. De analyse van de vondsten (datering/ functie van een grondspoor) geschiedt op basis van de vullingen (zie voor een uitgebreidere discussie de paragraaf Alternatieve opgravingsmethoden).


19

Vulling Deze tabel wordt gebruikt om de vullingen te beschrijven. Hier wordt de (op)vulling van een grondspoor gedocumenteerd door middel van kleur, textuur en karakter. vulling Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlak- of profielnummer yes spoor Numeric Long yes spoornummer yes vulling Numeric Integer yes vullingnummer tint Character 1 tint (ref_tint) bijkleur Character 2 bijkleur (ref_kleur) hoofdkleur Character 2 hoofdkleur (ref_kleur) textuur Character 4 bodemtextuur (ref_text) org_stof Character 3 gehalte aan organische stof in de bodemtextuur (ref_orgs) karakter Character 5 homogeniteit/vlekkerigheid van de vulling (ref_vulk) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

Grijze velden zijn optioneel. Primaire sleutel: put-vlak-spoor-vulling Relaties: 1-op-meer relatie met segment en zie spoor Referentietabellen: ref_tint, ref_kleur, ref_text, ref_orgs en ref_vulk Alternatieven: hier kan slechts het algemene karakter van een vulling worden gedocumenteerd, via een referentie tabel (ref_vulk) met bijvoorbeeld: “mangaan”, “ijzer/oer”, “fijne houtskoolspikkels” of “grote scherpe kleiige vlekken”. Er kan ook een aparte tabel insluitsel worden gebruikt in plaats van een variabele karakter. Zo’n aparte tabel geeft de mogelijkheid om voor meerdere insluitsels exact de samenstelling, grootte en begrenzing te documenteren. Segmenten In deze tabel wordt eigenlijk alleen vastgelegd in welke segmenten een bepaalde vulling is geconstateerd. segment Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlaknummer yes spoor Numeric Long yes spoornummer yes vulling Numeric Integer yes vullingnummer yes segment Numeric Integer yes segmentnummer opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: put-vlak-spoor-vulling-segment


20

Relaties: zie vulling Referentietabellen: geen Alternatieven: de vullingen kunnen ook ondergeschikt worden beschouwd aan de segmenten. In die situatie moet de hiërarchie van beide tabellen worden omgekeerd en veranderen de sleutelvariabelen (zie paragraaf Alternatieve opgravingsmethoden).

voorbeeld van een formulier voor de tabel: segment

4. Foto administratie De foto administratie bestaat uit twee samenhangende onderdelen, te weten: - de algemene gegevens over elke individuele foto/dia/digitale opname: tabel foto - de beschrijving van één of meer onderwerpen die op de foto staan (put-vlakspoor: tabel foto_onderw Foto In deze tabel worden de algemene gegevens van een foto vastgelegd. Het eerste veld van de tabel, de foto identificatie, is als tekstveld gedefinieerd om gebruik te kunnen maken van de bestandsnamen die digitale camera’s veelal gebruiken. foto Key Fieldname Type Length Required Description yes foto Character 12 yes foto identificatie medium Character 5 foto medium (ref_fotom) type Character 5 onderwerpstype van de foto (ref_otype) fotograaf Character 20 yes richting Character 4 op basis van ref_richt (n,o,zw,nno) fotobord Boolean 1 fotobord gebruikt datum Date 8 yes opname datum opmerking Character 80 nadere beschrijving gefotografeerd onderwerp INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: foto Relaties: 1-op-meer relatie met de tabel foto_onderw Referentietabellen: ref_fotom, ref_otype en ref_richt Alternatieven: als op de foto een Noordpijl wordt mee gefotografeerd kan het veld richting achterwege blijven.


21

Foto onderwerp(en) In deze tabel wordt beschreven welke grondsporen op de foto staan. Er kunnen meerdere sporen op één foto staan en er kunnen meerdere foto’s van hetzelfde spoor zijn. Maar op één foto kan noot meer dan één keer de combinatie van put-vlak-spoor voorkomen. Vandaar dat al deze velden samen de unieke samengestelde sleutel vormen. Deze tabel wordt gebruikt om bij het grondsporen overzicht. Zo kan worden weergeven op welke foto(‘s) het betreffende spoor staat. foto_onderw Key Fieldname Type Length Required Description yes foto Character 12 yes foto identificatie yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlaknummer, gebruik vlaknummer 999 bij putoverzichten yes spoor Numeric Long yes spoornummer, gebruik spoornummer 9999 bij vlakfoto's opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: foto-put-vlak-spoor Relaties: zie foto Referentietabellen: geen Alternatieven: deze gehele tabel zou achterwege gelaten kunnen worden. Er is dan alleen een administratie van de genomen foto’s/dia’s.

voorbeeld van een ingevuld formulier voor de tabellen: foto en foto_onderw


22

5. Tekening administratie De tekeningen administratie bestaat uit twee samenhangende onderdelen, te weten: - de algemene gegevens over een tekening (tekenblad): tabel tekening - de één of meer onderwerpen die op de tekening staan: tabel tek_onderw Tekening In deze tabel wordt de algemene informatie over een tekening (tekenblad) opgenomen. tekening Key Fieldname Type Length Required Description yes tekenblad Character 12 yes tekenblad identificatie soort Character 7 tekenblad soort (ref_bladsrt) datum Date 8 yes datum waarop met de tekening gestart is opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum INV_PERS Character 20 invoer tijd

De grijze velden zijn optioneel. Primaire sleutel: tekenblad Relaties: 1-op-meer relatie met tek_onderw. Referentietabellen: ref_bladsrt Alternatieven: er is hier uitgegaan van het idee dat er op één tekenblad meerdere onderwerpen (deeltekeningen) kunnen staan. Bijvoorbeeld zowel een vlak- als coupetekeningen van hetzelfde grondspoor, elk met een eigen tekenaar en schaal. Deze variabelen zijn daarom opgenomen in de tabel tek_onderw Tekening onderwerp(en) In deze tabel wordt beschreven wat er exact op elke tekening staat. Op één tekening kunnen meerdere (verschillende) sporen staan, maar één spoor kan ook meerdere keren op één tekening staan. Bijvoorbeeld zowel als vlak- en als coupetekening. Om deze reden vormen het tekenblad, put, vlak, spoor en type de primaire samengestelde sleutel. Komen er meerdere coupetekeningen van één spoor op één tekening voor, dan is het voldoende op dit slechts één keer in de tabel te vermelden. Deze tabel vormt de basis waarop, in het grondsporen overzicht, wordt getoond op welke tekening(en) het grondspoor staat. tek_onderw Key Fieldname Type Length Required Description yes tekenblad Character 12 yes tekenblad identificatie yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlaknummer yes spoor Numeric Long yes spoornummer, gebruik spoornummer 9999 bij vlaktekeningen yes type Character 4 yes type tekening: vlak, profiel, coupe (ref_otype) tekenaar Character 40 yes naam tekenaar schaal Character 10 schaal van de tekening opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon


23

De grijze velden zijn optioneel Primaire sleutel: tekenblad-put-vlak-spoor-type Relaties: zie tekening Refrentietabellen: ref_otype Relaties: een 1-op-meer relatie met de tabel: tekening Alternatieven: deze tabel kan volledig achterwege gelaten worden als alleen een administratie van de tekenbladen noodzakelijk is. Daarvoor moeten dan wel de velden type, tekenaar en schaal naar de tabel tekening worden overgeheveld. Daarbij kan dan slechts één type, tekenaar en schaal per tekening worden gedocumenteerd.

voorbeeld van een ingevuld formulier voor de tabellen: tekening en tek_onderw

5. Landmeetkundige informatie Voor het uitzetten van de opgravingsputten en het inmeten van vlakken, sporen en/of vondsten wordt, vanouds, landmeetkundige apparatuur gebruikt. Een waterpasinstrument of (infrarood) theodoliet is bij een opgraving net zo gebruikelijk als een schep en troffel. Het verzamelen van landmeetkundige gegevens is een specialistische taak, die veelal een eigen stroom gegevens oplevert. Een deel van die informatie wordt in de database opgenomen. Dit kan in aparte tabellen (coordinaten, vlakhoog, spoorhoog, vondst_loc, vondst_vak) worden opgeslagen of (in)direct worden geïmporteerd in specifieke velden (variabele nap, in de tabel spoor). Bijvoorbeeld in de situatie van de vlakhoogtes geldt dat die informatie veelal uitsluitend op de analoge of digitale vlaktekeningen staat. Dezelfde informatie zou ook in de database kunnen worden opgenomen (tabel vlakhoog). Die vrijblijvendheid geldt echter niet voor bijvoorbeeld de puntvondsten (tabel vondst_loc). De structuur van de tabellen is afgestemd op de gebruikte landmeetkundige apparatuur (Sokkia Total Station, TS). De huidige software (Mapsuite+) waarmee de digitaal geregistreerde metingen van de infrarood theodoliet worden verwerkt, kent enkele specifieke export formaten. Om het importeren van die gegevens in de tabellen mogelijk te maken, is de volgorde van de velden daarop aangepast en zijn extra


24

velden toegevoegd (metingnr, put_vlak). In de voorbeeld formulieren is de ordening van de velden echter weer op een inhoudelijk manier. Vlakhoogtes In deze tabel worden NAP-hoogtes van elk opgravingsvlak vastgelegd. De volgorde van de velden en de variabele put_vlak zijn specifiek voor de gebruikte landmeetkundige apparatuur. vlakhoog Key Fieldname Type Length Required Description metingnr Numeric Long metingnummer X_rd Numeric Double yes x-coördinaat in RD (in m.) Y_rd Numeric Double yes y-coördinaat in RD (in m.) nap Numeric Double yes NAP hoogte (in m.) put_vlak Character 15 import TS put Numeric Integer yes putnummer vlak Numeric Integer yes vlaknummer X_lokaal Numeric Double x-coördinaat in lokale meetstelsel (in m.) Y_lokaal Numeric Double y-coördinaat in lokale meetstelsel (in m.) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer tijd

De grijze velden zijn optioneel. Primaire sleutel: er is in eerste instantie geen primaire sleutel voor de tabel, uiteindelijk zou de combinatie put-vlak-metingnr uniek kunnen zijn. Relaties: geen Referentietabellen: geen Alternatieven: De velden X_lokaal en Y_lokaal zijn hier optioneel. Als de registratie van de opgraving in een lokaal meetsysteem plaatsvindt kunnen de velden X_rd en Y_rd vervangen worden door de lokale coördinaten. De lokale coördinaten zouden hier feitelijk achterwege gelaten kunnen worden.

voorbeeld van een formulier voor de tabel: vlakhoog


25

Spoorhoogtes In deze tabel worden de metingen geïmporteerd van de grondsporen. Bij de huidige opgravingsmethodiek wordt van elk grondspoor, ongeveer in het midden, een hoogtemeting gedaan, waarbij direct het spoornummer digitaal wordt geregistreerd. Deze gegevens worden in eerste instantie geïmporteerd in de tabel spoorhoog en later gebruikt om het veld nap (in de tabel spoor) te vullen. De volgorde van de velden en de variabele put_vlak_spoor zijn specifiek voor de gebruikte landmeetkundige apparatuur. spoorhoog Key

Fieldname Type Length Required Description metingnr Numeric Long metingnummer X_rd Numeric Double yes x-coördinaat in RD (in m.) Y_rd Numeric Double yes y-coördinaat in RD (in m.) nap Numeric Single yes NAP hoogte (in m.) put_vlak_spoor Character 15 import TS put Numeric Integer yes putnummer vlak Numeric Integer yes vlaknummer spoor Numeric Long yes spoornummer X_lokaal Numeric Double x-coördinaat in lokale meetstelsel (in m.) Y_lokaal Numeric Double y-coördinaat in lokale meetstelsel (in m.) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer tijd

De grijze velden zijn optioneel. Primaire sleutel: er is in eerste instantie geen primaire sleutel voor de tabel, uiteindelijk zou de combinatie put-vlak-spoor uniek moeten zijn. Relaties: indirect (update-query) met spoor Referentietabellen: geen Alternatieven: De velden X_lokaal en Y_lokaal zijn hier optioneel. Als de registratie van de opgraving in een lokaal meetsysteem plaatsvindt kunnen de velden X_rd en Y_rd vervangen worden door de lokale coördinaten. De lokale coördinaten zouden hier feitelijk achterwege gelaten kunnen worden.

voorbeeld van een formulier voor de tabel: spoorhoog


26

Puntvondsten Vondsten die bijvoorbeeld bij de (machinale) aanleg van een vlak of bij het opschaven worden gedaan, maar niet uit een grondspoor komen, worden veelal als puntvondst ingemeten. Puntvondsten worden met de Total Station ingemeten en de gegevens worden geïmporteerd in de tabel vondst_loc. Ook bij speciale vondsten of monsterpunten worden de puntlocaties landmeetkundige ingemeten. De volgorde van de velden is specifiek voor de gebruikte landmeetkundige apparatuur. vondst_loc Key Fieldname Type Length Required Description metingnr Numeric Long metingnummer X_rd Numeric Double yes X-coördinaat in RD (in m.) Y_rd Numeric Double yes Y-coördinaat in RD (in m.) nap Numeric Single yes NAP hoogte (in m.) yes vondstnr Numeric Long yes vondstnummer X_lokaal Numeric Double X-coördinaat in lokaal meetstelsel (in m.) Y_lokaal Numeric Double Y-coördinaat in lokaal meetstelsel (in m.) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

De grijze velden zijn optioneel. Primaire sleutel: vondstnr Relaties: zie vondst_v Referentietabellen: geen Alternatieven: De velden X_lokaal en Y_lokaal zijn hier optioneel. Als de registratie van de opgraving in een lokaal meetsysteem plaatsvindt kunnen de velden X_rd en Y_rd vervangen worden door de lokale coördinaten. De lokale coördinaten zouden hier feitelijk achterwege gelaten kunnen worden. Soms worden puntvondsten (alleen) op de vlaktekening aangegeven. De coördinaten worden dan handmatig of bij het digitaliseren van de tekening opgenomen en handmatig in deze tabel ingevoerd, waarbij de NAP-hoogte vaak oningevuld blijft.

voorbeeld van een formulier voor de tabel: vondst_loc


27

Vakvondsten Vondsten die bij de aanleg van een (eerste) vlak worden gedaan, worden soms per vak verzameld. Afhankelijk van de grootte van de opgravingsput of vondstdichtheid kan dat in (vierkante) vakken van bijvoorbeeld 2 bij 2, 5 bij 5 of 10 bij 10 meter geschieden. Vakvondsten worden hier op eenzelfde wijze behandeld als puntvondsten. Waarbij het centrum van het vak wordt ingemeten en de grootte van het vak (lengte, breedte) handmatig wordt ingevoerd vanaf de (schetsmatige) vlaktekening. De volgorde van de velden is specifiek voor de gebruikte landmeetkundige apparatuur. vondst_vak Key Fieldname Type metingnr Numeric X_rd Numeric Y_rd Numeric nap Numeric yes vondstnr Numeric X_lokaal Numeric

Length Required Description Long metingnummer Double yes X-coördinaat in RD (in m.) van centrumpunt Double yes Y-coördinaat in RD (in m.) van centrumpunt Single yes NAP hoogte (in m.) van centrumpunt Long yes vondstnummer Double X-coördinaat in lokaal meetstelsel (in m.) van centrumpunt Y_lokaal Numeric Double Y-coördinaat in lokaal meetstelsel (in m.) van centrumpunt lengte Numeric Single yes lengte van het vak (in m.) breedte Numeric Single yes breedte van het vak (in m.) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon

De grijze velden zijn optioneel Primaire sleutel: vondstnr Relaties: zie vondst_v Referentietabellen: geen Alternatieven: De velden X_lokaal en Y_lokaal zijn hier optioneel. Als de registratie van de opgraving in een lokaal meetsysteem plaatsvindt kunnen de velden X_rd en Y_rd vervangen worden door de lokale coördinaten. De lokale coördinaten zouden hier feitelijk achterwege gelaten kunnen worden. Het gebruik van vakvondst heeft als belangrijk nadeel dat de context (geologische, bodemkundige of antropogene laag) waaruit ze komen niet (vanzelf) wordt vastgelegd. Vakken zouden bij voorkeur als segmenten van een laag (grondspoor) moeten worden beschouwd (zie voor een uitgebreidere discussie de paragraaf Alternatieve opgravingsmethoden).


28

Conclusies In dit document is een structuur voor een velddatabase gepresenteerd. Op tal van plaatsen is er al op gewezen dat hiervoor een eenvoudige en praktische oplossing is gekozen. Er is, ons inziens, geen enkelvoudige, universele oplossing voor de velddocumentatie mogelijk. De specifieke opgravingsmethode, manier van documenteren en de organisatie van de dagelijkse werkzaamheden zijn nauw met elkaar verbonden, willen we effectief kunnen opgraven. Het is niet haalbaar en waarschijnlijk zelfs niet wenselijk om één database standaard voor alle opgravingen na te streven. Het huidige database ontwerp heeft, op basis van een aantal praktische en databasetechnische compromissen, een bruikbaar resultaat opgeleverd. Het biedt niet altijd de ideale, precies op maat gesneden, oplossing, maar met een aantal kleine aanpassingen kan een opgravingsproject snel van start gaan. Door gebruik te maken van de standaard mogelijkheden die Access in de vorm van formulieren biedt, kan de gebruikersinterface zonder zeer uitgebreide programmeerervaring worden aangepast en onderhouden.


29

Voorbeelden van referentietabellen De referentietabellen hebben in principe allemaal dezelfde structuur, die bestaat uit slechts twee variabelen: code en omschrijving. De gebruikte codes kunnen van project tot project worden aangepast. De inhoud van de referentietabellen kan worden veranderd zonder dat de gebruikersinterface (de formulieren) moet worden gewijzigd, zolang de naamgeving van de tabel en de twee variabelen niet wordt veranderd. ref_bewaar code omschrijving BREEKBR breekbaar DROOG droog bewaren GEMENGD gemengde bewaarcondities MINIMAAL geen specifieke bewaarcondities VOCHTIG vochtige bewaren

ref_bladsrt code omschrijving A0 mm F film, mm, A0 formaat A3 mm F film, mm, A3 formaat A4 mm F film, mm, A4 formaat A4 mm P papier, mm, A4 formaat

ref_cat code omschrijving bewaar BOT bot MINIMAAL GLS glas BREEKBR KBW bouwaardewerk MINIMAAL KER aardewerk MINIMAAL KHL hutteleem BREEKBR KPY pijpen BREEKBR KSC sculpturen BREEKBR LEE leer VOCHTIG MA monster algemeen MINIMAAL MAR monster arthropoda MINIMAAL MBOT monster van klein botmateriaal MINIMAAL MC14 monster voor C14-datering MINIMAAL MCR crematiemonster MINIMAAL MD monster voor dendrochronologie MINIMAAL MDI monster diatomeeën MINIMAAL ME monster ecologisch MINIMAAL MEA ecologisch, 10mm MINIMAAL MEB ecologisch, 4mm MINIMAAL MEC ecologisch, 2mm MINIMAAL MED ecologisch, 1mm MINIMAAL MEE ecologisch, 0.5mm MINIMAAL MEF ecologisch, 0.25mm MINIMAAL MFF fosfaatmonster MINIMAAL MHK houtskoolmonster MINIMAAL MHT houtmonster MINIMAAL MIX gemengd GEMENGD


30

code omschrijving bewaar MP pollenmonster MINIMAAL MPA botanie, 10mm MINIMAAL MPB botanie, 4mm MINIMAAL MPC botanie, 2mm MINIMAAL MPD botanie, 1mm MINIMAAL MPE botanie, 0,5mm MINIMAAL MPF botanie, 0,25mm MINIMAAL MSC schelpenmonster MINIMAAL MSL monster slijpplaat MINIMAAL MTL metaal MINIMAAL MZ zadenmonster MINIMAAL MZA zoologie, 10mm MINIMAAL MZB zoologie, 4mm MINIMAAL MZC zoologie, 2mm MINIMAAL MZD zoologie, 1mm MINIMAAL MZE zoologie, 0.5mm MINIMAAL MZF zoologie, 0.25mm MINIMAAL MZO monster onverkoolde zaden MINIMAAL MZV monster verkoolde zaden MINIMAAL PHK houtskool DROOG PHT hout VOCHTIG PLT plantaardig VOCHTIG PMA plantaardige macroresten VOCHTIG SCH schelp MINIMAAL SLK metaalslakken MINIMAAL SPC speciale vondsten BREEKBR STN natuursteen MINIMAAL TOU touw VOCHTIG VST vuursteen MINIMAAL XXX overig GEMENGD opmerkingen: in deze referentie tabel zijn zowel de verschillende categorieën monsters als vondsten opgenomen. Het extra veld bewaar is voor controle doeleinden toegevoegd (zie ook de beschrijving van de tabel doos). De categorie SPC (speciale vondsten) is toegevoegd om individuele vondsten uit een vondstzakje te kunnen halen en apart te administreren in de tabel vondst_s. Deze vondsten kunnen in een aparte doos worden opgeslagen, apart behandeld en/of uitgeleend aan een onderzoeker of tentoonstelling. Ze blijven echter eenduidig geadministreerd.

ref_complex code omschrijving DEPO depot EX economie, onbepaald GVX grafveld, onbepaald GX graf, onbepaald IX infrastructuur, onbepaald NBAS basiskamp/-nederzetting NEXT extractie kamp NS stad NX nederzetting, onbepaald RX religie, onbepaald VX verterking, onbepaald XXX onbekend opmerkingen: selectie uit het ABR (Archis).


31

ref_cont code omschrijving SCH scherpe begrenzing VG vage begrenzing VVG vervagende begrenzing

ref_cultuur code omschrijving ACH Acheuleen AHR Ahrensburg-cultuur CRE Creswell-cutuur EEM Eems-cultuur EGK Enkelgraf-culttur ELP Elp-cultuur HAM Hamburg-cultuur HAZ Hazendonk-cultuur HKL Hoogkarspel-cultuur HVS Hilversum-cultuur INH Inheems-Romeins KB Klokbeker-cultuur LBK Lineaire bandkeramiek LMS Late Mesolithic survival LWC Leijen Wartena complex MAG Magdelenien-cultuur MK Michelsberg-cultuur MOU Mousterien-cultuur MTA Mousterien de tradition Acheuleene NGK Nederrijnse grafheuvel-cultuur NWK Nordwest Kreis RBK Rhine Basis Kreis RO Rössen-cultuur ROM Romeins SOM S.O.M./Stein/midden-neolithicum Limburg SWI Swifterbant-cultuur TJO Tjonger-cultuur TRB Trechterbeker-cultuur VLA Vlaardingen-cultuur WKD Wikkeldraad-cultuur XXX onbekend ZEI Zeijen-cultuur opmerkingen: selectie uit het ABR (Archis).

ref_dat code begin_dat eind_dat omschrijving BRONS -2000 -800 Bronstijd BRONSL -1100 -800 Late Bronstijd BRONSM -1800 -1100 Midden Bronstijd BRONSV -2000 -1800 Vroege Bronstijd IJZ -800 -12 Ijzertijd IJZL -250 -12 Late Ijzertijd


32

code begin_dat eind_dat omschrijving IJZM -500 -250 Midden Ijzertijd IJZV -800 -500 Vroege Ijzertijd LME 1050 1500 Late Middeleeuwen MESO -8800 -4900 Mesolithicum MESOL -6450 -4900 Laat Mesolithicum MESOM -7100 -6450 Midden Mesolithicum MESOV -8800 -7100 Vroeg Mesolithicum NEO -5300 -2000 Neolithicum NEOL -2850 -2000 Laat Neolithicum NEOM -4200 -2850 Midden Neolithicum NEOV -5300 -4200 Vroeg Neolithicum NT 1500 2003 Nieuwe tijd (tot heden) NTA 1500 1650 Nieuwe tijd A NTB 1650 1850 Nieuwe tijd B NTC 1850 2003 Nieuwe tijd C (tot heden) PALEO -350000 -8800 Paleolithicum PALEOL -35000 -8800 Laat Paleolithicum PALEOM -300000 -35000 Midden Paleolithicum PALEOV -350000 -300000 Vroeg Paleolithicum ROM -12 450 Romeinse tijd ROML 270 450 Laat Romeinse tijd ROMM 70 270 Midden Romeinse tijd ROMV -12 70 Vroeg Romeinse tijd VME 450 1050 Vroege Middeleeuwen XME 450 1500 Middeleeuwen XXX 9999 9999 Onbekend opmerkingen: conform het ABR (Archis), de extra velden begin_dat en eind_dat zijn toegevoegd ten behoeve van de Archis (I)- melding en de mogelijkheid tot een chronologische sortering.

ref_fotom code omschrijving DIA kleuren dia DIGF digitale opname FOTO kleuren foto GBLD grootbeeld opname XXX overig ZWDIA zwart/wit dia ZWFOT zwart/wit foto

ref_geomorf code omschrijving DXX dal/dalvormige laagte GXX glooiïng LXX laagte RTE vlakte RXX rug XXX onbekend opmerkingen: selectie uit het ABR (Archis).


33

ref_inst code omschrijving AAC Amsterdams Archeologisch Centrum ADC Archeologisch Diensten Centrum ARBONE ArchaeoBone ARCHOL Archeologisch Onderzoek Leiden ARPLAN Archeoplan BIAX BIAX Consult FA Faculteit der Archeologie GIA Groninger Instituut voor Archeologie OPGR Opgravingslocatie RAAP Regionaal Archeologisch Archiverings Project ROB Rijksdienst voor het Oudheidkundig Bodemonderzoek TNO TNO/NITG Utrecht

ref_kleur code omschrijving BE beige BL blauw BR bruin GE geel GN groen GR grijs OR oranje RO rood WI wit XX indet ZW zwart

ref_maaiveld code omschrijving AKK akkerbouw/tuinbouw/bouwvoor BEB bebouwing/erf/weg/kerkhof BOO boomgaard BOS bos DUI duin GRA grasland/weideland GRO groeve HEI heide SEC secundaire/opgebrachte grond SLO sloot(kant)/oever STR strand VEE veen WAT water/geul/bank/plaat XXX onbekend ZAN zand(verstuiving) opmerkingen: selectie uit het ABR (Archis).


34

ref_orgs code omschrijving H1 zwak humeus H2 matig humeus H3 sterk humeus Vk1 veen, zwak kleiig Vk3 veen, sterk kleiig Vm veen Vz1 veen, zwak zandig Vz3 veen, sterk zandig opmerkingen: NEN 5104 conform.

ref_otype code omschrijving COUP coupe DET detail DIV meerdere types PROF profiel VLAK vlak

ref_precisie code omschrijving 0 kilometer-nauwkeurigheid (aantal decimalen 0) 1 100m.-nauwkeurigheid (aantal decimalen 1) 2 10m.-nauwkeurigheid (aantal decimalen 2) 3 meter-nauwkeurigheid (aantal decimalen 3) opmerkingen: conform het ABR (Archis).

ref_prov code omschrijving DR Drenthe FL Flevoland FR Friesland GL Gelderland GR Groningen LI Limburg NB Noord Brabant NH Noord Holland OV Overijsel UT Utrecht ZH Zuid Holland ZL Zeeland opmerkingen: conform het ABR (Archis).

ref_richt code N NNO NNW NO NW

omschrijving Noord Noord-Noord/Oost Noord-Noord/West Noord/Oost Noord/West


35

code omschrijving O Oost ONO Oost-Noord/Oost OZO Oost-Zuid/Oost W West WNW West-Noord/West WZW West-Zuid/West Z Zuid ZO Zuid/Oost ZW Zuid/West ZZO Zuid-Zuid/Oost ZZW Zuid-Zuid/West

ref_spr code omschrijving AKR oude akkerlaag AWC aardewerkconcentratie B Inspoelingshorizont BA balk BES beschoeiing BKS bekisting BOC botconcentratie BPA beschoeiing, palen BPL beschoeiing, planken BPT beerput/beerkelder BRL brandlaag BU bustum BUN visbun BV bouwvoor BVO bijzondere vondst C Moedermateriaal CR crematiegraf DIG dierbegraving DK drenkkuil DLT doorlaat(door een muur) DP depressie DR drain E Uitspoelingshorizont EG erfgreppel ES esdek FU fuik GA gracht GE geul/kreek/rivier GHE grafheuvel GR greppel GT goot HA haard HAK haardkuil HG huisgreppel HI hoefindrukken HKC houtskoolconcentratie


36

code omschrijving HO hout HU hutkom IN inhumatiegraf KEL kelder KGO ovale kringgreppel KGR ronde kringgreppel KGV vierkante kringgreppel KL kuil KS karrespoor LAK laklaag LAT latrine LG laag LO ophogingslaag LS stortlaag MI muurinsteek MR muur MSK mestkuil MST muursteen MU muuruitbraak NV natuurlijke verstoring NVD dierlijke verstoring NVP plantaardige verstoring OV oven PA houten paal PAK paal met paalkuil: intact PG paalgat PGK paalgat met paalkuil PK paalkuil PL plank PO poel/ven/meer POT potstal PS ploegspoor PSE ploegspoor, eergetouw PSK ploegspoor, keerploeg REC recente verstoring RPA palenrij RPG rij paalgaten RPK rij paalkuilen RPL rij planken SG standgreppel SI silo SK staak SL sloot SPG spitsgracht SS spitspoor ST steen STC steenconcentratie VL vlek VR vloer VSC vuursteenconcentratie


37

code omschrijving VW vlechtwerk WA waterput WG weg WK waterkuil WL wal WOO woonlaag op een nederzetting WVH wegverharding XXX onbekend opmerkingen: selectie uit het ABR (Archis).

ref_sprel code omschrijving AS hoort bij ID hetzelfde als JD oversnijdt OD wordt oversneden door

ref_stru code omschrijving AFSCH erfafscheiding of palenrij BIJGB bijgebouw ERF erf of woongebied HUIS huis SCHR schuur SPIEK spieker of graanschuur WPUT waterput

ref_text code omschrijving Ks1 klei, zwak siltig Ks2 klei, matig siltig Ks3 klei, sterk siltig Ks4 klei, uiterst siltig Kz1 klei, zwak zandig Kz2 klei, matig zandig Kz3 klei, sterk zandig Lz1 leem, zwak lemig Lz3 leem, sterk zandig Zk zand, kleiig Zs1 zand, zwak siltig Zs2 zand, matig siltig Zs3 zand, sterk siltig Zs4 zand, uiterst siltig opmerkingen: NEN 5104 conform.

ref_tint code omschrijving D donker L licht


38

ref_verwerv code omschrijving AAI aanvullende archeologische inventarisatie AAO aanvullende archeologisch onderzoek ABO archeologisch: boring AIN archeologisch: inspectie AKA archeologisch: kartering AOP archeologisch: opgraving AOW archeologisch: onderwaterarcheologie AXX archeologisch: onbepaald SAI standaard archeologische inventarisatie XXX onbekend opmerkingen: selectie uit het ABR (Archis).

ref_verz code omschrijving AANV aanleg vlak COUP aanleg coupe DETC detectorvondst MAA machinale aanleg MAF machinale afwerking PUNT puntvondst SCHA uitschaven SPIT uitspitten STRT losse stortvondst TROF troffelen ZF1 zeef, 1mm ZF10 zeef, 10mm ZF2 zeef, 2mm ZF4 zeef, 4mm

ref_vlak code omschrijving PROF verticaal profiel VLAK horizontaal vlak

ref_vorm code omschrijving LIN lineair ONR onregelmatig OVL ovaal RHK rechthoekig RND rond VKT vierkant

ref_vulk code omschrijving AS as FE ijzer/oer FF fosfaat


39

code omschrijving HK houtskool HU humus KI kiezel MG mangaan SC schelp VKL verbrande klei/leem


40

Bijlage: Alternatieve opgravingsmethoden Niet bij elke opgraving zal op dezelfde wijze worden gewerkt en gedocumenteerd. Zoals in de inleiding al is beargumenteerd is een min of meer op maat gemaakt documentatiesysteem zelfs te prefereren vanuit het oogpunt van efficiëntie en kwaliteit. Het streven van één uniforme databasestandaard is ook niet strikt noodzakelijk, mits elke database maar wordt vergezeld van een duidelijke beschrijving van de gehanteerde begrippen, variabelen en coderingen (metadocumentatie). Voor de hierboven beschreven velddatabase zijn een aantal methodische, praktische en technische keuzes gemaakt, die onlosmakelijk verbonden zijn met onze huidige opgravingspraktijk en technische hulpmiddelen (Total Station, geautomatiseerde Splitsmodule). Dit maakt dat de gepresenteerde database waarschijnlijk niet direct, ongewijzigd bij een andere opgraving kan worden ingezet. Wel staan de verschillende taken relatief los van elkaar en kunnen in principe als een soort “building blocks” bij andere projecten worden toegepast. Tevens zijn, per tabel, al (kleine) alternatieven vermeld. Hieronder zijn een aantal alternatieven en gebruiksmogelijkheden nader uitgewerkt, waarin de consequenties van een andere opgravingsmethode voor de tabelstructuur wordt aangestipt. Deze paragraaf geeft aan tot waar de flexibiliteit van het huidige ontwerp reikt en waar ingrijpender wijzigingen noodzakelijk zijn. Sporen per put of per vlak Bij sommige opgravingen worden de grondsporen niet direct gecoupeerd, maar wordt alleen de vorm, omtrek en vulling in het vlak gedocumenteerd. Als het vlak is getekend wordt tot het tweede vlak (machinaal) verdiept en de grondsporen opnieuw aangekrast. De grondsporen worden daarbij vaak per vlak opnieuw genummerd en beschreven. Vorm en interpretatie kunnen daarbij van vlak tot vlak verschillen. De sequentie van opeenvolgende vlakken geeft een (3D)beeld van de doorsnede van het grondspoor. Hetzelfde grondspoor komt dus meervoudig in de documentatie voor (bijvoorbeeld put 23-vlak 2-spoor 24 en put 23-vlak 3- spoor 11). Er moet worden gedocumenteerd dat de “grondsporen” een onderlinge relatie hebben: 23-2-24 is identiek aan 23-3-11. Bij andere opgravingen wordt een grondspoor direct op het eerste vlak waarop het zichtbaar is gecoupeerd. Het krijgt vaak een uniek identificatienummer binnen de put, maar onafhankelijk van het vlak: put 23 – spoor 28. Natuurlijk wordt het vlak wel gedocumenteerd. Een grondspoor komt maar één keer in de administratie voor en heeft maar één vorm en één interpretatie. Bij de spoorrelaties komt dan meer de nadruk te liggen op het feit of er sporen geassocieerd zijn of samen tot één structuur behoren. Voor beide benaderingen geldt dat er voor- en nadelen aan zijn verbonden. De databasestructuur hoeft echter niet persé te worden aangepast. Het huidige ontwerp, waarin put-vlak-spoor de sleutel vormt, kan dit verschil aan. Eventueel zouden de relaties tussen de tabellen aangepast kunnen worden.


41

Aparte monsternummers of houtnummers Bij sommige opgravingen worden monsters apart behandeld en genummerd. Er is dan een afzonderlijke monsteradministratie, met eigen formulieren en een eigen tabel, die wat betreft de structuur sterk op die van vondst_v lijkt. Hier is er voor gekozen om dat niet te doen en monsters net als een vondst te behandelen. De verdere verwerking van de monsters kan dan op dezelfde wijze als van de vondsten plaatsvinden. Een aparte monsteradministratie maakt kleine aanpassingen aan de administratie van de doosinhoud noodzakelijk. Het gebruik van een letter “M” voor de monsternummers, naast de “V” (vondsten) en “D” (dozen) is dan een vaker toegepaste oplossing. Soms worden ook alle houten vondsten apart gedocumenteerd (houtlijst), veelal ten behoeve van een specifieke verdere behandeling en natte opslag. Voor een zo’n eenvoudig mogelijke administratie en eenduidige procedure verdient het de voorkeur dit niet te doen. Als de hout-vondsten gewoon mee gaan in de reguliere procedure, is de kans op fouten in de administratie het kleinst. Overigens geldt, misschien nog wel in sterkere mate, ook voor unieke, speciale vondsten. Geen vondstnummer en unieke ID’s (enkelvoudige sleutel) Bij sommige opgravingen worden geen vondstnummers gebruikt, maar wordt per vondstzakje uitsluitend de unieke combinatie van put-(vlak-)spoor op het vondstkaartje vastgelegd. Aan zo’n vondst-identificatie 28-1-18 is direct te zien waar de vondsten vandaan komen en kunnen bij elkaar in een vondstdoos worden opgeborgen. Het is tegenwoordig niet meer nodig en wellicht zelfs onverstandig om dat op die manier te blijven gebruiken. Elke vondst/vondstzakje krijgt nu een uniek vondstnummer, waarvan (uitsluitend) op de vondstenlijst wordt gedocumenteerd uit welke vondstcontext deze vondsten komen. De gehele verdere vondstverwerking en doosadministratie zijn gebaseerd op het gebruik van dit unieke nummer. Wordt er besloten om het betreffende grondspoor toch nog een ander nummer te geven, dan hoeft dat alleen in de digitale vondstenlijst te worden veranderd. Zonder dat dit vergaande praktische en database technische consequenties heeft. Als archeologen zijn we gelukkig traditioneel al gewend aan dit soort genormaliseerde documentatie systemen, we geven vrijwel alles al een uniek nummer (tekenblad, fotonr, spoornr, putnr, etc., etc.). De in de AHR-specificaties (SiteInfo) gebruikte unieke enkelvoudige sleutels om elke waarneming in elke tabel te identificeren, is een te ver doorgevoerde normalisatie. Vroeger moest dat wellicht, om technische redenen, toegepast worden, maar een meervoudige sleutel is met de hedendaagse databasesoftware geen enkel probleem meer. Het uitgeven van een unieke vondst_id terwijl we al een uniek vondstnummer gebruiken is onzinnig en onwerkbaar. Op elk vondstkaartje dat de materiaalspecialisten bij de uitwerking gebruiken staat immers het vondstnummer en niet een door de software uitgegeven, voor de gebruik onzichtbaar vondst_id. Terwijl dat vondst_id wel weer nodig is om voor elke uitgewerkte vondst te achterhalen uit welk grondspoor dit komt. Inhoudelijke velden (put-vlak-spoor) gebruiken om een vondstzakje uniek te kunnen identificeren is niet correct. Het gebruik van uitsluitend enkelvoudige, software gegenereerde, sleutels is echter ook niet aan te bevelen. De normalisatie die wij als archeologen gebruiken in de vorm van een uniek vondstnummer is goed genoeg.


42

Vakken of segmenten Bij de tabel vondst_vak is al aangegeven dat in het veld blijkbaar soms de behoefte bestaat om (aanleg)vondsten in een grotere verzameleenheid onder te brengen, zonder al direct de context te moeten vastleggen. In een put wordt een eerste opgravingsvlak aangelegd. De losse vondsten bij het machinaal aanleggen van dat vlak en het handmatig opschaven worden verzameld in vakken van 5 bij 5 m. De ene opgraver zal zeggen: deze vondsten zijn zeker waardevol om te documenteren, maar ik wil nog niet een uitgebreide sporen/lagen documentatie uit de kast trekken. In put 18, zijn bij het machinaal aanleggen van vlak 1, in vaknummer 3 (zie schetsmatige vlaktekening) de vondsten gedaan, die zijn verzameld onder vondstnummer 3267. De context van vondstnummer 3267 is dus: put 18- vlak 1- vak 3, waarbij er helemaal geen laag wordt gedocumenteerd. Een andere opgraver zal echter zeggen dat er een vondstlaag (de geploegde bouwvoor, Ap) wordt opgegraven (machinaal verdiept). In put 18 ligt op vlak 1 (maaiveld) een grondspoor (laag) met het nummer 32 (de Ap). De vulling van dit grondspoor is een donker bruine, sterk gevlekte, zwak humeuze zandlaag. De vondsten komen uit segment (vak) 3 (zie schetsmatige vlaktekening). De context van vondstnummer 3267 is dan dus: put 18- vlak 1-spoor 32- vulling 1- segment 3. In de dagelijkse praktijk van het archeologisch veldwerk worden beide oplossing toegepast. Zonder een oordeel te willen vellen over welke documentatie manier beter is, mag duidelijk zijn dat dit verschil wel gevolgen heeft voor de manier waarop de informatie in de database terecht komt. In het huidige ontwerp is primair gekozen voor de tweede oplossing. Toch bestaat de mogelijkheid om vak vondsten op dezelfde wijze te behandelen als puntvondsten en is in de tabel vondst_v een veld vak beschikbaar. Vullingen en segmenten Grote, complexe grondsporen worden vaak onderzocht met behulp van meerdere coupes en kennen meerdere opvullingen. De documentatie daarvan is vaak grafisch, in de vorm van verschillende coupe-tekeningen, goed vast te leggen. Een tekstuele beschrijving daarvan in een database is echter niet zo eenvoudig. Een grondspoor (een grote egale kuil) wordt in eerste instantie op het vlak gedocumenteerd, er wordt een vlaktekening van gemaakt en het grondspoor krijgt spoornummer 38. Het bestaat uit een egale, lichtgrijze zandige klei: vulling 1. Dit grondspoor wordt vervolgens gecoupeerd en de eerste helft wordt al schavend verdiept. De vondsten worden onder één vondstnummer verzameld, waarbij ze dezelfde vondstcontext (zelfde vulling als in het vlak) krijgen. Als er een donkere vulling op de bodem zichtbaar wordt, worden de vondsten daaruit apart geadministreerd, vulling 2: een gevlekte, donkergrijze klei. Nadat de coupe is getekend wordt de tweede helft, per vulling, uitgeschaafd en de vondsten bij de overeenkomstige vondsten van de eerste helft gevoegd.


43

De segmenten spelen hierbij eigenlijk niet of nauwelijks een rol. Ze zijn kunstmatig, toevallig door ons zo aangelegd op basis van de gekraste coupelijn. Als ze al gebruikt worden is dit ondergeschikt aan de vulling en alleen om aan te geven in welk segment de betreffende vulling(en) zijn gezien. De vullingen zijn bovengeschikt aan segmenten. vondstnummer put vlak spoor vulling 1511 18 2 38 1 1512 18 2 38 2

(gezien in) segment 1 en 2 1 en 2

Als alternatieve benadering geldt: een spoor wordt op het vlak direct in 2 (of meer) segmenten verdeeld. Per segment wordt zo’n grondspoor schavend verdiept en worden de vondsten uit de verschillende vullingen apart verzameld. De indeling in vullingen in het ene segment komt niet per definitie overeen met de indeling in het andere segment. Zo wordt er wel eens in het eerste segment helemaal geen onderscheid gemaakt in vullingen en pas op basis van de coupetekening besloten om de vondsten uit aparte vullingen te verzamelen. De segmenten zijn weliswaar nog steeds arbitrair, maar zijn bovengeschikt aan de vullingen. Voor de vullingen moet dan, in een aparte tabel, wel worden gedocumenteerd wat de onderlinge relatie is: segment 1-vulling 1 is identiek aan segment 2-vulling 3 of segment 1-vulling 1 is de gemengde vondstcontext van segment 2–vulling 1 en 2. De segmenten zijn bovengeschikt aan de vullingen. vondstnummer put vlak spoor segment 1511 18 2 38 1

vulling 1 (gemengd licht en donker grijze (zandige) klei)

1512 1513

18 18

2 2

38 38

2 2

1 (licht grijze zandige klei) 2 (donker grijze klei)

Waarschijnlijk zijn beide oplossingen even goed bruikbaar, maar hebben wel gevolgen voor de structuur van de database. In het huidige database ontwerp is voor de eerste oplossing gekozen. Wordt er voor de tweede oplossing gekozen dan zijn er andere tabellen (segment_relaties, vulling_relaties), volgorde van de variabelen (putvlak-spoor-segment-vulling) en tabelrelaties noodzakelijk.


44

Een database structuur voor opgravingsgegevens Archol, voorjaar 2004 (Concept)

Recommend Documents