mapping for new item types

[stakats]

all of the following fields should probably map to "publisher"

label (Soundtrack)
studio (Video Recording)
network (TV Broadcast)
network (Radio Broadcast)
company (Computer Program)

[dstillman]

We can change these, but I should say that, at the moment, there are really only two reasons for reusing a field: 1) to share autocomplete and 2) so that data in a field isn't lost when switching between item types. It probably makes sense to have the latter be the case for these, but not necessarily the former. On the other hand, I could just have autocomplete not share data between the different labels of the same field in different item types, since they're probably usually different enough to not do so.

One other problem is how to handle search conditions--show the multiple labels for the same field individually? By then, along with explicitly not sharing autocomplete, you're adding a whole lot of code just to emulate the existing behavior for distinct fields. It may be easier to just implement them as different fields and add a bit of code to associate them in various ways when appropriate.

The Basecamp post lists various fields (along with these) that should be relabeled, but, while those are all set to the same field in the DB, they're not labeled differently yet, since I don't have a solution to these issues.

As for down the road, there could be advantages and disadvantages both to sharing fields and to having distinct fields...

Thoughts?

[erazlogo]

I think the best solution would be the one that takes less coding, and it sounds from your comment that having distinct fields would take less code. But it would be useful to allow users to search by "publisher" and find records under "label," "network" etc. Also, I think all of the above are marked as "publisher" in library databases so you'd need to write additional code to put the data in appropriate fields for each item type (I think now whatever you get from library catalog is marked as "book" but that should be changed).

Whatever you do, you should also map "university" in thesis and "institution" in report as "publisher".

[dstillman]

OK, I think distinct fields makes the most sense here.

Only custom logic that I can think of would be 1) in search.js to have publisher also search those other fields, 2) in itemPane.js to preserve fields when switching between types, and 3) in translate.js to automatically map publisher to the correct field. Overall, I think this will result in less and cleaner code than the alternative.

Will provide a lookup function to convert from publisher to the respective field for a given item type and to check if a given field is a publisher field for a given item type. Using these in translate.js will keep translators from needing to deal with this.

[dstillman]

Looking again over Elena's list on Basecamp, it seems to me there's a subtle distinction between some of these cases. Here's a list of the fields in question:

Item Type	Base Field	Type-specific Field	Type-specific Label
webpage	publicationTitle	website	"Website Title"
report	number	reportNumber	"Report Number"
bill	number	billNumber	"Bill Number"
bill	volume	codeVolume	"Code Volume"
bill	pages	codePages	"Code Pages"
case	title	caseName	"Case Name"
case	date	dateDecided	"Date Decided"
case	volume	reporterVolume	"Reporter Volume"
case	pages	firstPage	"First Page"
hearing	number	documentNumber	"Document Number"
statute	title	nameOfAct	"Name of Act"
statute	date	dateEnacted	"Date Enacted"
statute	number	publicLawNumber	"Public Law Number"
patent	place	country	"Country"
patent	number	applicationNumber	"Application Number"
email	title	subject	"Subject"
forumPost	publicationTitle	forumTitle	"Forum/Listserve Title"
audioRecording	publisher	label	"Label"
videoRecording	publisher	studio	"Studio"
tvBroadcast	number	episodeNumber	"Episode Number"
tvBroadcast	publisher	network	"Network or Station"
radioBroadcast	number	episodeNumber	"Episode Number"
radioBroadcast	publisher	network	"Network or Station"
podcast	number	podcastNumber	"Podcast Number"
computerProgram	publisher	company	"Company"
blogPost	publicationTitle	blogTitle	"Blog Title"
thesis	publisher	university	"University"

