General principles

  • The dependencies of the data model (i.e. the namespaces used) have been augmented to use OWL specification, when needed. Hence there are no orphan references but always a reference at least to OWL. In this manner we can avoid possible validation errors. 
  • Localised data (e. g. alternative titles in other languages) is removed if the corresponding language is not found in the data model metadata. This is mostly the case for references outside the FI-Platform (like DCAT) where resource names and descriptions could be found in many languages (e.g. in Arabic) that have not been used in the actual data model.
  • Resource identifiers in the new application are case sensitive. That is, it is not allowed that a resource is found with both lower case and upper case initials, for example jhs:Role (category) and jhs:Role (association). In these cases, the suffix '_' is added to the latter. All objects referring to this renamed resource are automatically renamed.
  • External resources are not added to the model. They will appear in the visualisation only, with a curie identifier like modelID:resourceName
  • The modification and creation dates of resources are imported from the previous Data Model tool, if the data model has this this information. The new application also shows the name of the creator/editor of the resource, but since this information was not available in the old application, it is not migrated to the new tool. When the migrated resource is edited in the new tool, the name of the editor will be saved.
  • The visualization data is imported from the old tool for the class locations only. The associative relation lines from a source class to a target class have not been imported, but have to be redrawn manually in the new tool. 

Core Vocabularies

  • If the association explicitly has a superclass reference (the association name is "superclass" or "inherits"), then the former associative relation is replaced by the rdfs:subClassOf reference. In the visualisation, this is indicated by a new line type, namely a dashed line representing the inheritance.
  • The target of the association is inferred primarily from the constraint property rdfs:range. If that is not applicable, then the property sh:node is used. If the reference is to an association used in another data model, then itsn property rdfs:range is used. If the target of the association cannot be inferred, the association constraint has not been added to the migrated class.

Application profiles

  • If the resource associated with the class does not have a local identifier (localName) defined, then the UUID generated for the resource is used. The prefix 'uuid-' is added to the identifier, as the resource identifier must not start with a number. If needed, the identifiers can be edited to make them more meaningful by using the Edit Identifier function that is available in the new tool. 
  • The attribute and association constraints are renumbered by sequential numbering, e.g. name-1, name-2, etc. if there are overlapping names in the old data model. 
  • The class (restriction) of the application profile should have a target class (sh:targetClass) in a respective core vocabulary, indicating from which actual class this application profile class is derived or inherited. If the target class has not been defined in the old tool and, therefore, cannot be inferred, the target class is automatically set to owl:Thing. Similarly, for attributes and associations, the target (sh:path) is set to owl:DatatypeProperty / owl:ObjectProperty, respectively. 


  • No labels