Developers' FAQ

Why are there three different language settings?

For some thesauri, it makes sense to distinguish primary and secondary langguages - e.g. if preferred labels should always be in English while other languages are allowed for alternative labels. Similarly, the selection of label languages does not necessarily apply to notes.

Thus iQvoc's instance configuration distinguishes the following settings:

• selectable languages for preferred labels (languages.pref_labeling)
• selectable languages for alternative labels (languages.further_labelings.Labeling::SKOS::AltLabel by default)
• selectable languages for notes (languages.notes)

Note that the selection of primary (i.e. pref. label) languages determines the available interface languages and is used for routing in the locale part of the URI. Unlocalized URIs (e.g. /search) are redirected to the first entry's language (e.g. /en/search).

How does instance configuration work?

[TODO: extract to separate page]

The instance configuration UI is generated from Iqvoc.config, which provides a list of key-value pairs. Supported values types are booleans, strings and numbers as well as lists of such primitives. In the UI, lists are represented as CSV-style strings.

Settings are created programmatically via the register_setting[s] method(s). Each setting requires a default value to be set, which determines the respective type during (de)serialization.

How to extend the concept user interface? (in progress)

[TODO: extract to separate page]

In case you use iQvoc as a framework you will come to the point, where you extend iQvoc with your own model classes. That will lead you to add new user interface elements to the default show view of your concept. This text will guide you through the basic principles of extending the user interface.

Let's start with an example. Let's say you have some event data you want to manage with iQvoc. Each event has a beginning and an ending. If you want to build that with iQvoc, you create a Concept::Event class which inherits from Concept::SKOS::Base. In addition, a TemporalEntity class might be used to keep track of the respective time interval. You maybe end up with something like this:

class Concept::Event < Concept::SKOS::Base
  accepts_nested_attributes_for :temporal_entities
end

class TemporalEntity < ActiveRecord::Base
  belongs_to :event, :class_name => 'Concept::Event'

  def self.partial_name(obj)
    'partials/temporal_entity/base'
  end
end

class CreateTemporalEntities < ActiveRecord::Migration
  def up
    create_table :temporal_entities do |t|
      t.date :beginning
      t.date :ending
      t.references :event
      t.string :type
    end
  end

  def down
    drop_table :temporal_entities
  end
end

The TemporalEntity class has two attributes, beginning and ending, for saving the time interval. The TemporalEntity model has a belongs_to relationship with Concept::Event. In iQvoc every model knows its show partial by convention; it is stored as a simple path string in the partial_name class method. With Concept::Event we inherit that method, but for TemporalEntity we have to declare it. The root of the paths is the partials folder, which is located in the views folder. Last but not least we have to create our partial. At this point we have setup our basic structure, what we want to do now, is to add the time interval to our show concept view.

Before we start with the necessary steps, let's have deeper look at how partials will be rendered.

Next up

• explain process of rendering partials see chat log
• explain additional_association_class_names