Closed LucasHorseshoeBend closed 3 years ago
NB at present the date of the correspondence is extracted from the filename (the folder name is ignored). Dates which have zeros in the month or day places are understood to represent years, or months, respectively. https://github.com/Conal-Tuohy/VMCP-upconversion/blob/master/xslt/extract-metadata.xsl#L308 The question of how dates are presented to users is something which is much more open in scope; not using XTF for the final publication platform means we have many different options, and I think this is best left until after the first revision of the public website is live (i.e. it should be part of the "public v2" iteration).
Conal, I am going to go through each of your e-mails now, and then go through the remaining issues on the GitHub page, then consider anything else of a coding nature of which I have become aware
For this one, issue # 44, the key is the style named number, which you interpret correctly. We are gradually redating many of these items as we now have access to better dating tools than when we first did some of these before the WWW (!!) and there will be few left dated only to decade.
So I agree that this can be left: its not a coding issue per se. At worst, editors will just need to add a footnote to letters that remain dated only to decade.
Best wishes Arthur
On 17 Feb 2021, at 05:39, Conal Tuohy notifications@github.com wrote:
NB at present the date of the correspondence is extracted from the filename (the folder name is ignored). Dates which have zeros in the month or day places are understood to represent years, or months, respectively. https://github.com/Conal-Tuohy/VMCP-upconversion/blob/master/xslt/extract-metadata.xsl#L308 https://github.com/Conal-Tuohy/VMCP-upconversion/blob/master/xslt/extract-metadata.xsl#L308 The question of how dates are presented to users is something which is much more open in scope; not using XTF for the final publication platform means we have many different options, and I think this is best left until after the first revision of the public website is live (i.e. it should be part of the "public v2" iteration).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Conal-Tuohy/VMCP-upconversion/issues/44#issuecomment-780313780, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF3IGTXOI44M5WUCI37ZFXDS7NJBFANCNFSM4EKRGZKQ.
We can close this issue.
We have redated most of the items originally dated to decade only. Although we have a few from 1880s, and more from the 1890s left to work up, I live in hopes that we can do the same with the remaining ones before they are made final and thus be included in the public presentation version. We are using in the notes a formulation like dated to yyyy as the likely latest/earliest date it could have been written Any residual ones will have a clear statement in the footnotes, and the broad dating will not be a problem in identification.
Another one for when yiou get the funds. Some letters can't be dated more precisely than to the decade. The problem is having items dated to both the decade and those for which a month can’t be assigned in the 0th year showing up as X0-00-00x
I think that there is a way we can distinguish them, without introducing new codes. If we create a new folder within each relevant decadal group, called something like X0sBroad we could indicate by their position in the filing system the ones that were broadly dated, a distinction which would show up in the citation if we use the system of citation generated by Conal’s XTF.
So, for example, we would have folders patterned like this:
1870-79 70sBroad 1870 1871 1872 &c
Rod was not sure what this would be like in practice. He said
I agree that it's highly desirable that we separate the two kinds of file, but I don't know that what you propose will fit the bill. It will clearly effectively separate things in our working files, but we surely also need the difference to show up when a file is viewed on-line? Or are you saying, in your sentence referring to Conal's XTF, which I don't really understand, that the different character of the two kinds of files will also be evident when viewed on-line?
I replied
My comment about Conals XTF citation depends on how we recomend that citations be made.
At the moment, if I search for 60.00.00a [note . not -] in the XTF files, and then select the citation option from near the top right of the window, I get as the citation "http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1860/60-00-00a-final.xml”. If we follow my proposal, it would come up as "http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/60sBroad/60-00-00a-final.xml”, showing that it was not in a specifc year within the 1860-9 group. For the final version the vmcp.conaltuohy.com would be replaced by the server address holding the letters If we recommend a different citation, then this may not work.
But the citation would need to be checked for this to show up. However, when we decide on what the end user is going to see, we could ask that a "cite as” statement appears at the top of each letter. If that could be done, then this will solve the problem. Wewould need to ask for something like “Cite as Home et al, Correspondence of Ferdinand von Mueller, …” where the ending is unique to each letter, something like the current "1860-9/60sBroad/60-00-00a-final.xml”
If a user choses the “data” facet, then instead of the current
collapse data
collapse 1860-9
expand 1860 (111) expand 1861 (113) expand 1862 (170) expand 1863 (169) expand 1864 (169) expand 1865 (203) expand 1866 (208) expand 1867 (152) expand 1868 (133) expand 1869 (171) there would be an extra line above 1860, saying “60sBroad” or whatever we call the folder.
This will need to be kept in mind when the final, user, display is being designed.