-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a subset of selections for different tables #54
Comments
I think the extra columns would be preferable, as long as the data can be cleaned up that way. |
@jduss4 The question was whether there would be time to clean up the data before the grant ended and the general consensus is probably no. However, if Carrie gave us a list of words and we could automate adding those into a keyword column, we might accomplish the same thing in a more straightforward manner. |
One issue which was brought up in the meeting was the danger of inserting this into tables as if it is a controlled vocabulary. For instance, if someone put "not turquoise" and we added a column to the database that contained "turquoise", it would be incorrect. So if we did insert terms into the database rather than doing canned free text searches (possibly for speed) we would need to make sure that the resulting data download did not contain this new column. For now, it's best to just create these categories in the interface and preform free text searches. If later we decide that this is slowing things down to a large degree, we can look into adding columns to the database to speed up the search. To be clear: there will not be time to actually clean up this data. We're just trying to provide the user with commonly used prompts. |
Alternately, we may just want to provide the user with prompts to do the search themselves |
My current thinking is that if we do the free text search solution, it would be for a very limited cases. This is a subject for discussion, but if time allows us to pursue this added functionality, it might only include turquoise, shell, jet and obsidian. These are all exotic, imported materials of particular interest to scholars. All four of those materials are scattered across various tables. For instance, the word "turquoise" occurs in the ornaments table (in the "Item" field), and the select artifacts table (in "Type" and "Comments" fields), the burials table (1 record described in "Assoc Art" field), and the bone tool table (1 record described in the "Comments" field). And there may in fact be redundancy in these items. For instance the dame items which occur in the select artifacts table are probably also listed in the ornaments table. If we proceed with a few of these free text searches, we may decide not to try to de-duplicate records, but rather leave that for the user to ferret out. |
It sounds like we have a lot of ideas for this, but it's a bit too late to implement for next week. Moving this to v2. Ideally we'll create a new issue with a more succinct "todo" |
For instance: Adding the ability to search for "Turquoise ornaments"
This is not currently possible because there is not a regularized row to find this data in. Current thinking is that we will need to produce "canned searches" to provide this functionality. For instance, under "ornaments" we would give the user the option to limit by "turquoise" "bone" "shell" and clicking that would do a text search (over the type field?).
The other option would be to add extra columns for, example,
material
, that would be filled in withturquoise
,bone
,shell
, and another for, example,shape
that could be filled in with things likebead
andslab
The text was updated successfully, but these errors were encountered: