rybesh
commented
10 years ago Re: issue categorizations; yes these are fully customizable. Once we have a few more we can think about better ways to organize them.
As far as preserving original text, the intention for start/stop endpoint values is that the "label" property in the PeriodO JSON (see for example https://github.com/periodo/examples/blob/master/data.json#L58) should contain the original text parsed by the input interface. So we need to make sure that is what is happening, and perhaps make it clearer in the UI that the original text is being maintained.
As for the spatial coverage values: what we really need here are some "cataloging rules." How would you instruct a student to select spatial coverage values, given some text in a source? Once we can decide on these rules, we can come up with a way of representing the data that reflects them. Right now we have a kind of odd mix of mostly modern nations but a few things like "Roman Empire," and it's unclear why one or the other was chosen.
atomrab
sarahab
and
ptgolden
via @atomrab: I wanted to move our discussions into the issue tracker, since I've found that as productive, if not more so, in other projects than long email threads.
I don't know if one can add categories for labels for issues, but I'd like to have something to set apart actual bugs, enhancements, and questions from larger theoretical issues. Does anyone have a suggestion for a tag we can put in a title for bigger-picture issues like this one? Or is this just really an enhancement?
Now on to the issue.
I wanted to submit this issue to check in with you and Ryan about the display of the periods entered in the client you're building. One of the principles I assume we want to maintain is the preservation of the original terms in which a given period was described (so even if we're representing it as ISO dates, we keep the original statement that it was "early 5th century BCE-25 CE" etc.). Right now it looks like BCE, for example, gets translated to BC, and ISO-style dates (e.g. -700) aren't recognized by the parser.
Obviously we'll need to normalize the dates on the back end and in the representation, but I'd find it helpful if the edit/browse interface retained the original label for display, either alone or in combination with the normalized ISO dates. I think it makes most sense to be explicit about any transformations that are happening between the temporal coordinates as expressed by the source and the information we're collecting.
Right now I think it's impossible not to mask the spatial transformations, though -- so when someone says that a period applies to "Mesopotamia", we're stuck making some deductions about the modern nations to which that applies. It will be interesting to see if we can get anywhere with ancient gazetteers or data sources -- Pleiades or maps of the extent of the Roman Empire, for example. But here too I'd be in favor of being as explicit about deductions as possible.