Skip to content
This repository has been archived by the owner on Jan 25, 2018. It is now read-only.

Does dc_language need to be single valued? #67

Open
sgbalogh opened this issue Aug 18, 2015 · 9 comments
Open

Does dc_language need to be single valued? #67

sgbalogh opened this issue Aug 18, 2015 · 9 comments

Comments

@sgbalogh
Copy link

Just curious what the rationale for making dc_language a single instead of multivalued field is. Was thinking about this a little while accessioning some datasets that contain both English and Chinese data, and noticed that I couldn't list both languages in this schema. Not a big deal, but I am interested to hear thoughts on it.

@kimdurante
Copy link
Contributor

No, I don't think this needs to be a single value. Good catch!
@drh-stanford do you recall having to limit this to one language for any reason?

@drh-stanford
Copy link

Perhaps we were thinking about the metadata language? In our deployment, we're not using language now as everything we're indexing is in English -- we removed the language facet a while ago.

@andrewbattista
Copy link
Contributor

I would say that almost everything we are indexing is in English as well, but we've come across a set of files from the China Data Center where column headers in the attribute table are in Chinese. Similarly, we're also adding some files from the Cuidad de Buenos Aires in which both the data in the attribute table and the documentation for the data is in Spanish. Even though this is an anomaly, I think it might be wise to make language a multivalued field. Other thoughts?

@mejackreed
Copy link
Member

@kimdurante
Copy link
Contributor

Sounds ok to me.
It might make sense to eventually maintain a mapping file in cases when 3
letter code values are supplied in case they are used as facets.

On Tue, Aug 18, 2015 at 2:22 PM, Jack Reed [email protected] wrote:

[image: 👍] for multivalued...
http://dublincore.org/documents/usageguide/elements.shtml#language


Reply to this email directly or view it on GitHub
#67 (comment)
.

@drh-stanford
Copy link

drh-stanford commented Aug 18, 2015 via email

@andrewbattista
Copy link
Contributor

Sounds good! Thanks for the help, all!

@mejackreed
Copy link
Member

So that can be the change in your local app, but maybe we should look at something more global to geoblacklight-schema.

I'll work on putting a proposal together for a v1 schema that starts to handle these problems.

@sgbalogh
Copy link
Author

Great, thank you!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants