- Last Updated on Wednesday, 05 February 2020 11:47
We have designed the database to provide the optimal access to the data we have collected, and so that interested linguists could pursue research agendas that use our database as a testing ground for theories and, more specifically, the analytic generalizations that theories generate. In order to provide optimal access to the data we have elicited, the Afranaph Database was designed to permit online search and manipulation of the data stored in the extensive responses to our various questionnaires and the additional data elicited in follow-up inquiries. In those domains and for those languages for which we have complete data sets, the database permits fine-grained searches to aid in the analysis of both language-internal and crosslinguistic generalizations. Since we are constantly entering new data, our database is dynamic, not only insofar as our search results expand where the data is new, but new forms of data are also added, and thus different sorts of searches become possible as the database design evolves.
Although Afranaph researchers for the various projects have strong theoretical commitments, we have tried to remain as theory neutral as our own generative grammar-oriented prejudices permit when it comes to presentation of the data. We recognize that our neutrality should be suspect. In fact, this is one reason that we provide pdf.s of the questionnaire responses, where possible, in addition to the database resources, so that database property attributions that some may find suspect, or errors that we make even in applying our own system, can be checked, discovered, refuted or improved by those who are willing to delve closely into the data we have collected. Hopefully, we have managed to remain consistent enough in our glossing and property attributions so that search and comparison functions that the database permits will provide pointed and accurate information. We are counting on our users to tell us when we fail.
The 2016 redesign of our database inaugurated the multiportal design, whereby the same database of glossed, translated sentences, the cumulative result of elicitations of all of our projects, can be viewed through portals designed to meet specific needs of one of our research groups. Although all the same sentence-based information is available to all the portals, e.g., one can search for sentences of a certain type or languages of a certain type, it is also possible to search for ‘analytic entities’ which differ in the different portals. More on the multi-portal design.
All of the portals have the same basic design, though the sets of analytic entities differ. At this writing, there are three portals: The Anaphora Portal, the Clausal Complementation Portal and the Generic Portal. The Generic Portal only permits searches for sentences and languages, but the browse page for any language will display all of the analytic entities that are otherwise unique to other portals. Anyone with an interest in languages for which we have data can search our basic sentence data using the Generic Portal with their own agenda in mind, ignoring any categorizations of the specific projects beyond our basic conventions of glossing and morpheme breakdown.
The Clausal Complementation portal has different analytic entities than the Anaphora Portal and thus permits searches that the other portals do not. Thus while research groups can organize data as they see fit, and design properties for entities that help them in their research, all of the sentence data collected for any project expands what is available in all the portals.
The software for this database server was created by Floris van Vugt (programmer) and Alexis Dimitriadis, for the Berlin-Utrecht Reciprocals Survey [LINK?]. The system is designed to house information about languages in a flexible and highly configurable fashion, which has allowed it to be adapted to the needs of multiple Afranaph Projects.
The system is unusual, among databases of this type, in that most questions are not hard-coded into the definition of the database: they are maintained as a separate set of tables that list the questions applying to each entity, and the type of answer(s) that will be accepted. This is what allows the database to be reconfigured for different research projects without much programming. There are no facilities for summarizing or statistics at this time. You can find a presentation of the design principles of the software here: http://languagelink.let.uu.nl/burs/docs/burs-design.pdf
It is normally the case that we only enter data into the database when a questionnaire response is complete or close enough to complete such that we do not expect the data to change radically on the basis of further elicitations in the near future. Whenever there is a significant change in what is in the database, that is, when the data of a language is updated or changed in some way, we will announce changes or work in progress on the case file page for the language in question. If you have used the database to establish a generalization and you are returning to it after a period of time to explore a related question, we recommend checking the case files involved to see if there have been revisions since your last visit.
View: How to Use the Database | Database Property Attributions