File Picking: "exclusively in" operator

[urapadmin]

• The first, date 09.VII is a0036147-f453-4b8f-a81c-cfcfcefd5fb9: It is also connected to SA-004
  • the second, date 09.VII is a109412e-8a98-43da-8121-9e1c477f9cd3: also connected to SA.
  • the ones that are just empty images are indeed not connected to any image record, so that's okay, too.

Ergo: File Picking did what it was supposed to do and we learned again, that things are more complicated than they seem. I will think about this again conceptually, but the ticket itself can be closed, I think.

Originally posted by @urapadmin in https://github.com/urapadmin/kiosk/issues/969#issuecomment-792976261

[urapadmin]

The file picking rules here were:

The result is that the two images mentioned above are set to "dummy" because they ALSO are part of context SA. But since they also appear in other contexts, it looks strange that they are shown as dummies there. What one really would have wanted here is something like "exclusively in".

• But what about some odd constellation where a file is in two contexts: FA-001 and SA. And both contexts are set explicitly to "dummy"? Then it is not any longer about "exclusively in" because the file appears in more than one context.
• Are there even weirder results in combination with other rules like "record type"?

[urapadmin]

let's think about "exclusively in" in the wiki: https://www.meritaten.net/urapdev/doku.php?id=manuals:developer_manual:file_picking_exclusively_in#kiosk_does_not_understand_the_semantic_implications_of_cc

[urapadmin]

@test kiosk 0.11

The "XIN" operator is implemented for the context rule. It is explained here: https://www.meritaten.net/urapdev/doku.php?id=manuals:developer_manual:file_picking#operators

Given how tricky the implementation turned out this is rather experimental. While the consequences seem to be clear enough for data structured the Uronarti way I am not so sure how this behaves e.g. with USTP. They have some strange concepts (like collected material without a unique identifier). So this needs testing in several different data structures.

I have only tested with top level identifiers like "CC" (not included in a higher context). What about using a locus or a locus-tag as the identifier here? XIN "Wheeler Room 1" would only apply for images that are exclusively associated with Wheeler Room 1 (but not with any other locus tag).

What happens when one uses alternative identifiers? Currently, I think we only have them for collected material.

This is all a bit mind-twisting!

[urapadmin]

@test kiosk 0.11 for developer

• [ ] Write a few more module tests with this

[lbestock]

The "Wheeler Room 1" issue is an interesting one. From a data point of view that would look like a problem - an "exclusively in Wheeler Room 1" pick cannot return anything at all from our excavations, since by definition the tag is applied to loci of ours. Wheeler Room 1 also exists as a feature to contain Wheeler's finds, and is tagged Wheeler Room 1, too, and so a context pick "exclusively in" Wheeler Room 1 would return Wheeler's own finds. And nothing of ours. I think. Hm but now I am thinking more in analysis mindset and less in file picking mindset, so switch gears. If I were trying to make all legacy images dummies (which I would not do - those are some of the most valuable to have in the trench) I would pick a rule "context" "Wheeler Room 1" "dummy". If I pick "=" then I dummify not only the legacy data but also all my own loci that are grouped under the tag Wheeler Room 1. So I want rather to use "exclusively in", and that would do it, no?

How is it going to work that Wheeler Room 1 is both a context in its own right (feature, for Wheeler's stuff) AND a locus tag that is applied both to that feature and to the loci we excavate within what was Wheeler's Room 1? I need to look at the database - did I actually number the feature something so insane as Wheeler Room 1, not WR1? If not, the name isn't really the same, and only the locus tag would be held in common, and a file picking rule for context "Wheeler Room 1" should behave as outlined above.

Important not to get too stuck in Uronarti, but the issue might get a workout sooner rather than later, where we rather want to have than dummify Wheeler images but don't want to transfer all the others. Because Christian raised the student data entry issue again. And particularly since we're talking online and URAP, regular transfer of a ton of images is better avoided.

[luizaogs]

So I admit to having avoided this ticket like the plague since May because my brain hurts every time I read it, but I don't have anything left to test currently so ... what are we actually doing here? Is testing this for USTP the goal?

[urapadmin]

@lbestock , @luizaogs: Honestly, before you torture yourself testing such mind-twisting exotics (I really doubt anybody will ever use this), what about rather attending to some of the discussion topics? They are all open and I can't see them progressing towards an end at all. And does somebody know a better word for discussion? For discussion in the humanities is really just discourse, I think. (Somebody is in a bad mood, don't pay too much attention).

[urapadmin]

A pictogram for #1056 e.g. would lighten that mood of mine, I am sure :o)

[luizaogs]

(For your amusement, not because it's going to be helpful: I was chairing sessions at a Portuguese-Spanish conference a few weeks ago, and "discussion" in both Portuguese (discussão) and Spanish (discusión) has negative connotations as far as I understand it, but since that's the word I am familiar with from English I floundered and used a million different synonyms, none of which worked properly. Fun times.)

[urapadmin]

I don't really know what this is about any more, so I postpone it...