Proposal of Institution attributes reorganisation

[fjorba]

In the 7.x branch of Muscat, there are several Institution attributes (Rails attributes or db columns) that seem unused, and some of them could find a better usage. The current schema is:

muscat/db/schema.rb

Line 149 in 951dd12

create_table "institutions", id: :integer, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8", force: :cascade do |t|

 create_table "institutions", force: :cascade do |t|
    t.string "siglum", limit: 32
    t.string "name"
    t.string "address"
    t.string "url"
    t.string "phone"
    t.string "email"
    t.integer "wf_audit", default: 0
    t.integer "wf_stage", default: 0
    t.integer "wf_owner", default: 0
    t.datetime "created_at"
    t.datetime "updated_at"
    t.string "place"
    t.text "marc_source"
    t.text "comments"
    t.text "alternates"
    t.text "notes"
    t.integer "lock_version", default: 0, null: false
    t.index ["siglum"], name: "index_institutions_on_siglum"
    t.index ["wf_stage"], name: "index_institutions_on_wf_stage"
  end

The following table tries to match them with the Marc21 standard and the current Muscat usage.

https://www.loc.gov/marc/authority/ad110.html

Subfield	Marc21 name	attribute	marc_institution.rb	Institutions column
001	Control Number	id	=	RISM ID
110 $a	Corporate name	name	get_name_and_place	Name and location
110 $b	Subordinate unit (R)	-	-	-
110 $c	Location of meeting	place	get_name_and_place	Place
110 $g	Miscellaneous information	siglum	get_siglum	Siglum
371 $a	Address	address	get_address_and_url	-
371 $b	City	-	-
371 $c	Intermediate jurisdiction	-	-
371 $d	Country	-	-
371 $e	Postal code	-	-
371 $m	Electronic mail address	email	(not filled in)	-
371 $u	Uniform Resource Identifier	url	get_address_and_url	-
371 $z	Public note	-	-
667 $a	Internal note	-	-
680 $a	General note	-	-
-	-	phone	(not filled in)	-
-	-	comments	(not filled in)	-
-	-	alternates	(not filled in)	-
-	-	notes	(not filled in)	-

So, at this moment, the attributes (columns) not filled in are:

• email
• phone
• comments
• alternates
• names

Those filled in but apparently unused are:

• address
• url

At the same time, I miss:

• name_d (matching full_name_d in Personal names, or "people")
• subordinate_unit (so it can be optionally shown in Muscat institution columns)
• subordinate_unit_d (ibid)

So, my proposal is, following the order of the columns definition:

• address: rename to name_d
• url: rename to subordinate_unit
• phone: rename to subordinate_unit_d
• email: remove
• comments: remove
• alternates: remove
• notes: remove

I'm unsure if implementing a repetable $b as attribute is worthwhile, as there are alternatives, as joining them with a dot (instead of: $a Institution. $b Subordinate. $b Minor use: $a Institution. $b Subordinate. Minor)

In RISM database, there are only a few subordinate units:

110 1  $a Fondazione Maggio Musicale Fiorentino $b Archivio musicale del Maggio Musicale Fiorentino $b Archivio Storico del Maggio Musicale Fiorentino. Programmi di sala $c Firenze $g I-Fammf
110 1  $a Archivio storico diocesano di Livorno $b Archivio del Capitolo della Cattedrale di Livorno $c Livorno $g I-LIasd
110 1  $a  "Śpiewak" $b miesięcznik śpiewaczy $c Poznań
110 1  $a Gewandhausorchester  $b Kammermusikvereinigung $c Leipzig
110 1  $a Universidad Carlos III de Madrid $b Instituto de Historiografía Julio Caro Baroja $c Madrid

However, in any university, for example, there are hundreds, and if they are not show in the institution list, it is impossible to know which to select, for example:

On the other hand, from my external point of view, I'd say that the Place maybe should be taken from 371 $b instead of 110 $c; however that is a minor point that should be addressed somewhere else.

@xhero, Do you think this is reasonable? Would you accept some PR to implement this?

Thanks

[Docudoctor]

Hi,
I am referring to "I'd say that the Place maybe should be taken from 371 $b instead of 110 $c"
All (sub)fields of 110 build an unit as an authority. Only a (larger) minority of institutions provide adresses.
I hope, my comment is usefull for your further thoughts.
Best,
Guido

[fjorba]

Yes, @Docudoctor, your observation is specially interesting when addressing how those fields would be indexed, and so, it is clear that $a and $b (if available) should be indexed as a unit (single field). However, according to https://www.loc.gov/marc/authority/ad110.html this $c refers to Location of meeting, and both examples in that page are, effectively, places where conference meetings were held, not the place (city) of an institution, like the typical RISM usage.

