# Tagging Models for Semantic Databases

The information model supports mapping your data model to a unique semantic database or a standard product data source such as: eCl@ss, Profibus, etc. To make it easy to find your types, the types support adding a tag property to provide information that the type might be able to be manually mapped to a product data source like Profibus. Adding tags does not allow the Ability Platform to map any types automatically. It is still up to the user to build in any mapping mechanism if that functionality is desired.

The approach is based on identification using URN schemas for tags (as defined in rfc4151) as defined below:

Adding a tag to a type definition allows you to map your type to a semantic database model, if applicable. This allows for the platform to read the namespace for the data source. However, to ensure that your type definition is able to be read correctly, the tags must follow the URN schema for tags. To reiterate that the platform dos not automatically map types, the tags are purely strings that follow this predefined schema purely to allow for querying later once the types have been stored in the platform. The tags themselves to not initiate any mapping functionality to the semantic databases. Below is a generic example of the syntax for a URN schema tag. If you are curious of the origins of this schema, please read the paper on the original definition defined by The Internet Society.

tag:<namespace>,<date>:<id>

For each semantic link the namespace of the product data source will be used accordingly (e.g., ecl@ss.org) in the type definition. The date is defined as when the tag was created. The date parameter, for example, may be the release date of the specific version of the standard that is used in the namespace.

By following this tagging schema the information model is able to leverage a number of benefits to allow for more stable and generic modeling strategies. This tagging is generic enough that it allows you to map to many different standard sources sa previously mentioned like ec@lass and Profibus. If you have a single object model that has information coming from multiple different sources this tagging option will allow you to provide multiple identifiers depending on the context to allow you to feed data to the correct model depending on the context of your solution. This tagging method is non intrusive and does not force any changes on your original model when you map to a different source. Adding these tags also makes your models efficiently query-able by following the domain specific language functionality built into the platform Information Model API.

# Tagging Examples

# eCl@ss

tag:eclass.org,2017:AAB998016

refers to “27-20-02-08 Temperature measuring electr. Complete” according to the eCl@ss classification directory.

# IEC61987

tag:iec61987,2016:0112/2///61987#ABA565

refers to definition of the "Manufacturer" property as defined by IEC61987 - Identification:

Code:  0112/2///61987#ABA565
Version: 002
Revision: 05
IRDI: 0112/2///61987#ABA565#002
Preferred name: manufacturer
Synonymous name: DEVICE_VENDOR
Definition: name of the manufacturer of a device

# ISO29002-5

tag:iso.org,2009:iso9002-5/nnn-xxx-xxx#xx-xxxxxx#n

For example:

tag:iso.org,2009:iso9002-50173-1#01-AAA123#001

# Example Tagged Type Definition

{  
  "model": "abb.ability.device",
  "typeId": "abb.iama.TTH300",
  "version": "1.0.0",
  "name": "TTH300",
  "tags": ["TTH300",
     "tag:eclass.org,2017:AAB998016",
     "tag:namur.de,2017:NE43-Messumformer",
     "tag:servis.abb.com,2017:24890zhh890t4h80",
     "tag:products.abb.com,2017:24890zhh890t4h80",
     "Asset"],
  "properties": {
     "manufacturer" : {
      "dataType" : "string",
      "tags" : ["tag:iso.org,2016:iec61987/0112/2///61987#ABA565"]
     }
  },
  "variables": {
     "temperature1" : {
      "dataType": "number",
      "unit" : "°C",
      "min"  : "-20",
      "max"  : "500",
      "tags" : [
          "tag:eclass.org,2017:0173-1#02-BAB726#007",
          "tag:profibus.org,2017:names/PV_SCALE.EU_at_0%",
          "tag:profibus.org,2017:indices/11[0]"
       ]
    }
  }
}

If your solution is handling any GDPR relevant data, and requires the need to store this type of data in the Ability Platform, it is important to follow all regulations for privacy protections. The model tagging functionality makes it simple to identify any GDPR relevant elements of a model (e.g., properties, events, etc.). Therefore, the data can easily be queried for the relevant privacy tags and handled according to the regulations (e.g., easily be removed). It is important to note that these tags do not have any privacy functionality built into their use. They are purely a mechanism for you to easily query and identify any relevant properties to ensure your solution is GDPR compliant.

# Personal Information

tag:abb.com,2019:gdpr/personal-data

Some examples for personal data are:

First Name
Last Name
Business Address
Business Email
Business Telephone Number
Business Mobile Number
Work Time Logging

There are more examples of personal data than listed here, so please ensure you are familiar with all forms of personal data that are expected to be protected under GDPR.

# Sensitive Personal Information

tag:abb.com,2019:gdpr/sensitive-personal-data

This tag shall be used for this this type of data:

Racial or Ethnic Origin
Political Opinions
Religion/Philosophical beliefs
Trade Union Membership
Genetic Information
Biometric Data
Health / Medical Data
Sex life or Sexual orientation
Criminal Record

For more information on how to treat GDPR relevant data see the GDPR Portal

← Type Definitions Semantic Versioning Object Model Ownership →