Some make sense to implement as separate fields, as they shouldn't auto-complete from the base type but should show up separately as search conditions: the publisher ones, place=>country, pages=>firstPage, for example. Others, such as the date ones, seem like they could be done simply as custom labels. Auto-complete between those wouldn't be a problem, and I think it'd be fine to just have "Date" as a search condition and not have "Date Decided," "Date Enacted"--even if those are the labels in the metadata pane, I think it'd be moderately clear that you should just use "Date" as the search condition. Same for the title fields. Less clear are the number, volume, pages=>codePages, and publicationTitle ones...

[dstillman]

(In [1154]) Addresses #346, mapping for new item types
Closes #453, Check if any fields will actually be discarded on item type change before giving warning
Refs #530, Add base field conversion to translation level

Added mechanism for linking item type fields via base fields, e.g. publisher => label in audioRecording

New methods:

Item.getFieldsNotInType(itemTypeID, allowBaseConversion)
ItemFields.getLocalizedString(itemTypeID, field)
ItemFields.isBaseField(fieldID)
ItemFields.getFieldIDFromTypeAndBase(itemType, baseField)
ItemFields.getBaseIDFromTypeAndField(itemType, typeField)
ItemFields.getTypeFieldsFromBase(baseField)

Currently only the publisher fields are mapped -- I need more feedback on #346 before I implement the others (specifically on whether or not all these sorts of fields should be done as distinct fields or whether some should just be localized strings (in which case they'll autocomplete but not show up separately as search conditions))

Also added 'university' as distinct publisher field for thesis

Values of equivalent fields are now preserved when switching between item types (e.g. the 'studio' value becomes the 'label' value when switching between videoRecording and audioRecording), and the pop-up is much smarter--it will only prompt you if fields will in fact be lost, and it will list the fields that would be deleted.

Not finished:

• Searching for base fields doesn't yet search the type-specific fields, as Elena requested
• import/export/bib should be updated to use the ItemFields base conversion methods where appropriate -- data coming from the 'publisher' field from translators, for example, should be put into the appropriate type-specific field.

[dstillman]

OK, Elena and I decided that implementing all of these as distinct fields, linked via base fields, would be appropriate, since autocomplete isn't really necessary. Once base field searching across type-specific fields is implemented, as discussed above, we can also just have the type-specific fields not show up in as search conditions, since people should just search in combination with an item type or other conditions. (This should help with #528.) This also applies to the various "type" fields, which should be linked with a base Type field. The only downside is that then autocomplete in the search window would autocomplete between audioRecordingType, videoRecordingType, etc., but 1) that's not too big a deal and 2) down the line we can perhaps add in some logic to check the other search conditions for item type conditions and narrow down the autocomplete scope accordingly.

[dstillman]

(In [1177]) Closes #346, mapping for new item types
Closes #227, Indent nested collections in search drop-down
Addresses #528, Make search condition drop-down menu less unwieldy

• Created new distinct fields for differently labeled fields
• Mapped lots of fields to base fields
• Made base field search conditions search type-specific fields as well
• Removed type-specific fields that are based on base fields not show up in search conditions drop-down
• Added a tooltip when hovering over a condition in the search conditions drop-down that shows the fields it searches (when there's more than one)
• Moved search dialog CSS to separate file

[dstillman]

(In [1202]) Addresses #346, mapping for new item types

Fix for base field not being included (only type-specific fields) when searching by a base field

[dstillman]

(In [1219]) Moved title field to itemData table, which made the following possible:

• All remaining fields in the items table exists in all items and are non-user-editable
• Simplified some data access code (e.g. removed Item.isEditableField())
• 'title' is now a base field used in case (Case Name), statute (nameOfAct) and e-mail (Subject)

Reengineered parts of the data layer for better performance

• Various recent changes, including the 'title' change above and base field mapping in Item.getField(), had a negative effect on performance. This should help. In particular, itemData values are now loaded in in bulk by Items._load() (via Items.get()) rather than on-demand, the sort process in itemTreeView caches values while sorting, and ItemFields.getFieldIDFromTypeAndBase() is faster.

Addresses #346, mapping for new item types