Working with Taxonomies

The Taxonomies collection type supports creating asset collections based on SKOS (the Simple Knowledge Organization System), the W3C standard ontology designed for representing taxonomies, thesauruses, and subject heading schemes.

EDG taxonomies are SKOS-based collections (i.e. datasets). When a new taxonomy collection is created, EDG will automatically include the SKOS ontology. SKOS provides a definition of Concept and related classes and their properties e.g., fields like preferred and alternative labels, various notes and relationships. Other EDG collections do not typically or automatically include SKOS, although they may.

Every taxonomy is expected to have at least one Concept Scheme that identifies its “top concepts”. A taxonomy can have multiple concept schemes; however, a better practice can be to use a single concept scheme per individual taxonomy. Since taxonomies can, as can all asset collections, be included into each other, a taxonomy with multiple concept schemes can be assembled through inclusion of several single concept scheme taxonomies.

Use of the pre-defined SKOS fields can be configured locally for a given taxonomy, globally for the entire EDG or for a subset of taxonomies e.g., all taxonomies associated with some business area. You can disable fields for all or a group of taxonomies by taking advantage of the Ontology modeling functionality in EDG - see Working with Ontologies.

Rules and constraints specified by SKOS are also included by default, as are other common constraints for taxonomies e.g., a concept must have a broader parent or be a top concept of some scheme. If desired, they can be disabled.

Ontologies are also used to define custom, non-SKOS properties for taxonomy concepts and to define specializations (sub classes of concepts). If you customize SKOS, make sure that the ontology with your customizations is included in the taxonomies to which the customizations apply. There is a system-wide setting your EDG administrator can use to ensure that the customized ontology is included in every new taxonomy. If customization only applies to a subset of taxonomies, creator of a taxonomy collection can use the Settings, Includes dialog to include the customized ontology.

Taxonomy Editor

For taxonomies, the default editor layout is the Taxonomy Concepts Panel tree view and the details Form Panel. Just like the other collection editors, the UI for this editor can be customized and arranged and comes with many panels and layouts.

Taxonomy Concepts Panel

This panel displays taxonomy concepts organized into concept schemes. It also lets you create new concepts and schemes.

A concept scheme provides an additional organizing context for a collection of concepts in a taxonomy. A concept is said to belong to a concept scheme if it is a child (directly or indirectly) of a top concept. Once a scheme is created, top concepts are added to it. A concept must belong to at least one concept scheme in order to be displayed in the Taxonomy panel, but it can also belong to more than one, if needs be.

You can create concept schemes and concepts using icons positioned in the header of the panel.

**TopBraid EDG Creating Concept Schemes and Concepts**

Taxonomy Concept panel has a quick search field. It lets you quickly look up concepts of interest. Lookup will only search for concepts presented in this panel i.e., those that are connected to concept schemes. The icon to the right of the Quick search field will switch from autocomplete lookup based on the preferred label to the full text search across all string properties.

**TopBraid EDG Switch to Full Text Search Option**

Note

When Quick search is in full text mode, the look up will be routed through the Lucene index and will be subject to its behavior …. for more information about the Lucene index see EDG Configuration Parameters Admin Page.

Concept Life Cycle Operations

During the life cycle of a taxonomy concept, you may find the following operations useful:

Taxonomy Specific Import Considerations

EDG Taxonomies features include the following special importers:

Importer Details

When using Import > Import RDF File to import data into a collection, EDG performs some transformations. This is done to ensure that imported concepts are visible in the Taxonomy Concepts panel. These modifications are as follows:

Narrower concept relationships will be used to generate inverse broader concept relationships
A Concept scheme will be added if none exists. Concepts without broader parents are made top concepts of the scheme

Note

See the rules in TopBraid/SKOS/skoscleaner.ttl in the EDG workspace for technical details.

When using Import > Import Spreadsheet using Pattern, hierarchical spreadsheet imports will also create concept schemes.

Taxonomy Specific Exports

EDG Taxonomies features include the following special exporters:

Taxonomy Specific Reports

In addition to the general reports, there the following specialized Reports tab capabilities for taxonomies:

Reports > Taxonomy Statistics which displays bar charts for the number of nodes per level and the distribution of the number of children.

SKOS-XL Taxonomies

SKOS-XL (SKOS eXtension for Labels) is a part of the W3C SKOS standard that lets you treat labels as resources in their own right, with their own metadata. This may be useful for adding provenance data or information for text mining tools about how to use specific labels. TopBraid EDG lets you use SKOS-XL to add any metadata you like to alternative and hidden labels. Starting with release 6.3, EDG also lets you add metadata directly to links between a concept and its textual labels as detailed in Enabling Reification of Property Values . This may serve as an alternative to SKOS-XL – an alternative that supports capture of label metadata without the added complexity of managing labels as independent resources.

To activate the SKOS-XL support for a particular taxonomy, select Settings > Includes and check SKOS XL SHACL Shapes to include SKOS-XL. Then, when you edit concepts in that taxonomy, the edit forms will let you add existing label resources as the values of alternative and hidden labels. Once a label’s data has been entered, it will appear like any other relationship property value on the relevant form: as a hypertext link. You will be able create new labels using “Create New” as part of the editing concept information. Or, alternatively, you can create and work with label resources independently from concepts. To do so, switch to the Search panel (or Search layout) and select Label from the asset type navigator.

Note

SKOS-XL SHACL Shapes only provide skosXL:altLabel and skosXL:hiddenLabel relationships so that you can create separate label resources for them.
A concept still needs to have a textual label. This means that even with SKOS-XL, TopBraid EDG will continue to use skos:prefLabel as a direct label of a concept.
EDG uses resource’s textual label (either skos:prefLabel or rdfs:label) as a display name consistently across all the UI. Further, TopBraid EDG creates text indexes of concepts (and other resources) to facilitate auto-complete and search. The indexing process uses resource’s label.

SKOS-XL defines only one property for the Label class – literal form. As previously mentioned, EDG uses either skos:prefLabel or rdfs:label as resource names. There is a special “hard coded exception” from this rule for the SKOS-XL Label resources. Even-though the create dialog for them says “label”, the value entered as a label is stored in the skosXL:literalForm property. EDG will understand that for Label resources this property is used as their name. To associate a new property with a SKOS-XL label use the same Ontology customization capabilities as you would use to create new properties for concepts.

Transform SKOS-XL

On the Transform tab of Taxonomies you will find an option to convert SKOS-XL labels to reified values. This feature will convert any instances of skosxl:Label to values of their corresponding direct SKOS properties:

skosxl:prefLabel is converted to skos:prefLabel
skosxl:altLabel is converted to skos:altLabel
skosxl:hiddenLabel is converted to skos:hiddenLabel

If the skosxl:Label has other properties than skosxl:literalForm and rdf:type then these values will be converted into reified statements. For example, if your skosxl:Label instances have values for ex:isAbbreviation and skosxl:prefLabel was used to point to the label, then there will be a reified triple attached to the skos:prefLabel statement to store these additional values. The ontology should define suitable node shapes that define the properties such as ex:isAbbreviation for display and editing purposes, and attach them to the property shapes of properties such as skos:prefLabel using dash:reifiableBy

Optionally, the original URIs of the skosxl:Label instances will be stored as reified triples and the property dash:uri which can then be used to restore the original skosxl:Label instances as part of an exporter.