I'm not so sure I'd be so quick over those functional categories...

Is the functional classification system based on the primary intended function
at the point of manufacture, or the primary intended use at the point of
acquistion (ie, a cup made for drinking tea, but acquired to display on a
dresser)?

If primary intended function at the point of manufacture, how will the database
allow cataloguers to include data on polyfunctionality where that data is
identifiable?

Note that I'm not arguing against including functional categories if that's what
you want to do (as some people have mistakenly believed when I've previously
raised this issue), simply noting that the assumptions underlying those
functional categories should be suitably queried and justified before they're
included.  Otherwise one of those tricky reviewers might ask precisely the sort
of question I'm asking.  Sorry if this causes a fuss, but I'm writing something
on this very topic right now, so it's very much on my mind.

Otherwise, I agree with Lauren Cook (and no doubt a lurking George Miller) that
'ironstone' is an extremely problematic ceramics term, and I similarly don't use
it.  Citations can be provided if necessary.  Here in Australia there isn't any
white granite (in the tightest definition of the term) until the US Civil War
forces Staffordshire potters to dump their American market materials on other
markets, so it provides a particularly nice and potentially important temporal
control.

And I also agree with Morgan Blanchard that any concerns over spending a lot of
time typing in identical information in multiple can be mitigated by using some
sort of auto-fill feature in the database - which also has the benefit of making
sure that everyone is using the same terminology when used.

Alasdair Brooks




> Date: Wed, 25 May 2005 09:39:39 -0400
> From: Mike Striker <[log in to unmask]>
> Subject: Historical Analysis Databases
>
> ~~~~
>
> I have been charged with the task of reworking the Access database in
> which our company catalogs and classifies historical artifacts.  Our
> database must meet two goals: One, to provide a catalog of artifacts
> that is suitable, with some minor manipulation, to meet curational
> requirements, and; two, to provide a functional analysis of the
> artifacts.
>
>
>
> The second part is fairly simple.  We have a classification system that
> can be used to describe artifact function.  It is the first part with
> which we are struggling.  Information is entered into the database on an
> electronic form.  Each artifact or lot of artifacts is given a name such
> as "can, fragment," and a series of attributes is entered.  For a can,
> possible attributes include such things as side seams, top / bottom
> seams, shape, closure, opening, and decoration / label.  Various
> attributes, such as "closure: hole-in-cap," are assigned TPQ and TAQ
> dates that are automatically entered.  The artifact attributes are
> entered through the use of pull-down menus to avoid such things as
> misspellings and formatting variations ("can, fragment" versus
> "Can,fragment") that can result in sorting errors.
>
>
>
> The problem that we're having a hard time getting our heads around is
> artifacts, such as ceramics, where the name of the ceramic type is based
> on the attributes.  For example, we find a lot of ironstone.
> Traditionally, we would include a name such as "ironstone, undecorated"
> and have a second pull-down menu indicating the part, such as "rim
> sherd, bowl."  These, however, are not attributes.  Attributes for this
> item would be things such as paste color (white), degree of paste
> vitrification (semi-vitrified), glaze color (clear), decoration (no),
> etc.  The list of attributes can become quite long, and are implied by
> the name "ironstone, undecorated."  Simply calling something "ironstone,
> undecorated" however, creates an inconsistency in the amount of
> information that is presented from one artifact type to the other.  We
> are no longer providing attributes, but are drawing a conclusion based
> on those attributes.  On the other hand, if the analyst can quickly
> determine that a particular sherd is "ironstone, undecorated," why spend
> the time entering the list of attributes?  If I wished to keep things
> entirely consistent, I would simply have the TPQ and TAQ dates for
> ceramics linked to a combination of the attributes, however, we are
> doing CRM, and reviewers, especially those with a limited knowledge of
> historical artifacts, are going to want to see "ironstone" in the table.
>
>
>
> I would be interested in hearing how others may have dealt with issues
> like these.  Perhaps it isn't an issue at all and I just need to go
> outside and get some fresh air.  Either way, I'd be interested in
> hearing what others have to say.
>
>