Difference between revisions of "Multi-lingual vocabularies"

From Metadata-Registry
Jump to: navigation, search
(New page: == Multi-lingual vocabularies == We intend to support two types of multi-lingual vocabularies: * Single vocabularies with multi-lingual editing support and language-specific filters * Se...)
 
(No difference)

Latest revision as of 15:29, 15 January 2009

Multi-lingual vocabularies

We intend to support two types of multi-lingual vocabularies:

  • Single vocabularies with multi-lingual editing support and language-specific filters
  • Separate vocabularies, linked at the vocabulary level and mapped at the concept level

Note that unless otherwise stated, when we say 'concept' we include schema properties and classes

Single vocabularies

We'll enable this first...

  • All languages would be represented in a single vocabulary
  • A language-specific representation of the vocabulary would be retrieved either through content-negotiation to determine the correct language to serve or by appending the appropriate language code, as defined in rfc4646 to the URI:
 All languages -- http://metadataregistry.org/uri/NSDLEdLvl/1001 
 English-US -- http://metadataregistry.org/uri/NSDLEdLvl/1001/en-US
 German-Swiss -- http://metadataregistry.org/uri/NSDLEdLvl/1001/de-CH
 English-US, with timeslice -- http://metadataregistry.org/uri/NSDLEdLvl/1001/en-US/ts/20080215221818
  • When a user registers with the registry, she will have the opportunity to select a default language to restrict viewing of vocabularies. This will default to no selection, which will display all available languages.
  • If a user selects a default viewing language, all lists, labels, definitions will be displayed in her default language. A selector will be provided to allow her to see the displayed data in the other available languages.
  • When a user is added to a vocabulary as a maintainer, she will have the opportunity to select a default language for editing that vocabulary. She may select other languages while editing, but the UI will always default to her selected language. This will be vocabulary-specific so she may have different defaults for different vocabularies.
  • We'll provide an interface that will show the user a matrix of all of the concepts in all of the languages in order to provide a quick check of missing properties in any language.

Separate vocabularies

  • Each vocabulary would be language-specific.
  • After the first vocabulary had been entered, subsequent vocabularies would be linked to it when they are created
  • The user interface would be similar to the current UI, but each concept in a linked vocabulary would provide a selector to choose a related concept in the linked vocabulary (optional)
  • If a related concept was chosen by the user, a mapping statement would be created in each vocabulary to link the concepts together. We may use SKOS mappings for this or create registry-specific mapping subproperties of them
  • Each vocabulary and its related concepts would have unique URIs

The downside of this approach (to us at least) is the essentially stand-alone nature of the vocabularies. It makes management and maintenance much more difficult and presents challenges keeping the vocabularies in sync. The upside is that maintenance of each language can proceed independently.

We're not recommending this approach for most vocabularies.