Configuration Parameters
Overview
The configuration parameters in model2owl define various aspects of how the transformation processes work. These parameters control namespace handling, ontology URIs, stereotype validations, reused concepts generation control, tags/comments generation, controlled vocabulary generation and constraints, metadata generation, status filtering.
Understanding these parameters allows users to fine-tune the output of the transformation, ensuring it aligns
with their requirements. Parameters are primarily stored in config-parameters.xsl
and linked XML files such as
namespaces.xml
, umlToXsdDataTypes.xml
, and xsdAndRdfDataTypes.xml
.
The configuration file used in model2owl is not an ordinary XML file. It is an XSLT-based configuration,
meaning that specific syntax and structure must be followed for it to work correctly.
Parameters are defined as XSLT variables (<xsl:variable>
), and their values directly affect the transformation
process.
Important:
-
When modifying this file, ensure that the XSLT specification is strictly followed. Improper syntax or unsupported XSLT elements can cause errors during the transformation process.
-
It is highly recommended to review the existing configuration examples first and understand that each parameter has a specific data type that must be respected.
-
Do not delete variables, as they are essential to the transformation process. Removing them will result in errors.
List of Configuration Parameters
Core parameter mappings
These parameters ensure that the system retrieves and applies predefined namespace prefixes, UML-to-XSD datatype mappings, and XSD-to-RDF datatype definitions from their respective configuration files.
They act as references to external XML documents that are part of the configuration, storing them in variables for use within the transformation process. This approach enhances modularity, allowing datatype mappings and namespace definitions to be updated independently without modifying the core configuration.
Note:
It is not recommended to modify these parameters unless absolutely necessary. Changing them may break the link between the main configuration file (config-parameters.xsl) and the supporting configuration files (namespaces.xml, umlToXsdDataTypes.xml, xsdAndRdfDataTypes.xml). This could result in errors or inconsistent behaviour during the transformation process.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
XML Document |
Defines the prefixes and base URIs for namespaces. |
( |
|
XML Document |
Maps UML atomic types to XSD datatypes. |
( |
|
XML Document |
Defines XSD datatypes that conform to OWL2. |
( |
General parameters
This section defines general configuration settings that control how model2owl processes data. These parameters specify namespace handling, base URIs, object property types, type of attributes that take values from a controlled list, allowed characters for normalised strings, default delimiter in URIs, etc.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
Boolean |
If |
|
|
String |
The base URI for the ontology. |
|
|
String |
The base URI for SHACL shapes. |
|
|
String |
The base URI for OWL restrictions. |
|
|
String |
The default delimiter to use when a namespace lacks one. |
|
|
List |
Defines types that can produce object properties. |
|
|
String |
The type of attributes that take values from a controlled list. |
|
|
String (Regex) |
Defines allowed characters for normalised strings. |
|
|
List |
Lists the UML versions supported by model2owl. |
|
Stereotypes parameters
This section defines the valid stereotypes that can be applied to different UML elements, such as attributes, objects, generalisations, associations, dependencies, and classes. For more details about stereotypes, please refer to UML Modelling Conventions – Stereotypes and Tags.
Certain stereotypes, like "Abstract", classify a class as abstract, while others, such as "Disjoint" and "Equivalent", define relationships between generalisations. These settings ensure correct interpretation of UML models during transformation.
Note: Changing these parameters may affect how UML models are processed and how elements are classified in the generated ontology.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
List |
Defines acceptable stereotypes on attributes. |
|
|
List |
Defines acceptable stereotypes on objects. |
|
|
List |
Defines valid stereotypes for generalisations. |
|
|
List |
Defines valid stereotypes for associations. |
|
|
List |
Defines valid stereotypes for dependencies. |
|
|
List |
Defines valid stereotypes for classes. |
|
|
List |
Defines valid stereotypes for data types. |
|
|
List |
Defines valid stereotypes for enumerations. |
|
|
List |
Defines valid stereotypes for packages. |
|
|
List |
Defines which stereotypes classify a class as abstract. |
|
Controlled vocabulary parameters
This section defines settings for handling controlled vocabularies in model2owl. These parameters determine whether enumeration items are converted into SKOS concepts and whether entire enumerations are structured as SKOS concept schemes.
Additionally, constraint levels can be applied to UML enumeration objects to specify how SHACL shapes should be generated for controlled vocabularies. This allows for fine-grained control over validation and enforcement in different vocabularies.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
Boolean |
Enables or disables the transformation of enumeration items into SKOS concepts. |
|
|
Boolean |
Enables or disables the transformation of enumerations into SKOS schemes. |
|
|
String |
Property used for constraint levels in controlled vocabularies (compact URI). |
|
CV Constraint Level
Due to the diversity of controlled vocabularies (CVs) that a project may use, it is necessary to have precise control over the type of SHACL shapes generated for each CV. This information will be stored within the UML model itself by using a tag with a key defined in the configuration (cvConstraintLevelProperty).
There are two possible constraint levels that determine the type of SHACL shape generated:
-
permissive – Generates a permissive SHACL shape for the related UML enumeration.
-
restrictive – Generates a restrictive SHACL shape for the related UML enumeration.
Note:
A tag with a key specified in cvConstraintLevelProperty
is not included in model2owl artefacts;
it is used solely to determine the type of SHACL shapes to be generated.
If a controlled vocabulary does not have a constraint level defined in the model, it will default to a permissive SHACL shape.
Reused concepts parameters
This section defines parameters that control the generation of reused concepts in different artefacts. Reused concepts are elements considered external but included in certain outputs to maintain consistency across the ontology.
To provide granular control, individual configuration variables allow users to specify whether reused concepts should be included or excluded for each type of artefact:
-
SHACL artefacts
-
OWL Core ontology
-
OWL Restrictions
-
Glossary
Additionally, a dedicated prefix list ensures that certain concepts are always treated as internal, preventing them from being excluded even if they would otherwise be classified as "reused."
With these parameters (generateReusedConceptsSHACL
, generateReusedConceptsOWLcore
, generateReusedConceptsOWLrestrictions
,
generateReusedConceptsGlossary
), users have full control over which artefacts generate reused concepts.
Each of these variables acts as a toggle for its respective artefact type:
-
true
→ The artefact will include reused concepts. -
false
→ The artefact will exclude reused concepts.
The includedPrefixesList
parameter ensures that certain prefixes (e.g., epo
, epo-not
, epo-ord
)
are always treated as internal. This means that concepts with these prefixes will always be included,
even if they would sometimes be classified as reused.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
List |
Defines prefixes for concepts that should be included in generated artefacts. |
|
|
Boolean |
Enables or disables the inclusion of reused concepts in SHACL artefacts. |
|
|
Boolean |
Enables or disables the inclusion of reused concepts in OWL core artefacts. |
|
|
Boolean |
Enables or disables the inclusion of reused concepts in OWL restrictions. |
|
|
Boolean |
Enables or disables the inclusion of reused concepts in the glossary. |
|
Status filtering parameters
This section defines parameters that control status-based filtering in model2owl.
Status filtering is a flexible mechanism that allows users to specify which UML elements should be included or excluded based on predefined status values. Since model2owl does not assume logical correctness of the statuses assigned to UML elements, it is the modeller’s responsibility to ensure that statuses are set correctly to maintain a consistent RDF representation.
Status Filtering
Status filtering in model2owl is fully configurable, allowing users to define custom status values for UML elements. model2owl does not impose fixed status values; instead, users must establish a list of valid statuses for their specific project.
Status Filtering Guidelines
The modeller must ensure that statuses are applied correctly to maintain consistency. The following cases require special attention:
-
Classes linked by a connector → If one or both classes are filtered out, the connector should also be filtered out.
-
Classes with attributes → If a class is filtered out, all its attributes should also be filtered out.
-
Class inheritance → If a superclass is filtered out, all its subclasses and related UML elements should also be filtered out.
Filtering out means that a UML element is assigned a status that prevents it from being included in the generated artefacts.
Defining Statuses in UML Models
Statuses should be assigned to UML elements using UML tags (tagged values). A compact URI representing the status property should be chosen and applied as a tag to elements where status-based filtering is needed.
Additionally, elements without a status tag will be assigned a default status defined
in the configuration (unspecifiedStatusInterpretation
). This ensures that even elements
missing an explicit status can be processed consistently.
Model2owl status configuration parameters
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
String |
Defines the property used to indicate an element’s status. |
|
|
List |
Defines the list of valid statuses for elements. |
|
|
List |
Defines statuses that should be excluded from the output. |
|
|
String |
Defines the default status for elements without an explicitly set status. |
|
Example: Status Filtering in Action
UML Element | epo:status Tag |
---|---|
|
|
|
|
|
|
|
not set |
|
|
Model2owl configuration
<xsl:variable name="statusProperty" select="'epo:status'"/>
<xsl:variable name="validStatusesList" select="('proposed', 'approved', 'implemented')"/>
<xsl:variable name="excludedElementStatusesList" select="('proposed', 'approved')"/>
<xsl:variable name="unspecifiedStatusInterpretation" select="'implemented'"/>
xml
Outcome: Included and Excluded Terms
UML Element | Included in Generated Artefacts? |
---|---|
|
|
|
|
|
|
|
|
|
|
Key Takeaways
-
Elements with a status in
excludedElementStatusesList
are not generated. -
Elements without a status use the default value set in
unspecifiedStatusInterpretation
. -
If a status value is not listed in
validStatusesList
, an error is triggered. -
The
statusProperty
tells model2owl which property is used in UML tags to express the status of an element. Model2owl interprets these tags to determine element status.
Comments generation
This section defines parameters that control how comments are handled in the generated artefacts. Comments can be included to provide additional explanations, annotations, or editorial notes within OWL or SHACL outputs.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
Boolean |
Enables or disables the generation of comments in the output. |
|
|
String |
Specifies the property used for comments in the output. |
|
Tags
Model2owl uses tags found in the UML model in two distinct ways:
-
To generate corresponding RDF statements that express metadata about concepts, following the transformation rules for tags.
-
To control the generation process at the UML element level by using specific tags that describe an element’s status or constraint level (control tags).
Control tags influence the generation process by altering how elements are transformed into semantic artefacts. These tags modify or control specific behaviours during the transformation process, such as filtering elements based on their status or applying constraints.
Model2owl relies on certain tags to define properties such as:
-
Status of elements (statusProperty)
-
Constraint level of controlled vocabularies (cvConstraintLevelProperty)
Since these tags are only required internally for processing and filtering, they are not included in the generated OWL and SHACL artefacts.
The excludedTagNamesList
variable ensures that these tags are filtered out, preventing them from appearing in the output while still allowing them to control how elements are processed.
Note:
This exclusion only affects the representation of the tags in the final artefacts—it does not impact their functionality in filtering or validation.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
List |
Defines tag names that should be excluded from the output. |
|
Convention report parameters
This section defines parameters used in the generation of the convention report. The convention report provides a structured evaluation of the UML model, ensuring it adheres to predefined rules and best practices. These parameters allow users to customise report metadata, such as the copyright statement, author details, and the UML model name included in the report.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
String |
Defines the copyright text for the convention report. |
|
|
String |
Defines the author of the convention report. |
|
|
String |
Defines the location of the report’s author. |
|
|
String |
Defines the website of the report’s author. |
|
|
String |
Defines the name of the UML model in the report. |
|
Metadata parameters
This section defines metadata parameters used in the generation of OWL Core, OWL Restrictions, and SHACL Shapes artefacts. Metadata plays a crucial role in identifying, describing, and managing ontology components, ensuring that each generated artefact contains the necessary information.
Parameter Name | Data Type | Description | Default Value |
---|---|---|---|
|
String |
Defines the module reference identifier. |
|
|
String |
Defines the title for the OWL Core ontology. (dct:title) |
|
|
String |
Defines the title for the OWL Restrictions ontology. (dct:title) |
|
|
String |
Defines the title for the SHACL Shapes ontology. (dct:title) |
|
|
String |
Provides a detailed description of the eProcurement Ontology Core. (dct:description) |
Some text |
|
String |
Provides a detailed description of the eProcurement Ontology Restrictions. (dct:description) |
Some text |
|
String |
Provides a detailed description of the eProcurement Ontology Shapes. (dct:description) |
Some text |
|
String |
Defines the label for the OWL Core ontology. (rdfs:label) |
Some text |
|
String |
Defines the label for the OWL Restrictions ontology. (rdfs:label) |
Some text |
|
String |
Defines the label for the SHACL Shapes ontology. (rdfs:label) |
Some text |
|
Date |
Defines the ontology’s issuance date. (dct:issued) |
Automatically set to current date |
|
Date |
Defines the ontology’s creation date. (dct:created) |
Automatically set to current date |
|
String |
Defines the status of the ontology. (bibo:status) |
|
|
String |
Defines the ontology version. (owl:versionInfo) |
|
|
String |
Defines the prior version of the ontology. (owl:priorVersion) |
|
|
String |
Defines the preferred namespace URI. (vann:preferredNamespaceUri) |
|
|
String |
Defines the preferred namespace prefix. (vann:preferredNamespacePrefix) |
|
|
String |
Defines the licensing terms for the ontology. (dct:license) |
|
|
String |
Defines the publisher’s URI. (dct:publisher) |