search

arch-kiosk / arch-kiosk-office

💼 central place for collaboration
GNU Affero General Public License v3.0
1 stars 0 forks source link

consolidate ceramic preprocessing entries of equal categories #1809

Closed urapadmin closed 2 years ago

urapadmin commented 2 years ago

after the import we will have presumably several records with the same category_1 and category_2 per context from different seasons. But that is something we were also talking about in the meeting: Instead of updating records, users should just keep adding records even if there is already one for the same category combination.

Here is the solution for both: Kiosk will consolidate them and do the math during synchronization. That takes care of both import, legacy inputs and future inputs. The only downside of doing it in Kiosk is that while inputting the records in FileMaker the records will stay separate. So one would have two or more records of the same category combination. They will not be added together in FileMaker. But after synchronization and a fresh download they will be consolidated and the result will show after the next download in FileMaker. I think that's okay.

urapadmin commented 2 years ago

I guess I should make this a housekeeping module so it might also be time for #1064

urapadmin commented 2 years ago

Before I do that, consider: @Tfranconi, @lbestock

Consolidating sherd records of the same category has implications: We lose the date and the recorder of the distinct records.

An example: 344 - Coarseware - rims - 2 from 2014 and 344 - Coarseware - rims - 4 from 2015 would be consolidated to ---------------------------------------- 344 - Coarseware - rims - 6 from 2015 (using the latest modification date) or 2022 (using the date of the consolidation).

It would also not be possible to see anymore if one has already added the rims from, say, 20221 to the rims from 2016.
Do we really want that?

For the records created by the import the date is currently always the current date and the recorder always the same User. But the date could somehow be faked into with the date of the imported file. That would make it possible to still see in which season the records were created.

urapadmin commented 2 years ago

@lbestock: We should also ask PASU if it is the same for them

lbestock commented 2 years ago

A couple of thoughts: First is about workflow. There must be some means of knowing if a bag has been counted that is appended to the bag itself, either marking it or physically mixing it with the previously collected stuff, so I would be surprised if the scenario of uncertainty if one had counted things comes up. But @Tfranconi can answer that better as it's their workflow (and PASU - let's ask).

Second though is that really the date of collection is not important enough to trump getting rid of a confusion. The sherds are all considered together for the locus, even if dug across seasons. Other parts of the record indicate the multiple seasons in which the locus was excavated (opening and closing dates; narratives). I never thought about it before but this is really the difference between the Uronarti way of numbering every bag uniquely and the USTP/PASU way of only using locus numbers. The Uronarti way makes better sense for tracking movement of finds from field to lab, but makes it harder to see the total data from a locus. The other way makes registration harder but analysis easier. I was about to say that digital makes the analysis part easier and thus tips recording in favor of the "every bag numbered uniquely" way in terms of best practice for a new project. But I am not totally sure that's the case because we never dump all our bags together and so we never SEE them all at once with our eyes, even if we can put them together digitally.

Third is about when one wants things totaled and the difference between recording and analysis. If you're going to give a total ceramics report, or any other ceramics-related queries, then the totaling might be done there and not in FM if indeed there is some reason for wanting to hold onto the multiple dates of counting, right? But I still don't see much downside to totaling in FM and do see upsides.

urapadmin commented 2 years ago
Tfranconi commented 2 years ago

OK, I try to address everything here in one go:

Consolidating sherd records of the same category has implications: We lose the date and the recorder of the distinct records. An example:

344 https://github.com/arch-kiosk/arch-kiosk-office/issues/344 -

Coarseware - rims - 2 from 2014 and

344 https://github.com/arch-kiosk/arch-kiosk-office/issues/344 -

Coarseware - rims - 4 from 2015 would be consolidated to

344 https://github.com/arch-kiosk/arch-kiosk-office/issues/344 -

Coarseware - rims - 6 from 2015 (using the latest modification date) or 2022 (using the date of the import). \

It would also not be possible to see anymore if one has already added the rims from, say, 20221 to the rims from 2016. \ Do we really want that?

For the records created by the import the date is currently always the current date and the recorder always the same User. But the date could somehow be faked into with the date of the imported file. That would make it possible to still see in which season the records were created.

