innoq / iqvoc Goto Github PK

The view lists the concept members of a collection in an unsorted way.

At the moment collections are listed under hierarchical and alphabetical concept lists as well. That's because collections are concepts.

Requirements

• Admins should be able to manage languages in admin backend
• Language: i18n code + fully qualified description (translated depending on the primary language setting)
• Primary language: UI language AND pref label language; no need for a specific UI language
• Secondary language: only selectable in detail views
• i18n fallbacks
• Only allow UI languages based on the prefLabel languages configuration
• Don't display a language switch if there's only one language configured
• Don't display fallback annotation if browsing is done in a non-configured prefLabel language (e.g. nil)

authlogic seems to unmaintained now. It should be possible to replace it by something handcrafted.

Validations have to be specified directly in the class they belong to. E.g. if you want to check that there is only one pref_label per concept this should be done in the Labeling class and not in the Concept or Label.

The problem in which form validation errors from nested invalid objects are shown up when saving the "main" object is still open.

Running the test suite, I get plenty of deprecation warnings like the following:

DEPRECATION WARNING: save(false) is deprecated, please give save(:validate => false) instead. (called from create at iqvoc/app/controllers/user_sessions_controller.rb:11)

DEPRECATION WARNING: Using & to merge relations has been deprecated and will be removed in Rails 3.1. Please use the relation's merge method, instead. (called from iqvoc/app/models/labeling/base.rb:21)

While this not a problem for now, it should be straightforward to fix.

Given two unpublished concepts A and B, with A being a broader relation to B, A should be displayed as broader relation when previewing an unpublished version of B. This is not currently the case.

• create a new concept, assigning two related terms (e.g. "Foo" and "Bar") - then submit
• return to edit mode
• note that only "Bar" is being listed in the respective input field

Concept::Base currently contains a valid_label_language validation which requires the SKOS-XL extension:

This should probably be (re)moved.

It is currently possible to create circular references among collections:

• create collection foo
• create collection bar, link it to foo
• link foo to bar

Such errors should be flagged, either during the edit phase or when doing a consistency check.

(cf. 6bedf4f)

Given a published concept A with a broader relation to a unpublished concept B.

Now: A will appear on the root-level of the hierarchy.

Better: A shouldn't appear :-)

Some Theory:

root_concept = {c | c is Concept && c.broader_relations.count == 0}

This can be done by a

.includes(:broader_relations).where("broader_relations.id IS NULL")

Concept relations should be editable by offering drag & drop support in tree elements.

Things to keep in mind

• Whole hierarchy (concept relations) has to be checked out (within an extra view)
• A popup menu has to be displayed after the "drop" event taking place that offers options like "move" or "copy" (poly hierarchies)
• A root node is needed in order to hide newly created concepts without relations

As an editor, I'm currently able to publish or send objects to review which are locked by other users. That should not be allowed.

Currently the New collection link is visible even if the current user does not have permission to create new collection.

(Clicking that link actually raises a 500 error... )

Now that iQvoc has committed to jQuery UI, it might make sense for custom widgets (currently* EntitySelector and LanguageSelector) to use the jQuery UI widget factory.

* assuming the entity_select branch is accepted, as it includes Autocomplete (Datepicker alone does not depend on the widget factory)

Support for Note::Annotated::Base relations is still missing in RDF output.

This is considered an important change in the architecture.

The core iqvoc app should be turned into a depedency. It should be usable standalone or via vendor core apps.

While branching an object, the following occurs:

ActiveRecord::StatementInvalid (NativeException: java.sql.SQLException: ORA-00942: table or view does not exist
: SELECT "CLASSIFICATIONS".* FROM "CLASSIFICATIONS" WHERE ("CLASSIFICATIONS".owner_id = 59400)):

Looks like a regression. Change notes should be generated automatically on every save.

• create a new concept, assigning two related terms (e.g. "Foo" and "Bar") - then submit
• note that the concept is being created, but no related terms are being listed on the resulting page

