We need to add a `fragmentarium_id` field to our `Source` model

[jacobdgm]

Working on #1259, the CSV file Debra provided has a Frag_id column. In our BaseChant model, we have a commented-out fragmentarium_id field. Looking at the PR where we established the BaseChant model, it seems this field was already commented out when we switched from separate Chant and Sequence models to BaseChant.

Evidently, we need to reintroduce this field.

It would also be worth researching why this field definition was commented out in the first place - did it show up in an interface in OldCantus but was never imported? Did we make a conscious decision to remove this field?

[annamorphism]

This field is comparatively new--I think it was created on OldCantus after a certain amount of migration work had already happened--so maybe there were some unresolved questions about its implementation. It should, like siglum, be coming from information on the source; unlike siglum, I don't think it ever displayed in a chant interface on OldCantus (but maybe it was supposed to?).

[ahankinson]

Note that the _id suffix is automatically appended to foreign key relationships, so you might want to choose a different name.

[jacobdgm]

this is a good thing to keep in mind - thanks.

We already have Chant.cantus_id and Chant.melody_id - since I don't expect we'll ever have a Cantus model or a Melody model, I imagine we don't need to be overly worried about the names of these fields. So long as we're confident we won't ever have a Fragmentarium model, do you think we're fine to use Chant.fragmentarium_id (or is this more of a communicating-to-future-developers thing, who will see *_id and think "foreign key")?

[ahankinson]

It was more to flag it for you so you could verify that this would work as expected, and there were no restrictions to this as a name.

[jacobdgm]

It should, like siglum, be coming from information on the source...

To confirm - does this mean that this field should go on our model for Sources rather than on our model for Chants?

In the .csv Debra gave us, there was a siglum column with the same value in all cells, and a Frag_id column, also with the same value in all cells. If we add a fragmentarium_id field to our Sources, I guess that whichever developer is importing the CSV will have to manually specify the siglum and Fragmentarium ID when creating the source, and then ignore these two columns when creating all the chants.

[ahankinson]

I don't really know what you're trying to do, but is there a 1:1 mapping between a fragmentarium ID and a Cantus Source?

Fragments are just that: partial sources. It can be that a source has had some pages ripped out of it and they pop up in another library, and are given their own shelfmark. It's only later that someone says "hold on, don't these two things go together"?

How does Cantus deal with fragments? As their own source, or as a part of a whole?

[jacobdgm]

I don't really know what you're trying to do, but is there a 1:1 mapping between a fragmentarium ID and a Cantus Source?

How does Cantus deal with fragments? As their own source, or as a part of a whole?

@annamorphism?

[annamorphism]

Well, not every source is a fragment, and not every fragment has a fragmentarium ID, so it's not 1:1; but every source that IS on Fragmentarium should have a unique "Fragmentarium ID". Currently (with the exception of Gottschalk, which is an older inventory) each fragment is put up as an individual source, so we have source/701386 = q4re on Fragmentarium, and source/701224 = 1en8 , even though they are part of the same book originally.

[ahankinson]

Exceptions generally also set the limits of your data model. If there is at least one source in cantus that requires more than one Fragmentarium ID, then you will probably also need to account for that possibility in all sources. (A one-to-many relationship, rather than a simple string.)

[annamorphism]

Good point. I do think the sources are intended to map uniquely onto a single Fragmentarium ID; a composite source of several fragments would have a new ID.
So in this case (which is working backward from the more usual fragment inventory) "GOTTSCHALK"=source/123609 = Fragmentarium 75ud, while "St. Louis, Public Library (Rare Books), Grolier 44" which is one of its folios = Fragmentarium lcqf = source/SomeNewNumber.

I really don't think once would need multiple values in this field. I suppose conceivably the same physical object could be uploaded to Fragmentarium several times and thus have several digital objects associated with it; supposing one wished to inventory each of those, they would then have to have unique sources for each ID.