ISOOD - International Standard of Pipe Organ Documentation
Version 2012-11-23. (Copyright) idea and introductory framework for IS by Jurij Dobravec, Ars Organi Sloveniae



Contents

1. Preamble
2. Metadata
3. Technical background (in preparation)
4. Communication (in preparation)
5. Procedure (in preparation)


1 Preamble
Core significance of pipe organ is to support musicians in transferring art of music to audience. However, with millenary development, it's basic purpose exceed into fields of technics and design, history and education, common culture and spiritual life. So now-a-day, we can think about pipe organ as both, a science and a beauty, or of construction, sound and sight.
Pipe organ is a heritage genuine and origin in Europe and therefore a reflection of common European spirit. As opposite to many other types of usable heritage we are dealing here with objects where usage means out-wearing.
Intention of standard is not to uniform pipe organ as an instrument or to confine art of organbuilding, but to uniform data about the instrument. Intention of this standard is to better understand the instrument and to be more effective in communication. Therefore ISOOD is facility for integration of heterogeneous pipe organ information. It should serve as a communication tool for manifold characteristics of pipe organs, as well as a bridge among involved sectors. Standard is not a goal but explicitely a tool.
Core standard should be uniform and unique. But, because of variability of involved sectors, for each of them a special sub-standard should be developed. It is expected that some sectors will share the same data.
Beside, within individual sectors, data and communication should be split into two equally important layers: internal and external. Internal, deeper, is used within discipline or branches, for management, preservation, education, research, or specific projects. External, mostly simplified, is used in process of communication with laics, either specific or common, but in any case the most important target audience.
ISOOD has to base on networking of existing know-how solutions.


1.2 Quality starting point
In scope of preparing quality international standard, which would serve to a broad audience of European (or World) users, we should follow some facts listed below at the very beginning:
- Pipe organ is a complex instrument and a culture object that many different groups are interested in. Core standard have to be the same for all, substandards are expected to be developed separately for organbuilding, acoustics, history style and design, conservation, technics, maintenance.
- Many persons, states and regions developed their own local database since now, with implemented norms suitable for their areas; many existing solutions are useful and welcome to ISOOD
- Existing official or semi-official pipe organ standards have to be included in a greatest possible level (like ISO, ANSI, DIN, VOD, OHS ...).
- Structure of standard have to be compatible (link-able) with standardized and/or official databases that exists in the fields of discussion (geodetic systems, cultural heritage cadastres, names of administrative units and units itself, ownership cadastre/catalogues, library systems for bibliography, etc.)
- Standard will/would be used on different levels of deepness.
- Standard is prepared and will be used in international and interlingual surroundings.
- Standard structure have to be simple but open for upgrade and interconnections.
- Standard framework and solutions have to (should) be(come) state-of-the-art example for databases of other types of in-use cultural heritage.


1.3 Looking forward = looking for effectiveness
Standard structure have to be developed as clear as possible. Inputs and outputs have to be conspicuous at each point of dataflow. Users have to easily get strait answers to the questions:
what (in sense of present - what is this item in the database and what does it mean),
why (in sense of past - why this data stands in the database) and
what for (in sense of future usefulness, ... and to justify expenditures)

plus

where (in sense of connecting with other spatial features and needs, especially heritage) and
when (in sense of historical context)

But, before we start with database itself, we should resolve the three general steps:

1.3A General system step, where we agree/adopt decision(s) what the object is, or objects are.
Explanation: From acoustics point of view, pipe organ is a complex instrument, strictly speaking a mixture of different instrument-like voices and sounds. Each acoustical part of organ can produce a sound of itself, therefore could be considered as an instrument itself as well. On a contrary, only integral union of all sonic (sub)objects is a useful object for performance and listening. In the middle stands parts that are technically separable but acoustically integral, like ranks of pipes of one stop.
Suggestion: Multiobject database e.g. five hierarchically dependent types of objects: [1]instrument's milieau, [2]instrument, [3]keyboard (Werk), [4]rank and [5]pipe. First object is unmovable, other four are movable (in a sense of database and in a sense of objects itself)

1.3B General technical step, where we should decide about controlled vocabulary and terminology use, and form of their description, as well as language, spelling and literation.
In technical sense, the database itself would operate with codes and IDs instead of words. But for the sake of human communication (and finally standard is a communication tool) we have to
[1]- agree precise meaning of each part of database contents (what is and what is not)
[2]- define primary language used for each part (Suggestion: define German as a core language for technical part, define French as core language for acoustical parts, define English as a core language for communication and descriptions. Exceptions should be considered at characteristic terms, like ripieno, batalla etc., which are commonly used already)
[3]- optionally define translations of interface and expressions to other European languages

1.3C General proceeding, where we reconcile, who is responsible for what during preparation, and especially, which body is in charge of adoption of final result or/and confirmation of separate stages.


1.4 Structure, contents and actions
After consensus about above general steps, we can proceed to database standard itself:
[1] database structure,
[2] database contents (categories and items) and
[3] survey (or input) questionnaire.
Strict distinction of three entities of standard (and each sub-standard) with different characteristics should be recognized. Each of them should be planned, used and manipulate in it's own way.
Structural, technical, pilot testing and communication development should run in-parallel. Contents of database should never be finished. Along, there is no final result predicted. Database have to be finished to the draft level from whish we can easily get final results in dependance of demands or needs.



2. Metadata of the Pipe organ database
Fundamentally, data management is arranging of data with intention to analyse, extract and present information. If we store more data, we can get better answers to our queries. Conversely, reducing the amount of stored data might improves performance and reduce costs. Cost-benefit balance is mostly the main reason for data management.