[xhero]

I would prefer not to rename fields if possible, because this comes with a quantity of subtle breakage that is quite difficult debug. If it is about the naming, we can create an alias in the model. For example, why do you want to rename address to name?
On the other hand there is no problem to add fields (or clean the unused ones). @ahankinson Do you too have any data you would like to have here? @jenniferward ?
Lastly I'm not sure we need to add the _d fields anymore, since all the indexing is done in Solr and not by sql anymore, do you have a special use for those?

[fjorba]

If renaming fields causes problems, I didn't know, thanks for letting me know. I'll remake the proposal removing and adding fields (attributes). My proposal to rename address to name_d (not name) was to avoid a delete a field to add another one, but I see that it a bad solution.

Regarding the _d fields, if Solr takes care of the needed functionality (including sorting, #978), I'll remove them as well. I haven't tested 8.x release yet.

Finally, there is the issue of indexing $a and $b (and maybe $c, but this would be a cataloguing discussion) together in Solr. Do you have another case in Muscat where more than one Marc subfield is indexed as a single Solr field?

[jenniferward]

I have no additions from the Series C project side, but I will admit that 110 $c can be seen as a RISM local practice. As an aside, we (the Series C group) have noticed the Institutions are particularly well-stocked with fields for locations: 043 (Country code), the 371 (with country and cities), and 551 (Places), this 110$c, and 368, and 370.

I note that LC uses 370 for what—I think—@fjorba would expect RISM's 110$c info to be? This is LC's authority record for itself: https://lccn.loc.gov/n78089035

[fjorba]

Taking into account that renaming columns is problematic and that the _d fields are no longer needed, my second proposal is:

1. Remove those columns (attributes):

• address
• url
• phone
• email
• comments
• alternates
• notes

2. Create a new column (attribute):

• subordinate_unit

Adapt marc_institution.rb methods accordingly.

This subordinate_unit should optionally be shown in the institution list, maybe as a parameter, replacing one of the current columns.

I'm not proposing anything regarding the Solr indexing issue here, as I don't have a clear idea about how to implement it. However, if this reorganisations is accepted, I can work on it in order to address the #1196 issue.

Is this ok now?

[Docudoctor]

Dear Ferran,
you talk about MARC fields 371 in institutions, I guess. The fields are in use for publishers, printers and library sigla.
Best,
Guido

[fjorba]

Yes, I was talking about institutions, certainly. I don't know if it should be different in your case but, of course, you know it better.

Thanks.
Ferran

[fjorba]

Maybe a lighter alternative to the display issue could be that the attribute name has both $a and $b (if available), because it would imply less modifications. That would be more acceptable?

I'd like to know which path should I follow that would be accepted and merged upstream. Which alternative would you prefer, @xhero?

[fjorba]

After testing several configurations, my current proposal is:

• Keep current name attribute, but now it is the concatenation of $a and $b (not just $a as before)
• Create a new corporate_name atrribute, just with $a
• Create a new subordinate_unit attribute, just with $b

Those corporate_name and subordinate_unit attributes will be respectively linked to $a and $b in yaml files, like that:

diff --git a/config/marc/tag_config_source.yml b/config/marc/tag_config_source.yml                                                   
index 4d878918..7f6469ec 100644                                                                                                      
--- a/config/marc/tag_config_source.yml                                                                                              
+++ b/config/marc/tag_config_source.yml                                                                                              
@@ -657,9 +657,11 @@                                                                                                                 
     - - a
       - :occurrences: "?"
         :foreign_class: ^0
-        :foreign_field: name                                                                                                        
+        :foreign_field: corporate_name                                                                                              
     - - b
-      - :occurrences: "*"                                                                                                           
+      - :occurrences: "?"                                                                                                           
+        :foreign_class: ^0                                                                                                          
+        :foreign_field: subordinate_unit                                                                                            
     - - c
       - :occurrences: "*"
     - - g

Autocomplete works well because it searches the name attribute, as it should. So, if there are several library services in different institutions, the cataloger should be able to pick up the right one choosing the right one, seeing the whole name, for example:

And the names in the instutions list also appear in full (as they keep the old name attribute):

Comments?

I'll create my PR with the implementation of this proposal.

[fjorba]

Done in #1287

[fjorba]

I'd like to add that my patch works not only for interactive cataloging but also with marc import (housekeeping/import/import_from_marc.rb), first with person and institution authority records, and finally source records.

[fjorba]

Closed by #1335