Languages and regions – TBX and SKOS – API Keys
A couple of enhancements have just been deployed. We’ve worked a lot on all
things language management – pretty sophisticated topics this time. On the
authentication side we now support API keys, and – as always – a set of
miscellaneous fixes and improvements.
Read below more details on these changesRegards – your Coreon Team
Languages #1: Regions
Yes, we also were now faced with the challenge to provide proper support to manage languages as well as regions. I.e. to provide a solution to differentiate between say German – German (Germany) – German (Austria) – German (Switzerland) – German (Belgium). This must be an optional approach, since for some repositories, for some languages the region differentiator is not relevant whereas for others it is indispensable.
To capture regions there are – in theory – two approaches:
- Treat a region as a language on its own, thus “de-de”, “de-at”, “de-ch” are like three completely different languages.
- Treat a region like an attribute to a term. We only see the language “de” complemented by an optional property named “Region”. When you then have, say two terms, Abitur and Matura, the first one had the Region property value
Germany, the other one the valueAustria.
Both approaches have pros and cons in data modeling, business process support and even in organization and brand politics. We will discuss this in an upcoming blog post. For now, we decided to follow the first approach to support required business processes. Therefore instead of only seeing the language “German” or “English” in the list of repository languages, the repository can be configured to have languages like “Portuguese (Brazil) – Portuguese (Portugal)”, “Spanish Mexico)”, or “French (Canada) – French (France)” – to name a couple of obvious
candidates.”
While implementing above we took the opportunity to clean the UI a bit to always show the full language name and no longer cryptic language codes (i.e. always “French (France)” instead of “fr-fr”).
Please get in touch with us if you want to revisit the configuration of the language list in your repositories.
Languages #2: TBX vs SKOS
In other words: “Group concept property values by language or not”?
Coreon is a fusion of terminology management with knowledge modeling. When managing terms everything hovers around getting the language aspect under control, whereas in knowledge modeling everything hovers around meanings and semantics. In Coreon’s data model we brought aspects of TBX (concept orientation, open data category set for descriptive richness, term autonomy) together with SKOS / OWL (concept relations).
The key information objects in Coreon are: concepts, terms, properties and concept relations. Terms are member of a concept, properties are member of a term or a concept, and a concept is member of one ore more relations.
But how about TBX’ so-called “language group”? In TBX the language group is a container element that sits as an additional layer between a concept and its terms / properties. The TBX idea was to group all elements ( properties and terms) belonging to one language into a dedicated container. However, in the SKOS / OWL W3C standards as well as in the Coreon data model, terms and properties are not grouped underneath a language, but are attributed with a language. Thus the information is also there, but stored in a different way.
All fine? Well, in some circumstances, users expressed the wish to still have a slightly more TBX-like experience in Coreon. Therefore, we’ve now introduced a capability – without touching our data model – to work a bit more in a TBX style (as an alternative to the familiar Coreon / SKOS style):
- In your repository settings you will now find a switch to change from SKOS style to TBX style. This has only (!) an effect on the rendering of properties and terms. It has no effect on the storage. One user may work in SKOS style, another user in TBX style.
- When working in TBX style: concept properties that can carry a language attribute (typically a property such as Definition) are no longer rendered on top of the concept page, but in the respective language sections, right above the terms.
- When working in Coreon / SKOS style: No changes, concept properties with a language attribute are all rendered on top of the concept page.
- Repository managers can define in the repository model whether a concept property 1) cannot or 2) can or 3) must carry a language attribute. This influences then where it can be added when editing a concept
A little note / outlook: In Coreon’s data model / storage we explicitly decided to not enforce the TBX grouping by language – last but not least we wanted to avoid to be so restrictive. Grouping by language is one way to organize all the information about a concept. But not the only way. One could also imagine to group terms by another criterion than language – for instance by “Status” or by “Term type”. Then terms with status ‘approved’ would be rendered on top of the page, unapproved data only further own. Or we could group by Full form terms, then Short form terms, then the acronyms …
Authenticate via API Keys
News for software developers integrating Coreon as a service, as a backbone, into other solutions: Complementary to username / password based credentials access to Coreon, we now also support authentication via an API key. Such a key – a cryptical string – is a comfortable and very easy method to connect two applications. API keys behave like the following:
- A key is bound against a valid repository user. Thus when authenticating via such a key, the granted rights in the repository are identical to the rights of the user.
- A key can have a time range while it is valid (“from date to date”)
- Using API keys is not foreseen to be typed in in a Login dialog box. Their purpose is rather to be used directly within other software applications.
Want to know more? Please contact us – the API keys are documented as
part of the Coreon API specification.
Miscellaneous
And a couple of UI goodies, nice things. Thanks to our users for all the feedback
and suggestions.
- Editing properties of type date/time: Until now maintainers had to type in a syntactically correct date-time string. Now we offer a simple date picker control.
- Adding a mandatory single select picklist value: Default value was not chosen. This has been resolved.
- Applying a filter, effect not immediately visible, refresh was necessary. This has been fixed, the effect of the filter is now immediately visible.
- Stable rendering of nodes in the concept map: When clicking a node in the concept map – depending from the amount of text – then sometimes an additional wrapping occurred. This caused a, say, instable, agitated map rendering. This has been fixed.
- Editing the concept map, dragging and dropping a “parentless” concept, i.e. a root node, onto another node was not supported. This has been fixed.
- Firefox: rendering of concept nodes not aligned vertically. This has been improved.