This appears to happen because the controller assigns relations before the concept is saved to the database:

Minimal test case (assuming two concepts with origins "tennis" and "golfing" exist):

params = {
  :concept_relations_by_id => {
    :concept_relation_skos_relateds => "tennis,golfing,"
  }
}

c = Concept::Base.new params
c.generate_origin
c.save

puts "BEFORE: %s / %s" % [c.relations.length, c.related_concepts.length] # 0 /0

c.update_attributes params
d = Concept::Base.by_origin(c.origin).first

puts "AFTER: %s / %s" % [d.relations.length, d.related_concepts.length] # 2 / 2

This widget should be fixed or completely removed (I would prefer the second "solution").

The order of fieldsets for the concept template should be customizable in some way.

Using Ruby 1.8.7 it is currently random, because the structures are hashes. Using 1.9.2, the fields are ordered based on the configuration hashes.

It's currently possible to assign an EN label as DE labeling (and vice versa), which can lead to unexpected results:

• in UMT, create EN labels Foo and Bar
• create a concept
• assign Foo as preferred label (which is meant to be DE)
• assign Bar as DE alternative label
• save - note that there is no pref. label being displayed and that Bar is listed under EN alt. labels
• re-enter edit mode - note that there is no pref. label; Foo has become inaccessible within the concept (but the labeling is still present in the database)

Extract SKOSXL relevant stuff into a separate gem.

Broader relations in a mono hierarchy allow only one broader relation per concept. You can see if this is the case by asking the model:
https://github.com/innoq/iqvoc/blob/master/app/models/labeling/skos/pref_label.rb#L21
The widget should be configured with this option and should restrict the selection to one item if the corresponding option is set.

Given: A > B > C and X < Y < B
When I visit B I want to see A and Y As Broader Relations (works). But in the current Version A has the child B again. I would expect X under Y instead. The tree must be shown regarding to the broader relations not to the narrower ones.

Note: Some branches are already switched to "Mono" Hierarchies (the new default). You'll have to use a poly hierarchical thesaurus the reproduce the problem.

Every copy saying "not available" or "not found" should be replaced by a sane "-".

Validations targeting PrefLabels must be moved to their according model (Labeling::SKOS::PrefLabel).

when assigning sub-collections to a collection, the current collection should be filtered from the selection list

The tree structure contains strange misplacements of elements.

As far as I can tell, there's no simple way (i.e. UI button) to delete an existing concept.

While I realize that this might often be undesirable (e.g. due to hierarchical relations), it should at least be possible?

In order to jump to linked concept directly out of a widget, small link icons have to be applied to a widget's tokens.

Lots of items slow down the page loading.

URL should be something like http://innoq.github.com/iqvoc.

Manual: http://pages.github.com/

All associated (unpublished) objects should be published recursively.

It is currently possible to create a concept or collection without assigning a pref label (cf.

Due to recent changes (multilang branch does not use origin as fallback for pref_label anymore) this is problematic - plus the original rationale for this behavior seems forgotten.

Thus at least one pref label should always be required.

Under certain - yet unclear - conditions, creating a new concept results in an existing concept being overwritten. While, unfortunately, I have not been able to create a reproducible test case, I have experienced this on two different machines with two different setups (Ubuntu 10.10 with Ruby 1.8.7 and SQLite vs. Ubuntu 11.04 with Ruby 1.9.2 and MySQL).

It appears that this is due to faulty origin generation (

When editing and saving a collection and leaving the subcollection widget untouched, all child collection get destroyed.

Change notes create annotations with "umt:editor". This is obviously wrong.

The whole design should be questioned:

• Why is the annotation displayed as read only input field (when creating the notes) instead of being rendered as "plain" text?
• Annotation predicates shouldn't be in turtle syntax. It should be done in two fields: namespace prefix and predicate or in one field as complete URL. As long as this isn't fixed, it won't be possible to render annotations in RDF/XML.