I gave up on the work thing about eighteen months ago, but I've recently volunteered for a project documenting a large number of nineteenth century artefacts in an old pharmacist's shop where (a) the owners never threw anything away and (b) sometime in the mid sixties the old man gave up and, unable to sell the business, the family just locked the door and left it.
The actual job itself is quite simple. The people I'm working for use Inmagic for collection management, and what I'll be doing is working through the shelves of the pharmacy documenting/describing each object using a controlled vocabulary (ok, possibly more a folksonomy than a standard controlled vocabulary), and attaching an image.
All done as an excel spreadsheet and imported into Inmagic in as a csv file.
The downside is that as a volunteer, I don't get to play with Inmagic or do the data ingest, but the upside is I'm a volunteer - I just do my thing a couple of days a week, and get to go home when I want.
The actual model of doing it this way is really quite robust and provides a really good methodology for fieldwork and documenting artefacts in the field - all that's needed is a laptop - any laptop running an OS that supports something that can create csv files. No need to worry about 3G connections or anything else.
Such a method is not unique to Inmagic of course. When I was involved in the ANU DataCommons we sought to build a generic solution that was agnostic as to the sort of data we uploaded, purely as the Data Commons was designed as a content agnostic repository.
Change the rules slightly, parse the data on upload according to some set of rules and it could have been turned into a collection management solution.
And this got me thinking about what we've been doing with the whole digital object management thing.
In universities at least the focus has been on building collections of documents - mostly research papers and preprints, but the thing is, because these are textual documents they are self describing - we can extract titles and abstracts, build metadata records and do something a bit like good old fashioned library cataloging.
At the same time archival services use much the same technology to index and publish electronic representations of historic documents, in the main because the archivists already knew what the content was and this allowed them to build large collections as well as using specialist tools such as Omeka to build collection specific sites.
Enter data.
Data is inscrutable. It consists of arbitrarily structured information and without a decent description you are sunk, purely because the structure is arbitrary - it has meaning, but you need to know the structure to understand and interpret (and indeed reuse) the data, which is why in these days of computational analysis all the code and tools used needs to be documented and saved with the object.
If that's true of data, it's even more true for documenting artefacts.
One glass bottle looks much like another, but actually documenting their size and characteristics tells us things.
To explain, think about 330ml beer bottles.
The actual job itself is quite simple. The people I'm working for use Inmagic for collection management, and what I'll be doing is working through the shelves of the pharmacy documenting/describing each object using a controlled vocabulary (ok, possibly more a folksonomy than a standard controlled vocabulary), and attaching an image.
All done as an excel spreadsheet and imported into Inmagic in as a csv file.
The downside is that as a volunteer, I don't get to play with Inmagic or do the data ingest, but the upside is I'm a volunteer - I just do my thing a couple of days a week, and get to go home when I want.
The actual model of doing it this way is really quite robust and provides a really good methodology for fieldwork and documenting artefacts in the field - all that's needed is a laptop - any laptop running an OS that supports something that can create csv files. No need to worry about 3G connections or anything else.
Such a method is not unique to Inmagic of course. When I was involved in the ANU DataCommons we sought to build a generic solution that was agnostic as to the sort of data we uploaded, purely as the Data Commons was designed as a content agnostic repository.
Change the rules slightly, parse the data on upload according to some set of rules and it could have been turned into a collection management solution.
And this got me thinking about what we've been doing with the whole digital object management thing.
In universities at least the focus has been on building collections of documents - mostly research papers and preprints, but the thing is, because these are textual documents they are self describing - we can extract titles and abstracts, build metadata records and do something a bit like good old fashioned library cataloging.
At the same time archival services use much the same technology to index and publish electronic representations of historic documents, in the main because the archivists already knew what the content was and this allowed them to build large collections as well as using specialist tools such as Omeka to build collection specific sites.
Enter data.
Data is inscrutable. It consists of arbitrarily structured information and without a decent description you are sunk, purely because the structure is arbitrary - it has meaning, but you need to know the structure to understand and interpret (and indeed reuse) the data, which is why in these days of computational analysis all the code and tools used needs to be documented and saved with the object.
If that's true of data, it's even more true for documenting artefacts.
One glass bottle looks much like another, but actually documenting their size and characteristics tells us things.
To explain, think about 330ml beer bottles.
- some are brown, some are green
- some have long necks, some short
- some are squat stubby shaped and some are more classic bottle shaped
- some are generic, some have a brewery name moulded in
- some have a manufacturers product code on the base, some don't
in other words, not all beer bottles are the same. And because different bottles can be tied to different breweries, you can start to make statements based on frequency and distribution about people's beer preferences.
This of course works better for nineteenth century bottle dumps, when beer wasn't routinely shipped halfway round the planet, than your neighbourhood bottlebank, but even so you could probably discover some interesting things.
(In fact this might be a really interesting project to do on somewhere like Fiji or Samoa to trace changing trade patterns, much as people have used grecoroman amphora types to trace trade patterns in the early Mediterranean.)
However, the point is that when we document things we implicitly classify them, and it's the classification that turns a list of artefacts into something interesting, which of course means we need to capture the classidication model as well ....
No comments:
Post a Comment