-
Notifications
You must be signed in to change notification settings - Fork 2
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
(!) wasteful multiplicity of type nodes #59
Comments
This probably applies to all museums, does apply to all Constituent name types, and probably to other type nodes as well (eg title types, see #58 item 2) |
I agree—the reification of having both a type and a broadMatch is unnecessary, and should eventually be corrected in the model. If possible, we should fix this in all mappings, however I don't want to break things that are already modeled by changing the review tool midstream, and if ISI isn't going to be able to correct the reification, we should leave it and fix it in a future phase. This does not change the fact that
is a serious problem, and needs to be addressed. |
I have changed the name type nodes to thesauri/name_type/first_name thesauri/name_type/middle_name and thesauri/name_type/last_name |
@bsnikhila did you check it for other types and other museums as well? |
I will do that. |
Consider this:
The node cbm:person-institution/111/appellation/name_type/firstname is useless because it doesn't say anything more than aat:300404651; # first name. But this is according to the mapping: presumably it gives museums the freedom to have their own concept for First Name, not that such freedom is needed or desired.
The problem is that you use a separate node for EVERY instance of a first name. Instead, use a single node eg
cbm:type/name/firstname
The text was updated successfully, but these errors were encountered: