I have followed only partially this discussion. From a point of view of the intended scope of
the CIDOC CRM, which tries to provide a high-level model of cultural information, it appears to
me that ALGAO defines concepts that may be quite helpful to map to the CIDOC CRM, in order to
achieve the degree of interoperability a CRM compliant solution can provide.
From CIDOC-CRM, we would give all support to such a comparison.
best regards,
Martin
> Nigel Pratt ES wrote:
>
> Posted on behalf of Mark Bennett:
>
> On 08/05/02 Bob Sydes asked: "Anyone out there wish to defend the ALGAO position?"
>
> I notice that no one has yet argued for the ALGAO definition of event. Since here in Lincolnshire we use the ALGAO definition and do not
> record desk-based assessments (DBAs) as events in the SMR database I thought I would lay out the argument in case it helps. I suspect, in some
> ways, that this particular discussion would have been better on the SMR forum rather than the FISH forum, but it has continued to be debated
> here while the thread on the SMR forum stopped after only a few postings.
>
> If anyone is unfamiliar with the definitions, the ALGAO definition of an event basically is the collection of primary data (including null
> data) of a single data type, within a definable spatial area, at a particular date and by a particular data collector. The MIDAS definition is
> somewhat wider and includes "any event, or activity, which has enabled information to be gathered, or a judgement to be made, about a monument
> in a particular locality" (MIDAS manual p.14).
>
> I believe what ALGAO is trying to do by defining an event so rigidly is to restrict events to those activities where primary data is
> physically collected on site. It also allows different types of primary data collection to be separated out in a database. The
> Event-Monument-Archive data structure then allows this primary data to be interpreted to create monument records and this process is supported
> by the archive (the sources of information that have been used). The process of primary data collection, interpretation and monument creation
> is one of the things that a traditional SMR records. The ALGAO definition allows a database to separate the primary data collection phase from
> the interpretation phase in this process. The primary data can then be revisited and reinterpreted and the changing interpretation would be
> reflected in the associated monument records.
>
> A DBA does not always involve the collection of primary data from a site, it is usually the collation and interpretation of data which already
> exists and this, sometimes, will lead to the identification of 'new' monuments. In other words it is research. If a DBA does include a site
> visit, usually a walk-over survey, then that would involve the collection of primary data and the site visit would be recorded as an event
> following the ALGAO definition.
>
> It is perfectly possible to record what I have called 'the interpretation phase' as an event under the MIDAS definition. These are sometimes
> called interpretation events. One might well call a DBA an interpretation event but if you do then, in the interests of data consistency (to
> which all database managers aspire), you should also record as events other pieces of research that interpret archaeological and historic
> evidence. Thus, for example, an article discussing the interpretation of a particular cropmark, a book on medieval settlement that interprets
> evidence from place-names and maps to identify deserted medieval villages, a comment by the sixteenth-century traveller and scholar John
> Leland which has been interpreted as a reference to a medieval chapel site. (It is worth noting that any of these examples might appear in a
> DBA.) If you do not do this you are treating the DBA as a special case, and database managers hate special cases. Nevertheless, I can see why
> archaeologists, planning archaeologists especially, would want a record of a detailed study of a particular site.
>
> Incidentally if anyone wants to know how we record DBAs if not as events, we have a separate database for development control reports that is
> used to monitor their incorporation into the computerised SMR and to index them (we have had over 2100 reports since 1990). Because this
> database contains a grid reference it can be imported into the GIS and my development control colleagues use the GIS to check sites for any
> DBA that is in the system. DBA reports are also recorded as sources within the computerised SMR with a link to the appropriate monument
> records.
>
> Mark Bennet
> Lincolnshire SMR
> Lincolnshire County Council
>
>
> ********************************************************************************
> Note: We are a Microsoft Office site. Our base version is 4.3. Please make sure
> that files you send can be read in this format.
>
> Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and/or publication of this e-mail is strictly
> prohibited save unless expressly authorised by the sender.
>
> The information contained in this message is intended for the named
> recipients only. It may contain privileged and confidential information and if you
> are not the addressee or the person responsible for delivering this to the addressee,
> you may not copy, distribute or take action in reliance on it.
> If you have received this message in error, please notify the sender(s)
> immediately by telephone. Please also destroy and delete as soon as possible
> the message from your computer.
>
> *****************************************************************************************************************************************************
>
> This email (including any attachments) is intended only for the recipient(s) named above. It may contain confidential or privileged
> information and should not be read, copied or otherwise used by any other person unless express permission is given. If you are not a named
> recipient, please contact the sender and delete the email from your system. It is the recipient's responsibility to ensure that appropriate
> measures are in place to check for software viruses.
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(810)391625 |
Principle Researcher | Fax:+30(810)391609 |
Project Leader SIS | Email: [log in to unmask] |
|
Information Systems Laboratory |
Institute of Computer Science |
Foundation for Research and Technology - Hellas (FORTH) |
|
Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
|
