Skip to main content

Categories and Groups

It’s useful to organize individual metadata items into some groups in some cases. This makes the working with the application simpler for the end user while the system still works with the individual items in the background.

The possible metadata grouping ways include categories and groups.

Categories​

Categories are collections of feature types that make working with feature types easier. The feature type grouping in categories is quite loose, one feature type may belong to any number of categories including zero. Furthermore, categories can be arranged in a tree structure. Such organization enables to logically categorize feature types according to various aspects, which results in effective feature type handling.

The category tree does not represent inheritance in any sense, it is really just logical feature types organization. Also, inclusion of feature type in the category is not inherited through feature type hierarchy.

Categories definitions are grouped together in the categoryArray collection.

Example: Definition of categories.

<ber:categoryArray>
  <!-- Root level category -->
  <ber:category id="cat_5010000" name="Water-supply network">
    <ber:description>Water-supply network</ber:description>
    <ber:featureIdArray>
      <ber:item refId="ft_5040000"/>
      <ber:item refId="ft_5010200"/>
      <ber:item refId="ft_5012200"/>
      <ber:item refId="ft_5011200"/>
      <ber:item refId="ft_5012100"/>
      <ber:item refId="ft_5011100"/>
      <ber:item refId="ft_5012300"/>
      <ber:item refId="ft_5020000"/>
      <ber:item refId="ft_5010100"/>
    </ber:featureIdArray>
  </ber:category>
  <!-- Another root level category -->
  <ber:category id="cat_5020000" name="Electrical network">
    <ber:description>Electrical network</ber:description>
    <ber:featureIdArray>
      <ber:item refId="ft_5020000"/>
      <ber:item refId="ft_5090000"/>
    </ber:featureIdArray>
  </ber:category>
  <!-- The electrical network subcategory -->
  <ber:category id="cat_5023000" name="High voltage" parentId="cat_5020000">
    <ber:description>High voltage</ber:description>
    <ber:featureIdArray>
      <ber:item refId="ft_5020000"/>
    </ber:featureIdArray>
  </ber:category>
  <!-- Another electrical network subcategory -->
  <ber:category id="cat_5022000" name="Low voltage" parentId="cat_5020000">
    <ber:description>Low voltage</ber:description>
    <ber:featureIdArray>
      <ber:item refId="ft_5020000"/>
    </ber:featureIdArray>
  </ber:category>
  ...
</ber:categoryArray>

  • category – Single category definition.

  • parentId – References its super category in the category hierarchy. Optional.

  • featureIdArray – Collection of item elements, i.e. feature types contained in this category.

Backdrop Categories​

Categories of backdrops have similar functionality as ordinary categories. The categories again do not represent inheritance in any sense, it is just logical backdrops organization that makes working with backdrops easier. Also, inclusion of a backdrop in the category is not inherited through backdrop hierarchy. Backdrop categories definitions are grouped together in the backdropCategoryArray collection.

Attributes

  • id – Unique identifier of a backdrop category.

  • name – Name of a backdrop category.

  • parentId – References its super category in the backdrop category hierarchy. Optional.

Inner Elements

  • description – Contains a detailed description of the group container.

  • backdropTypeIdArray – Collection of item elements, i.e. backdrop types contained in this category.

Example: Backdrop category structure.

  <ber:backdropCategoryArray>
    <ber:backdropCategory id="cat_vicinity" name="Vicinities">
      <ber:description>Vicinity backdrops</ber:description>
      <ber:backdropTypeIdArray>
        <ber:item refId="bd_04"/>
        <ber:item refId="bd_05"/>
      </ber:backdropTypeIdArray>
    </ber:backdropCategory>
  </ber:backdropCategoryArray>

Groups​

Groups are more general than categories. While categories are limited to feature types only, groups can contain feature types, codelists, associations and reports.

Individual metadata items are assigned to groups by specifying particular group id at the particular metadata item definition directly. There is no explicit definition of groups. List of all groups is dynamically generated by selecting all distinct group references from metadata.

Example: Assigning codelist to two groups.

<ber:codeList dbName="A" id="cl_1" name="Abc">
      <ber:description>XYZ</ber:description>
      <ber:groupsArray>
        <ber:group id="group_1"/>
        <ber:group id="group_2"/>
      </ber:groupsArray>
      <ber:columnArray>
…

Example: Assigning feature type to two groups.

<ber:featureType id="ft_1" name="Abc">
  <ber:groupsArray>
    <ber:group id="group_1"/>
    <ber:group id="group_2"/>
  </ber:groupsArray>
  <ber:container refId="ct_1"/>
  <ber:featureAttributeArray>
…

Example: Assigning association to two groups.

<ber:relationAssoc dbName="R_A" id="r_1" name="Abc">
  <ber:groupsArray>
    <ber:group id="group_1"/>
    <ber:group id="group_2"/>
  </ber:groupsArray>
  <ber:srcRole refId="rt_1"/>
  <ber:destRole refId="rt_2"/>
</ber:relationAssoc>

Some groups don’t have to be explicitly defined in project metadata. Such so called “system groups” are generated dynamically by the system according to some other configuration. Example of such system group: group search includes all feature types included in search.xml, group collaboration-comments includes feature types from collaboration.xml.

tip

Assigning parent feature type to a group means all its child feature types are assigned to the group as well.

tip

Content of one or more groups can be evaluated by executing following REST request (individual groups separated by comma):

http://server:port/project/rest/metadata/group/business,collaboration-comments,search