This is a bit of a problem for us because almost everything we collect is stored by trench and year. So it is therefore important that I be able to know when looking at something that it was from trench 5 in 2015, or trench 4 in 2016, etc. I still have the paper records for these past years, so can obviously chase it up there and this is not the end of the world, but if there is a way to make it easily found in the database as well, that would be ideal. The user is not so important, as I am the one who has entered almost all of this material anyway.

A couple of thoughts: First is about workflow. There must be some means of knowing if a bag has been counted that is appended to the bag itself, either marking it or physically mixing it with the previously collected stuff, so I would be surprised if the scenario of uncertainty if one had counted things comes up. But @Tfranconi https://github.com/Tfranconi can answer that better as it's their workflow (and PASU - let's ask).

We do this by the crate that it is in. Ceramics come into the lab and go in a "to be washed" crate organized by each trench. They then go in a "washed, needs to be counted" crate by trench, and then finally a "Washed, counted, trench X year XXXX" crate that is then stored.

Second though is that really the date of collection is not important enough to trump getting rid of a confusion. The sherds are all considered together for the locus, even if dug across seasons. Other parts of the record indicate the multiple seasons in which the locus was excavated (opening and closing dates; narratives). I never thought about it before but this is really the difference between the Uronarti way of numbering every bag uniquely and the USTP/PASU way of only using locus numbers. The Uronarti way makes better sense for tracking movement of finds from field to lab, but makes it harder to see the total data from a locus. The other way makes registration harder but analysis easier. I was about to say that digital makes the analysis part easier and thus tips recording in favor of the "every bag numbered uniquely" way in terms of best practice for a new project. But I am not totally sure that's the case because we never dump all our bags together and so we never SEE them all at once with our eyes, even if we can put them together digitally.

As I answered elsewhere, since we store by year of collection, it matters here. I take all of your points, but can't easily change it now. I'm not entirely clear here if it is possible in any case to enter the data and maintain the year collected date, so this would maybe be an easier conversation for me in person. Sorry, I've also had a long weekend and may not be thinking wholly straight.

Third is about when one wants things totaled and the difference between recording and analysis. If you're going to give a total ceramics report, or any other ceramics-related queries, then the totaling might be done there and not in FM if indeed there is some reason for wanting to hold onto the multiple dates of counting, right? But I still don't see much downside to totaling in FM and do see upsides.

I see value here. Leave raw data in the collected material page but then summarize in report? Is that possible? What would that approach otherwise obscure along the way?

Sorry for the slow and now bulky response, but I hope I haven't missed anything.

best, Tyler

Tyler Franconi Visiting Assistant Professor of Archaeology Joukowsky Institute for Archaeology & the Ancient World Brown University Box 1837, 60 George Street, Providence, RI 02912, USA @.***

On Mon, Oct 10, 2022 at 8:25 PM kioskadmin @.***> wrote:

— Reply to this email directly, view it on GitHub https://github.com/arch-kiosk/arch-kiosk-office/issues/1809#issuecomment-1273938895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQHL5IJGIUROP3OUBM45FKLWCSXXLANCNFSM6AAAAAARAPL7IE . You are receiving this because you were mentioned.Message ID: @.***>

Tfranconi commented 2 years ago

This one I don't understand. Is this something we did wrong when entering data, or something that kiosk did wrong along the way?

Tyler Franconi Visiting Assistant Professor of Archaeology Joukowsky Institute for Archaeology & the Ancient World Brown University Box 1837, 60 George Street, Providence, RI 02912, USA @.***

On Mon, Oct 10, 2022 at 8:25 PM kioskadmin @.***> wrote:

— Reply to this email directly, view it on GitHub https://github.com/arch-kiosk/arch-kiosk-office/issues/1809#issuecomment-1273938895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQHL5IJGIUROP3OUBM45FKLWCSXXLANCNFSM6AAAAAARAPL7IE . You are receiving this because you were mentioned.Message ID: @.***>

urapadmin commented 2 years ago

I think algamating the ceramic records is off the table for the time being. I close this in favor of a consolidated view in filemaker, that shows how many Coarseware/Rims exist in a context while the records themselves stay separate. That way we can both track down where a ceramics entry stems from (year, recorder) and nonetheless see the numbers per trench at a glance: #1825.

In the import I must create a creation date that dates to the year of the workbook from which it originates.