Palinurus said:
Data, I've prepared Event #1710 for reviewing.
The whole entry is problematical for several reasons.
First off, it combines heterogeneous elements which belong together as its title shows: Portents, prodigies and prophecies about destruction of Jerusalem (70 AD) and also because Josephus put them together in one single paragraph.
Secondly, the dating is problematical and there has been ample discussion about it previously which didn't result into a rounded conclusion; so I left the date unchanged for the time being. I've listed the relevant contributions to that discussion for your convenience:
Thanks Palinurus, and in order to answer your questions I have to write a longer, general response,
relevant for all editors:
As the project has been progressing last year, there was some going back and forth between decisions about a) how to date an undated event and b) how to deal with 'mixed' events and Event/Text duplicates etc. I think we all were just beginning to experience the great complexity of the project we've undertaken, and struggling to find solutions to it. Complicating further this already complex matter, we also had to deal with the fact that we're several people, all not yet synchronized with to the 'workflow', and on top of that, using a customly written software / database application that had its own design flaws.
This situation naturally led to more questions than answers, which you brought up Palinurus, which is good. I've been wrestling with these problems myself, and I think with the current HED I've managed to implement a system which allows, in principle, to reach all aims that have been set for this project. With this post I'm going to attempt to clear up some confusion by re-addressing and clarifying stuff.
To recapitulate, the
two aims are, mentioned a few posts earlier by Laura (I'm detailing and rephrasing them):
1. Creation of a
chronology of environmental and social events based on the survey of ancient literature. The generated chronology should hold up to
academic standards and should be
indisputable (in the sense that it is indisputable that our collected texts ARE present in ancient literature).
2. '
Atomization' (splitting up) of 'mixed' reports, where each 'atom' clearly belongs to one, and
only one, category and subcategory]. Doing this allows to:
a) measure the '
weight' or 'event density' of a time period (e.g. one year) by counting the atomized events in that time period,
b) see possible
patterns of events by filtering by category, subcategory, author, keywords, etc.
Both a) and b) are already implemented in the interactive graph of the public interface.
Now, these aims are ideal, and there are number of problems standing in the way in some cases. These problems are already well known by us editors and are ...
The dating problem
Some events do not have a date attached and can only be dated by cross-referencing other literature, by interpolation, and by inferring -- a method that some scholars undertake. A number of you have been attempting to do this, which has produced some 'editorial commentary'. The problems with dating and writing commentary are:
1. It takes a lot of time, energy and knowledge to come to any conclusion in the first place,
2. It takes a lot of time, energy and knowledge to do a 'peer review method' on such commentary (all of which I don't have, but I CAN verify citations),
3. It's possible to come to wrong conclusions and we would add another layer of noise to the raw data and make it
disputable.
Thus,
for this current stage in the project, we give up any attempt of dating or correcting given dates. However, this does
not mean we should delete or ignore undated events.
Enter undated events anyway and submit them for review. The more data is in the database, the more valuable and useful it is!
If a date cannot be explicitly determined from the source, set the special year 9999. Having all such events in one 'virtual' year will allow us later to return to them and work with them. I will make a special listing for such events in the public interface.
Always enter the given date even when you know it's wrong or shifted in the source. This will make our data indisputable. Events which have two different given dates should not be merged, even if you think they are one and the same. We will save this work for a later stage of the project.
Now, some of you, especially Zadig, already have made a lot of efforts writing extensive commentary and attempted to find plausible dates by pulling in other source's information. As mentioned, don't spend time on this any more. But at the same time,
for already written commentary, there is no need to delete it: simply separate your commentary from the actual citation by copy-pasting it into a new text field, and submit the entire event for review anyway. During review, I simply will ignore this commentary and click a checkbox to exclude these commentary from publication. But the information still will be around in the database to help us along in the future. Again, the more structured data is in the database, the more valuable and useful it is.
The splitting (or 'atomizing') problem
(Finally I'm able to come back to your question, Palinurus ;) ) I want to illustrate this problem with Event #1710 which Palinurus just submitted for review. The quotation is from Josephus, and in one paragraph Josephus mentions 7 different classes of relevant (to us) events. It is NOT ENOUGH to simply create ONE Event from this quotation, there must be SEVEN Events with SEVEN DIFFERENT categories. For this particular quotation from Josephus, the 'atomized' events are:
1. Celestial / Comet
2. Environment / Atmospheric Prodigies {the bright light}
3. Environment / Animal Prodigies {the heifer giving birth to a lamb}
4. Environment / Strange Sounds {what the priests heard}
5. Geology / Earthquake {what the priests felt}
6. Celestial / Other {chariots and troops amongst clouds}
7. Other / Other {heavy gate opens by itself}
Categories are always open to discussion and sometimes it's not entirely clear (like the "heavy gate"). But categories can be changed easily later, so don't obsess over it. The important thing is to 'atomize', this gives it 'weight'!
See the 7 different Events made from Josephus' quotation with the SAME Text here: http://hed.quantumfuturegroup.org/events/list?commit=Filter%21&filter1_attr=events.occurrence_year&filter1_value=9999&filter2_attr=&filter2_value=&filter3_attr=&filter3_value=&utf8=%E2%9C%93
Note that in this listing, the date says "undated". This is OKAY and DESIRED for this stage of the project.
The Text duplication problem
Now, for Josephus' just mentioned quotation with 7 different aspects, one could create 7 different Events (as one should), and copy-paste the same quotation again and again. The latter copy-pasting is
not good. This is duplication, which is a lot of work and not good for the database structure. In the newest HED
it is possible to re-use one particular Text across many Events. There is a new input field at the very bottom of the page: "Add existing Text ID". For Josephus' just mentioned quotation, I've added the SAME Text #6206 to 7 different Events. This is quite simple and quick to do, but if you need more info about how it works, just ask here. Doing this will allow the software to NOT reproduce the same Text if it has already been produced.
Summary
You will notice that for the current stage in this project there is a strong empasis on
raw and
structured data, as opposed to analysis, correction and commentary. This should make our job MUCH easier and faster. This current stage in this project will continue until ideally ALL Events which are now in the 'Draft' state, are reviewed and published in the public web interface of the HED.
Editors who 'run out' of draft Events, can either continue adding new data, or assist others.
I hope this clarified some things, if not, just ask, as always! :)