2.2 History, theory and status
In the past, before computer era, a large amount of data was hard to manage. Later, computer datasheets was just an (insufficient but necessary) introduction to 70s, when Oracle and IBM developed relational structure of database. From then on it seem to many people that machines could resolve our brain's deficiency.
Actually, amount of data is not the only parameter important for database. There are others, among them perhaps we should accent two, the structure quality and the quality of input. In computer database science a well known abbreviation is known, "GIGA", that does not mean Greek ???? as giant, but "Garbage In, Garbage Out". Computer tools are more or less of no use in case of directed by unsuitable structure. As well, results of analyses are ineffective without well established background in quality.
A database is a structured collection of data. There exists databases where every data field is known (or can be known). We can call them full-array databases. From developer point of view they are easy to construct and setup. For example database of goods in store, or bank accounts with clients and transactions, or regular population surveys, or particles for pipe organ construction. Statistics on such databases is rather easy. Today's' computer tools in the field of database management are mostly developed for those kinds of bases.
But there are data in our world for that we perceive a kind of order, but it cannot be arranged into full array. Particular facts are either unavailable (for example historical data), dynamic and too complex (like biological parameters of ecosystem), unreachable (in astronomy), partly or fully overlapping, or simply out of recent (or past) science paradigm. Statistics and analyses might be very complicated, and use of statistical improper methods might direct us to incorrect results and interpretation.
Beside, we know data where common public interest for collecting exists at relatively low level (like cultural heritage incl. pipe organ - with exception of few attractions). At the latest, cost-benefit balance is of even greater significance.


2.3 Pipe organ data towards quality information
It is nice to have a database, but it is not sufficient. Database have to fulfil it's primary purpose: to result information. This information should be objectively transferable across different systems.
At work with databases where full-array cannot be reached by any reason, we have to be aware of:
- shortages of existing computer database tools
- expected higher complexity of analyses
- broader confidence interval needed at statistics
- greater uncertainty of results
There are many reasons why pipe organ heritage database can not be full-arrayed. Just think about historical data of now demolished instruments that are in many cases unavailable, or, some places are too remote to perform a survey by qualified person, or, some of existing data are of poor quality or out-dated, etc.
In spite of problems we are dealing with existed, nonexisted or expected data, it is by all means possible to setup a suitable and high quality database. To fulfil this presumption, in not-full-array database management, we have to follow a principle of so called meta-knowledge. In other words, it has to be clear on a higher level (mostly even without need to consider contents itself) what we do know and what we do not know.
This meta-knowledge might be express on two (in linear sense) levels: at some data a simple yes-no structure is sufficient, on others, graduated or continuous structure of quality evaluation is necessary. First level is a simple one, the second more complex. In both principles data itself has to be accompaniments with a structure of quality, a kind of parallel meta-database for each record and even for each data in particular cases.

What does it mean? For example, let's take a simple datasheet with data arrayed into 5 columns with 100 rows. For the simplest meta-knowledge about each record we should establish additional column in which a status of fulfilment of basic 5 columns should be recognized (yes-no structure). Such status could be of course defined by computer itself - mostly by using a suitable SQL query. So in cases where all 5 fields would be filled, a value in meta-column stands 1, otherwise 0.
In more complex cases a creator/manager of databases have to decide himself about level of quality of each particular record or each field. Levels of such valuation (continuous or categorized, nominal or ordinal, or other kinds) should be generally reconciled by experienced content specialists before use of database.

Although somehow subjectively and in many cases generalized, this meta-data is not just important for experts during statistical and other kinds of analyses, but extremely important for common use of database, for example by culture heritage officers, teachers, tourist guides and similar - significant target groups for promotion and fundraising.

Beside linear evaluation systems, more comprehensive, two or higher dimensional systems are possible. In two dimensions a pivot table is one example of possible approach to recognize meta-status of database. Higher dimensions are perhaps harder to understand for most of us.


2.4 Interconnected quality of dataflow and workflow
In not-full-array databases we have to consider about some another characteristics of data that will rise it's quality in a relatively simple way.
2.4A First, empty record represents data as well. For example: for each empty field of database array we should know why a record is missing (doesn't exist, not surveyed, insignificant, not enough certain to be considered ...).
2.4B Second, false data is data as well. Surveys (and conclusions on their bases) are not always perfect. Even in science literature errors might be noticed. From practice we know that many database managers simply delete and correct an error just after they got better input (by instantaneous knowledge). In sense of clarification we should rather establish a strike-through system instead of replacing.
2.4C Third, tracking of changes. Not only explicit errors but many other categories, like unsureness, suppositions, oddities... In now-a-days database management, there is no need to care about existence or non-existence of garbage. Today, it is important to develop skills, how to manage them. Many of computer database tools (software) already contain modules for tracking of user actions.



2.5 Conclusion of metadata chapter
All above in draft mentioned tools of metadata system have at least three useful application
- (internal) workflow monitoring
- (internal and external) quality supervision
- base for better analyses and results (simple way of excluding parts of databases that are under defined/chosen quality level)
The ability of working in such a way we can improve our ability to design good representations, storage mechanisms, and future analysis tools for data. And finally to reach better cost-benefit balance.


Used background literature for this version (draft)
Minimum Categories for Museum Objects: Proposed Guidelines for an International Standard
Core Data Index to Historic Buildings and Monuments of the Architectural Heritage
Digitisation Standard Landscape
Categories for the description of Works of Art
Guidelines for Museum Object Information : The Information Groups and Categories
Systeme documentaire des peintures et enluminures (France)
Unified Passport for Museum Object (USSR)
Objets religieux. Methode d'analyse et vocabulaire (Canada - France)
Manuel de normes. Documentation des collections africaines./ Handbook of Standards. Documenting African Collections
Methode d'interventaire informatique des objets: beax-arts et arts decoratifs (France)