SPARQL – DnD in the concept map – Filtering – Export templates
A couple of improvements have just been deployed. This time we’ve worked on
some fixes when dragging and dropping concepts to change relations as well as in
the filtering module. Further, we are publicly launching a beta preview on Export
Templates. And the SPARQL endpoint is now in production.Read below more details on these changes
Regards – your Coreon Team
SPARQL Endpoint
As announced last time, we have now finished this development activity and brought the SPARQL endpoint into production. This means that – upon demand – we can add a SPARQL endpoint to your Coreon repositories. Developers from the Semantic Web Community will appreciate this simplicity to query repositories while not having to learn a foreign API.
With that addition Coreon is now fully compatible with requirements known from the Semantic Web. We export into RDF formats (Turtle, N3, JSON/LD etc.) for offline use and we have a SPARQL endpoint to query the repository even in real-time. To our knowledge we are one of the first – if not even the first – software for multilingual, concept-oriented terminology management that goes so far when it comes to RDF and SPARQL.
… yet another step of our vision to make terminology deployable in way
more different business processes than known years ago …
Dragging ‘n Dropping Concepts: Type of Relations Kept
When dragging and dropping a concept to move to another broader concept then one issue occurred, namely that the type of the newly generated hierarchical relation was always set back to ‘unspecified’.
However, users reported that we should try to keep the type of the hierarchical relation. In other words, when the concept was originally stored with a ‘has-part’ type of hierarchical relation to its broader concept then after the move to its new broader concept then it should again be stored with that type.
This is now resolved in two variants: when dragging and dropping a concept within the Concept Map to another node (see screenshot) as well as – an alternative editing method – when dropping a concept from the clipboard into the broader concepts zone (to use as the new parent).
Filtering: Several Improvements
A few fixes and subtle improvements here:
- Rule applies to a term, but export process writes whole concept: Assume you created a rule to filter for terms such as “preferred only” by evaluating the value of a term property like Usage. In the UI of the browser you were observing the desired behavior. Terms with a status ‘preferred’ passed the filter rule, terms with a different status (say ‘forbidden’) did not pass the filter rule. Fine.
However, when using this filter rule during an export job all terms were exported as part of the concept and not only the expected ones; the rule was not applied. This has been addressed and the export now also writes only these terms that pass the filter. - Operators ‘equals not’, ‘contains not’ have a more tolerant meaning: When creating a rule using the ‘equals not’ operator – say “Status equals-not Approved” – , it only found those concepts that both a) do have the property Status there, and b) but with a different value, say ‘Draft’. Technically this is correct. But us humans, we’d expect that also all concepts that completely lack the property Status pass the rule (thus, mentally the value is also ‘not equal to Approved’) . This wasn’t the behavior up to now.
We’ve changed the meaning of the ‘equals not’ and the ‘contains not’ operators in a way that they fire either when the property is not there at all or (as before) when the property is there and then the value is different resp. doesn’t contain the specified string. - Operators added: is alias / is not alias – checks for the ‘alias’ nature of a concept node
- Operators added: is branch root / is not branch root – preview checks whether the concept has a property ‘Coreon branch root’ set to true or not.
- Operators added: is not below concept, is not above concept: The negation of the ‘below concept’ / ‘above concept’ operators. Allows to filter whether a concept is below / above respectively – and now – not below / above a given concept. These operators help to filter for branches of a repository.
We were also diving into a couple of further enhancements – for instance to make it an option whether to combine more than one filter via AND or OR, as well as when it comes to filtering for relations, such as ‘filter for all concepts that are the target of a has-part hierarchical relation’.
These two however require a slightly larger development sprint, with some more UI changes. Since we will anyhow work this spring on the relations, their types and in this context touching the filter form and logic we had to postpone changes in this area and do it in one coherent development project in a couple of weeks.
Export: Public Preview of Templates
Enhancing the export capabilities is a focus for already many months.
Publishing repositories and various formats most comfortably on a regular basis allows smooth and flexible generation of export files in various formats.
Export Templates allow you to save (and next time re-load) the various parameters you need to set in order to generate right the desired export file with exactly the desired content. Further, such templates also allow to embed and launch xslt and pdf transformations to further transform the export file directly as part of an export job.
What important export settings are kept in such a template (not going into the details … things may still change a bit):
- Name and Visibility – the name of the template so that you can use it when starting the next export job. Its visibility: is the template shared with colleagues or only available to the creator/owner of the template.
- The format – Coreon XML / Spreadsheet (XLSX) / TBX XML / RDF
- What concepts and terms – should the export take one or more filters into account or export all concepts
- What data values – should the export file contain all languages, all properties, all relations or some selected ones only
- Subsequent transformations – after generating the export file, should a transformation be applied to for instance create an HTML table out of it. And then having the HTML table should it transform to a print-ready pdf file?
With these transformations the Coreon Export module becomes very powerful. Yes transformations can even be chained into a pipeline. On the one hand a template could be defined that creates more than one export file within one export job, very comfortable. On the other hand, by supporting XSLT as well as PDF transformations, virtually any format can be generated directly out of Coreon (i.e. without the need to do some after-processing locally based on custom scripts etc.).
This template functionality is now available as a preview / beta – we’d like to gain a bit more experience with real data to make it stable and to finalize the UI. And if you want to test with your own custom transformations / XSLTs please get in touch with us.
