rules for concept and data modelling · the model rules contribute to better data and increased...

Rules for Concept and Data Modelling

Version 1.0.0

1

Contents Introduction .............................................................................................................................................................................................3

i Introduction ......................................................................................................................................................................................4

ii Reading guide for the model rules ...................................................................................................................................................7

Generally Applicable ................................................................................................................................................................................9

01 Use UML as the visual model language .......................................................................................................................................10

02 Use only select UML elements .....................................................................................................................................................11

03 Publish the model online .............................................................................................................................................................13

04 Publish the model in machine-readable format ..........................................................................................................................14

Models ...................................................................................................................................................................................................15

05 State meaningful names for models ............................................................................................................................................16

06 State the namespace of the model package ................................................................................................................................17

07 State the preferred prefix of the model package ........................................................................................................................18

08 State the ownership of the model ...............................................................................................................................................19

09 State the theme of the model......................................................................................................................................................20

10 State the version of model...........................................................................................................................................................21

11 State the business approval status of the model .........................................................................................................................22

12 State the status of the model ......................................................................................................................................................23

13 Document the link between the legal basis and the concept model ...........................................................................................24

14 Document the link between concept models and core models ..................................................................................................25

Common to Model Elements .................................................................................................................................................................27

15 State meaningful UML names for model elements .....................................................................................................................28

16 Assign all model elements an identifier .......................................................................................................................................29

17 Generate element names that are qualified names based on the HTTP-URI of the element ......................................................30

18 State terms in common language ................................................................................................................................................31

19 State equivalent terms in English ................................................................................................................................................33

20 Use standardized naming conventions ........................................................................................................................................34

21 Compose definitions or descriptions of the model elements ......................................................................................................36

22 Compose structured definitions in a standardized way ...............................................................................................................38

23 Compose application neutral definitions .....................................................................................................................................39

24 Compose English definitions ........................................................................................................................................................40

25 Document the link between the legal basis and the model elements .........................................................................................41

26 Document the link between elements in core models and application models ..........................................................................43

27 Reuse existing core model elements ...........................................................................................................................................45

28 Document the provenance of new elements ..............................................................................................................................47

Concepts ................................................................................................................................................................................................49

29 Define concepts using the stereotype 'RdfsResource' .................................................................................................................50

2

30 State which concepts belong to the business domain .................................................................................................................51

Classes ...................................................................................................................................................................................................52

31 Define classes using the stereotype 'OwlClass' ............................................................................................................................53

32 Declare a class as a specialization by using the tag ‘subClassOf’ .................................................................................................54

Properties ..............................................................................................................................................................................................56

33 Declare a property as a specialization by using the tag 'subPropertyOf' .....................................................................................57

34 Declare the domain of a property using the tag 'domain' ...........................................................................................................60

35 Declare the range of a property with the tag 'range' ..................................................................................................................63

36 Declare exactly one domain and exactly one range for each property .......................................................................................66

37 Declare a property as functional using the tag ‘functionalProperty’ ...........................................................................................68

Object Properties ...................................................................................................................................................................................70

38 Use association ends with the stereotype 'ObjectProperty' to define object properties ............................................................71

39 Declare an object property as being symmetric by using the tag ‘symmetricProperty’ ..............................................................72

40 Declare an object property as being transitive by using the tag ‘transitiveProperty’ ..................................................................74

41 Declare an object property as being inverse functional by using the tag ‘invFunctionalProperty’..............................................76

42 Declare the inverse property of an object property by using the tag 'inverseOf' ........................................................................78

Datatype Properties ..............................................................................................................................................................................80

43 Use attributes with the stereotype 'DatatypeProperty' to define datatype properties ..............................................................81

Datatypes ..............................................................................................................................................................................................82

44 Use standardized and published RDF-compatible datatypes ......................................................................................................83

45 Document user-defined datatypes ..............................................................................................................................................84

Individuals .............................................................................................................................................................................................85

46 Define objects using the stereotype 'Individual' ..........................................................................................................................86

47 Use the class ‘owl:Thing’ as superordinate class for all individuals .............................................................................................87

48 Use the object property ‘rdfs:type’ to declare object type .........................................................................................................89

Classification ..........................................................................................................................................................................................90

49 Define classification classes as subsets of the class ‘skos:Concept’ .............................................................................................91

50 Model classifications as classes and classification elements as instances ...................................................................................92

51 Declare classification elements as instances of a classification class...........................................................................................93

52 Use 'dct:type' as a property to indicate classifications ................................................................................................................94

References .............................................................................................................................................................................................95

Appendices ............................................................................................................................................................................................98

Appendix A: Plus Profile ....................................................................................................................................................................99

Appendix B: Datatypes ...................................................................................................................................................................101

Appendix D: Example Models .........................................................................................................................................................104

Appendix E: Information types in the concept model ....................................................................................................................107

3

Introduction

The Rules for Concept and Data Modelling – commonly referred to as the model rules - operationalize the

White Paper's architecture rule 6.2 in White Paper on a common public-sector digital architecture: Use

common rules for documenting data.

Through use of the model rules, it is ensured that concepts and data are described and documented thoroughly, correctly and consistently. This is an important prerequisite for authorities and companies to retrieve understand and use data originating from other authorities. Model rules are based on national and international methods, standards and experience.

The rules for concept and data modelling are owned by the steering committee for data and architecture, which is a steering committee under the auspices of the Digital Strategy 2016-2020.

4

i Introduction

Why have model rules in the public sector?

The model rules contribute to better data and increased sharing and reuse of data across the public sector. The model rules have three overall objectives:

1. to ensure that business knowledge is the basis for data modelling and development 2. to ensure coherent data across the public sector 3. to ensure reuse with the purpose of minimizing the total resources and time spent on developing

and maintaining IT solutions.

These three purposes must be considered throughout the modelling process. It is especially crucial to keep them in mind during the very first steps of the process, as it is in the business understanding and the organization of data modelling that the major changes must be achieved in order for the vision to become reality.

The model rules must be used by the initiatives that are part of the digital strategy and are recommended for use in the public sector as a whole.

The application of the model rules must take into account that a given sector may be bound by other considerations, such as international rules and standards for concept and data modelling.

What problems do the model rules seek to remedy?

The absence of shared guidelines for designing, sharing and reusing concept- and data models equals the absence of an essential means to achieve the digital strategy's goal of a common data architecture where good data is shared and reused.

The absence of shared guidelines may have several negative consequences:

Models are rarely published, shared or reused Models are heterogeneous and difficult to assemble Models are not rooted in the business There is no coherence between legislation and IT systems

What are the benefits of the model rules?

The benefits of applying the model rules are:

Good international modelling practice: The model rules are a collection of recognized and internationally rooted methods for good concept and data modelling. Following the model rules makes it easier to model well.

Concepts and data can be more easily reused: When the model rules are used, concepts and data are described more consistently across authorities, making it easier to reuse descriptions of concepts and data from other authorities.

5

Coherence between legislation and IT Systems: The model rules support rigorous and effective transfer of legal concepts to the interfaces of IT systems, which increases the quality and efficiency of public sector digitalization.

Shared language, competence development and tools: The model rules give model owners a shared language that promotes collaboration, and facilitate initiatives for competence development as well as shared modelling tools.

Better preparation for new opportunities for using data: The possibilities for using data are rapidly evolving and it is difficult to predict how public sector data may be used in the future. By using the model rules, the door to the future is kept open.

What experience and methods do the model rules build on?

International methods and standards for modelling and data dissemination are the methodological foundation for the model rules. Further, the rules for concept and data modelling may be considered a continuation and extension of the model rules for the Basic Data Programme, which itself builds on national and international experience.

What is the basic idea of behind the model rules?

The basic idea is to provide a framework for achieving coherence between legislation and IT systems. In other words, it must be possible to trace a concept from its definition in the law, through the modelling to its actual use in a data set or an IT system, as illustrated in the figure below.

What rules must be observed in relation to a given need?

The goal of coherence from legislation to IT systems is ambitious, so it must also be possible to get started without necessarily fulfilling all the model rules and gaining the full benefits.

6

The rules are organized in three successive levels, as illustrated in the figure below.

First level (dissemination) consists of a smaller number of rules, the next level (reuse) entail additional rules, while the last level (coherence) encompasses all the rules. The choice of level - and thus the subset of rules - can thus be adapted to the modelling capabilities of the organization and the specific purpose of the data to be modelled.

What are the model rules about?

Model rules have been developed within a number of areas in order to ensure:

That concept- and data models are developed That models at different abstraction levels are linked That the same modelling language is used That there is clarity about model ownership, versioning and approval status That models are available to users That concepts and data are named unambiguously and meaningfully That concepts and data are defined comprehensively

These model rules constitute a contribution to a shared public sector data architecture and a shared modelling language. They provide a tool for public sector management, so that they can help create a culture of good concept- and data modelling that supports the goal of good data and efficient data sharing.

There is no doubt that this ambitious goal will require resources and that benefits are largely realised in the long term, but adopting this agenda should be seen as a strategic and valuable investment in good public data.

7

ii Reading guide for the model rules

The rules are divided into chapters that allow for an overview of general rules, rules applicable to the model and rules that apply to the model's elements. Each rule is described by the same pattern which is explained below.

Level (in table) Specifies which modelling level the rule belongs to

Model Type (in table) Specifies which model types the rule applies to and its relevance

Name Specifies the name of the rule

Rule Clearly and accurately indicates the rule

Rationale Describes value to the business of following the rule

Implication

Describes the properties that models and model elements must have to comply with the rule. In general, it should be mentioned that where the implementation in a concept list often consists of a standardized "headline" with a value, in UML-models on the reuse level it will consist in filing out a particular tag. Properties of this type are presented in a small table, stating: Name : Linguistic appellation of the property

Definition : Description of the meaning of the property

Value Space : Description of the values the property may have

Source : Indication of the vocabulary element from which the property originates,

its qName and its definition

Examples Provides concrete examples of meeting the implication

Model types:

concept model : model that describes the concepts of a specific domain and their relationships o concept list : representation of a concept model in list form o concept diagram : representation of a concept model expressed as a diagram

logical model: model that describes what information is part of a defined context and how it is logically linked

o core model : reusable logical model of a domain focussing on a central business object that does not define model elements defined in other core models

o application model : logical model aimed at a specific application situation in a defined context

logical model in RDF: logical model based on the RDF description framework: o vocabulary : core model, based on the RDF description framework, which ensures semantic

unambiguity, coherence and machine accessibility o application profile : application model that by means profiling reuses selected elements

from one or more vocabularies based on the RDF description framework

8

Modelling Level: Modelling Level is specified for each rule. The model rules are divided into three levels:

Level 1 (dissemination): This level consists of a small number of basic rules that deal with basic documentation of the model, adding business metadata, a uniform graphic expression, and the model being published on the Internet.

Level 2 (reuse): This level adds additional rules that relate to reuse of model elements from existing models, higher quality in definitions and names, as well as the use of a standardized exchange format.

Level 3 (coherence): This level adds additional rules relating to data coherence, allowing seamless, automatic data retrieval in services, as well as self-describing data.

The total number of rules can at first seem overwhelming. Thus, it is important to keep in mind that the rules focus on these three levels of modelling. Each IT project - in conjunction with its management framework – decides for itself which modelling level is to be achieved. Additionally, not all rules are relevant to all models, as a rule must only be observed if the content of the model indicates that it is relevant. For example, the rule 'Document user-defined datatypes' is of course only relevant if the model uses custom datatypes.

Relevance: The relevance of a rule is specified for a model type by using the following terms: MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT simply – (not applicable). These terms are taken from IETF RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels". Relevance is given - for each model type - in a table of the following type under the title of each rule:

Concept List Concept Model Core Model Application Model Vocabulary Application Profile

Tool support: Compliance with the rules is significantly facilitated by setting up the specified UML profile in UML modelling tool used by one’s organization. Implementation of the defined UML profile will, for example, make all the defined stereotypes and tags readily available to modellers and errors when manually entering stereotypes and tags may be avoided.

The recurring example: A fictitious comprehensive example has been constructed, which serves to illustrate the implications of the individual rules. The example deals with electricity and heat supply (FORM 56.05) focusing on power generation plants, and although the model owner is listed as the Danish Energy Agency, this is merely a constructed example, which does not represent the Danish Energy Agency's modelling of the domain - nor are the concepts verified by experts. Only legal texts, relevant online datasets (particularly master data sets for wind turbines) and descriptions have provided the basis for the example. The complete recurring example can be found in Appendix D: Example Models.

9

Generally Applicable

One of the goals of the model rules is to create a basis for effective communication.

Effective communication between business and IT throughout the development process from idea to implementation.

Effective communication between modellers through recognisable modelling expressions and standardization of model elements and metadata.

Effective communication between IT systems by providing a basis for direct reuse of the concepts and model data defined by the business in actual system data exchanged between IT systems.

To facilitate this communication, the widely used model language, Unified Modeling Language (UML), is used. Specifically, diagrams are used for modelling classes and objects to create a standardized and visually comprehensible expression.

The underlying metamodel for UML has been created to be so flexible that it can be expanded and adapted relatively easily. This is utilized by adding a metamodel that adds new useful elements on the semantic level, provides a semantically unambiguous (machine-interpretable) language and enables efficient reuse and exchange of both models and data.

In order to make models reusable, it must be possible for others to find them, and it should be possible for others to use them in their own UML model tools.

Therefore, models must be shared and they must exchangeable in a standardized model exchange format.

10

01 Use UML as the visual model language

Rule All models must be defined as UML class diagrams using UML elements only in accordance with the Unified Modeling Language ™ (UML®) standard in version 2.0 or later versions [OMG 2015].

Level 1: Dissemination


- MUST MUST MUST MUST MUST

Rationale UML class and object diagrams are a standardized, accessible and sufficiently unambiguous way of visualizing models, which is also open to expansion and further specification. The visually simple expression in a UML diagram can serve as an easy-to-understand representation of the business concepts and as a means of communication between data modellers and between data modellers and programmers. Potentially, class diagrams could be used for effective communication between people from different fields throughout the development process from idea to implementation of the solution. Implications UML class and object diagrams must be used for visual representations (diagrams) of concept models and logical models. All UML elements can be used in a dissemination level model, but in reuse and coherence level models only selected UML elements are to be used, namely 'Class', 'Generalization', 'Association', 'Association', 'Attributes' and 'Objects' as well as add-ons from the Plus-profile in the form of UML stereotypes and tags, cf. rule Use only select UML elements under Rules that promote reuse. This rule is automatically met by the MDG-technology

11

02 Use only select UML elements

Rule

All models must be defined as UML class diagrams using only the UML elements 'Class', 'Generalization',

'Association', 'Association end', 'Attribute' and 'Object' and the add-ons from the Plus-profile in the form of

UML stereotypes and tags [OMG 2015].

Level 2: Reuse



Rationale

ML is relatively easily expandable and sufficiently flexible to incorporate an RDF based metamodel in a way

that, among other things, provides a broader common foundation for semantically unambiguous language

at both model and data levels, and better reusability of other models and existing international data and

concept definitions expressed in RDF.

The incorporation and full utilization of the RDF-based metamodel requires, both that only select UML elements are used in UML class diagrams, and that the metadata of these model elements is specified using tags related to the metamodel.

Implications

UML class and object diagrams must be used to express conceptual diagrams and logical model types.

The following UML elements are permitted, and these UML elements can be mapped to an RDF representation.

Class: UML element used to describe a class of individuals Object: UML element used to describe a specific individual. NOTE: Used, for example, to model

members in a classification Attribute: UML element used to describe those of a class's properties that have a range consisting

of values Association : UML element used to relate objects of given classes to each other Association end: UML element used to describe those of a class's properties that have a range

consisting of a class Generalization: UML element used to relate a subclass to a superclass Package: UML element that may contain other UML elements, and which characterizes these as a

whole. A package defines and contains a model.

The following UML extensions of the specification of a UML element are permitted:

Stereotype: Extension of the specification of a UML element that specializes its application to a particular meaning and context

12

tag: Extensions the specification of a UML element by adding properties of UML model elements - i.e. metadata for the concepts that model elements model

The model type is indicated by the stereotype of the package:

Concept Diagrams - Create as packages with the stereotype Core Models - Create as packages with the stereotype Vocabulary - Created as packages with the stereotype Application Models - Create as packages with the stereotype Application Profiles - Create as packages with the stereotype

Concept models should consist solely of: classes, generalizations and named associations.

Core models and Vocabulary should consist solely of: classes, objects, generalizations and associations, association ends, attributes, and attribute types. Core models must be defined without multiplicity of properties.

Application models and application profiles should consist solely of: classes, objects, generalizations and associations, association ends, attributes, and attribute types. Application models must also be provided with multiplicity.

This rule is automatically met by the MDG-technology

13

03 Publish the model online

Rule

A model must be public and freely available on the internet and have representation in list format or

graphic illustration.



MUST MUST MUST MUST MUST MUST

Rationale

By exhibiting the models on the internet, free and equal access to the models is achieved.

Implications

The model owner must ensure that the model is published on the internet and that the user is presented

with a representation in list format or graphic format. In addition, it is intended that the URL from which

the model is published is persistent.

This rule cannot be met automatically by the MDG-technology

14

04 Publish the model in machine-readable format

Rule

The model must be available in a machine-readable format

Level 2: Reuse


MAY SHOULD MUST MUST MUST MUST

Rationale

Publishing the model in a machine-readable format allows modelling tools and machines to interpret the

content of the model. In addition, it facilitates reuse, as the modeller does not have to manually copy the

content and structure of the model for further use. The XML Metadata Interchange (XMI) format,

developed by Object Management Group (OMG), is a recognized exchange format for UML models, and has

become a de facto standard for interaction between UML tools. The vast majority of UML tools thus

support export and import of a model into a file in XMI format.

Implications

The model must be published in a file that complies with the XMI Standard [OMG-XMI 2015].

This rule is partially met by the MDG-technology

15

Models

In order to assess whether an existing model is appropriate for reuse in a new model, some information about the model must be available.

The information should indicate where in the development process a model is and who owns it. It should also be stated which subject area the model focuses on, and, when possible, what regulatory or legal basis the model is based on.

In addition, it may be useful to see the model's provenance, i.e. information about which other model or models it has been based on.

For the sake of consistent modelling across models, it would also be useful to indicate which abbreviation is suggested to indicate the model's 'namespace' - a so-called 'prefix'.

16

05 State meaningful names for models

Rule The model must be given a meaningful name.




Rationale It is appropriate that the model is given a meaningful and application neutral name, as it is the intention that the model should be read, used and reused by others, and it will facilitate dissemination, search and use. Implications Concept models, core models and vocabularies must be given meaningful names referring to the relevant subject matter and / or the central business concept.

In relation to the naming of concept models and vocabularies, it is recommended that you do so based on the element that is the focus of the model, which is typically presented graphically in the model as the element that links the other elements of the model and from which the relationships originate ". In application models, however, the naming will typically be associated with that application in a data system.

Similarly, usage models and application profiles must be provided with meaningful names referring to the application in question.

This rule is met by stating the model name using the model property 'model name':

Name: model name

Definition: the word or words that designate a model

Value space: text

Source: http://www.w3.org/2000/01/rdf-schema#label

(rdfs: label) "human-readable name for the subject."

Concept lists: Fill in 'model name' according to Appendix E UML models: Fill in the tag 'label (da)' and possibly. 'label (en)' on the model element

Examples

In concept list: 'model name' = electricity generation plant In core model: 'label (da)' = power generation plant In application model: 'label (da)’ = data registry for wind power plants

The rule cannot be met automatically by the MDG-technology

https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/2000/01/rdf-schema&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhiz66mn0UURkGvVTO0A8vTvPE4tIw#label

17

06 State the namespace of the model package

Rule Model packages are to be given unique identification using an HTTP-URI terminated with the fragment identifier #.

Level 2: Reuse



Rationale By using a unique HTTP-URI as an identifier for a model, the HTTP-URI can simultaneously function as a unambiguous identifier (~ unambiguous name) and potentially as unambiguous URL (~ unambiguous address), making it suitable both for unambiguous identification of elements and to subsequently find additional information about the element.

By using a unique HTTP-URI that ends with the fragment identifier # as the last character, the identifier can be used directly as the namespace for elements which the model defines. This ensures both unambiguous reference to the model and to the elements defined by the model, across other models and other systems.

Implications This rule is met by stating the selected HTTP-URI in the tag 'namespace'. The selected HTTP-URI serves both as a unique identifier for the package itself and as the namespace that the elements defined by the package is associated with.

Name: namespace

Definition: HTTP-URI base for creating unambiguous identification of resources (classes, individuals, recreations or values)

Value space: HTTP-URI

Source: https://www.w3.org/TR/ld-glossary/#uniform-resourceidentifier (Universal Resource Identifier) https://en.wikipedia.org/wiki/Namespace

UML models: Fill in the 'namespace' tag on the model package

Examples

In core model: 'namespace' = http://data.gov.dk/ns/energysupplyfacility


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=https://www.w3.org/TR/ld-glossary/&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgR05HiJ_voiwgv0F-M6AS7zhi1bg#uniform-resource-identifierhttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=https://en.wikipedia.org/wiki/Namespace&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhjv70Vh58diHc8rTSk3y9UZvkMoOghttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://data.gov.dk/ns/energysupplyfacility&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgmp677t9VWVaqszfbJ9-pI3s_c-w

18

07 State the preferred prefix of the model package

Rule For each package's namespace, a preferred prefix is to be defined.

Level 2: Reuse


- MAY MUST MUST MUST MUST

Rationale Visible use of prefixes on the classes and attributes of a model can help to give a better picture of the model's use of vocabularies and improved recognisability of the individual element.

Standardized use of prefix significantly contributes to increased recognisability of the individual element. Without a preferred prefix, it will be up to the individual user of the package’s elements to establish a prefix for use in their model. This increases the risk of establishing different prefixes and thus reduced recognisability and user-friendliness. By allowing the creator of a vocabulary to define a preferred prefix, a standardized application is enabled.

Implications This rule is met by specifying the preferred prefix with the model property 'namespacePrefix'

All packages are assigned a stereotype with the associated tag 'namespacePrefix', used to specify prefix. The model owner should as far as possible ensure that the prefix is not associated with a different namespace than the package's namespace, for example, by checking http://prefix.cc/ .

Name: namespacePrefix

Definition: Short name for a namespace

Value space: xsd: string

Source: http://www.linkedmodel.org/schema/vaem#namespacePrefix

UML Models: Fill in the 'namespacePrefix' tag on the model package

Examples

In core model: 'namespacePrefix' = esf

(short name for the namespace http://data.gov.dk/ns/energysupplyfacility )


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://prefix.cc/&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgn7LjAOA4XRcOy02DInYGBqmKy6ghttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.linkedmodel.org/schema/vaem&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhjn9_y3krs6d5EH3uLrCJf--rQ36A#namespacePrefixhttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://data.gov.dk/ns/energysupplyfacility&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgmp677t9VWVaqszfbJ9-pI3s_c-w

19

08 State the ownership of the model

Rule Ownership of and responsibility for the model and its elements must be clear and evident.




Rationale In order for a user to see if a model is relevant and applicable, it must be stated which authority owns the model. Ownership should in this context be understood as the responsibility to vouch for the content and structure of the model. The data owner is not necessarily the owner of the model used. For some fields, there may be separation between data ownership and 'specification responsibility' for the models describing data, for example, within the fields name registration and address registration. The ministries responsible for these (Ministry of Interior and Ministry of Energy, Supply and Climate) are also responsible for the specification of the data model, cf. regulations. Data is, however, compiled and quality assured by the municipalities. Information about model responsibility is thus very relevant when the modeller assesses whether a given model element is the correct / applicable expression of the business concept to be modelled. Implications This rule is met by specifying the model's ownership as the model property 'publisher'.

Name: publisher

Definition: public organization which undertakes to be responsible for the content and structure of the model

Value space: ownership should eventually be expressed as a reference to a structured organizational chart established under the direction of the digital strategy

Source: http://purl.org/dc/terms/publisher (dct: publisher) "An entity responsible for making the resource available"

Concept lists: Complete the information 'publisher' according to Appendix E UML models:

o (level 1 - Dissemination): Specify 'publisher' on the model diagram o (level 2 - Reuse): Fill in the tag 'publisher' on the model package

Examples

In concept list: 'model owner' = The Danish Energy Agency In core model: 'publisher' = The Danish Energy Agency

The ownership is indicated here with a name - The Danish Energy Agency - since it is not yet possible to provide a reference to a structured organization overview.


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://purl.org/dc/terms/publisher&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhjBkUGYRL9QkKMu1V0IQHdY1SxSwQ

20

09 State the theme of the model

Rule Specify the theme (primary subject area) of the model.



MUST MUST MUST SHOULD MUST SHOULD

Rationale By classifying the models by theme, according to a shared reference model, the search, reuse and application of published models is facilitated. It allows the user to use the themes as an entry point to find the desired model or model element without necessarily knowing a specific keyword. Implications

This rule is met by specifying the theme of the model as the model property 'theme'.

Name: theme

Definition: information that classifies a resource in a thematic category

Value space:

sufficiently precise reference to a relevant publicly available classification, such as The Danish Business Reference Model (FORM) - which classifies public administrative task types , or - if the subject area is not a classified public task - with another sufficiently standardized reference model.

Source: http://www.w3.org/ns/dcat#theme (dcat: theme) "The main category of the dataset"

Concept lists: Fill out the information 'theme' according to Appendix E UML models:

o (level 1 - Dissemination): Enter 'theme' visible on the model diagram o (level 2 - Reuse): Fill in the tag 'theme' on the model package

Examples

In concept list: ‘theme' = 56.05 (Electricity and heat supply) In core model: 'theme' = 56.05 (Electricity and heat supply)

The subject is indicated here with a text string - since it is not yet possible to use a shared classification service


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/ns/dcat&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhhE1_nhaQPiAetLw15nVe3V6WFlMQ#theme

21

10 State the version of model

Rule The model version number and latest update date must be stated.




Rationale By providing the model with information about version number and latest update date, it will be easier for the user to assess whether a given model or elements from it can be used for a particular purpose. Among other things, the user can easily determine which version of a specific model is the latest and when the model has last changed. Implications

This rule is met by stating the model update date and version number as the model properties 'update date' and 'version number', respectively.

Name: date modifed

Definition: the date of the latest changes

Value space: date

Source: http://purl.org/dc/terms/modified (dct: dateModified) "Date on which the resource was changed"

Name: version info

Definition: unique identification of a specific version

Value space: outbound space built with a major version, minor version and revision separated by period, eg: 1.0.0 [ http://semver.org ]

Source: http://www.w3.org/2002/07/owl#versionInfo (owl: versionInfo) "The annotation property that provides version information for an ontology or another OWL construct"

Concept lists: Fill out the ‘date modified' and 'version info' information in accordance with Appendix E

UML models: o (level 1 - Dissemination): Enter ‘modified' and ‘versionInfo' visible on the model diagram o (level 2 - Reuse): Fill in the 'modified' and 'versionInfo' tag of the model package

Examples

In concept list: 'modified' = 02-02-2017, and 'version info' = 0.1.1 In core model: 'versionInfo' = 0.1.1, and 'modified' = 02-02-2017


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://purl.org/dc/terms/modified&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgJPe_PcS8w3ChElpNxVv6SeZMKbAhttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://semver.org/&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhi_pmNEkHdHbhWWXmk5wzMi-EXZJAhttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/2002/07/owl&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgQfRTggs6549P3WCSPm4tdLLb0fg#versionInfo

22

11 State the business approval status of the model

Rule The model must be approved by a relevant forum

Level 2: Reuse


MUST MUST SHOULD MAY SHOULD MAY

Rationale An important element in the creation of a coherent public business is the business clarification that, among other things, consists of individual organizations identifying which business objects they, by virtue of legislation or agreement, have the specification responsibility for. The clarification thus implies a 'drawing of boundaries' between individual concept- and core-models where each field or business takes ownership of the business objects within its area of responsibility. At the same time, the business waives specification responsibility for all other objects - but, of course, can still use them to contextualize, expand and qualify its modelling. Implications In relation to the relevant professional field, which the concept model describes, a relevant forum with decision-making competence and knowledge of the field must be identified and these stakeholders must be in the process of an approval process. The rule is fulfilled by specifying the model's business approval status using the model attribute 'approval status':

Name: approval status

Definition: status indicating whether a model is accepted and declared valid in a - for the business area - relevant forum

Value space:

Not relevant: Status indicating that a model is not currently undergoing an approval process

Awaiting Approval: Status indicating that a model is awaiting an approval process Approved with remarks: Status indicating that a model has been accepted and

declared valid but that comments have been highlighted relevant to the approval Approved: Status indicating that a model is accepted and declared applicable

Source: plus: hasApprovalStatus

Concept lists: Fill in 'Approval Status '' in accordance with Appendix E UML models: Fill in the 'approvalStatus' tag on the model package

Examples

In concept list: 'approval status' = awaiting approval In core model: 'approvalStatus' = awaiting approval


23

12 State the status of the model

Rule It must be stated which status the model has in terms of how complete and finished and thus applicable the model is.




Rationale In order for the users of a given model to be able to assure themselves of the potential application and relevance of a model, it should be possible to be able to obtain statements about the model's status. Implications This rule is met by stating the status of the using the model property 'model status':

Name: model status

Definition: status indicating the validity of the model in terms of how complete and finished, and thus applicable the model is

Value space:

development: Model status indicating that the model has a preliminary and incomplete design

testing: model status indicating that the model is essentially complete and in use but minor changes may occur

stable: model status indicating that the model is complete, stable and in use obsolete: model status indicating that the model was previously valid but that it

has been replaced by another model or become redundant

Source: http://www.w3.org/ns/adms#status (adms: status) "Status for aktiviteten i forbindelse med en bestemt arbejdsgangsproces"

Concept lists: Fill out the 'model status' information in accordance with Appendix E. UML models:

o (Level 1 - Communication): Specify 'Model Status’ on the model diagram o (Level 2 - Reuse): Fill in the 'modelStatus' tag on the model package

Examples

In concept list: 'model status' = development In core model: 'modelStatus' = development


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/ns/adms&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhjmHuDydJi5tWCTZ8QApUcDIjcEUw#status

24

13 Document the link between the legal basis and the concept model

Rule The correlation between legal basis and concept models must be documented by providing references to legal basis and standards in the field.

Level 2: Reuse



Rationale By visualizing and documenting the connection between legal basis and business concept models, legal and organizational interoperability is promoted. Implications The legal framework around the model must be described at the level of the model.

This rule is met by specifying references to laws and regulations with the model 'legal source' feature - possibly by a textual description of the relevant legal texts for the field or by URI referencing the European legislation identifier (ELI) identifiers presented at Retsinformation.dk ( https://www.retsinformation.dk/eli/dan )

Name: legal source

Definition: Reference to the legal basis that forms the basis for the model

Value space: Overall textual description of the legal framework or indication of ELI URI references

Source: (Plus: Legal source) "A related legal resource from which the described resource is derived"

Concept lists: Fill in 'legal source' for the model according to Appendix E UML models: Fill in the 'legalSource' tag on the package


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=https://www.retsinformation.dk/eli/dan&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhiKQMmGIUvxO5K9aklNDFPgrSIZew

25

14 Document the link between concept models and core models

Rule A business-owned core model must use concepts defined by a concept model. A business-owned core model must identify which concept model or external core model it is based on. Note that by 'business-owned core model' is meant the core model that a given business area has produced according to the Rules for Concept and Data Modelling.

Level 2: Reuse


- - MUST - MUST -

Rationale By ensuring coherence between concept models and core models that exist at different abstraction levels, legal, organizational and semantic interoperability is provided. Core models are a continuation of business modelling into logical modelling, so by linking the core model and its elements into a concept model, the connection from business to data modelling is ensured. Implications The implications of this rule are twofold.

1) The terms and definitions of the concept model are passed on to the core model. That is, the concept model that subject matter experts contribute knowledge to, must form the basis for the data modeller's creation of one or more core models. The core model must implement the terminology and semantics contained in the concept model by allowing classes, association ends and attributes to realize the concept model content:

Concepts are transformed into classes, objects, attributes, and association ends Relationships are transformed into generalizations and associations

26

2) Secondly, the core model must have metadata added about which concept model is the basis for creating the core model. This part of the implication is met by stating the model's basis using the model property 'was derived from':

Name: was derived from

Definition: relationship that indicates that an entity has formed the basis for creating a new entity.

Value space: reference in the form of a HTTP-URI

Source: http://www.w3.org/ns/prov#wasDerivedFrom (sample: wasDerivedFrom) A derivation is a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-existing entity

UML models: Fill in the tag 'wasDerivedFrom' on the model's package

Examples

The example below shows how the term 'wind power plant' from a concept list in ISO format is transformed into a class in a core model:

The example below shows how for a while, in a core model, what concept model it is based on

In core model: 'wasDerivedFrom' = http://data.gov.dk/ns/cm/energysupplyfacility


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/ns/prov&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhjJEIFuvNbLqPAd1VeYWpcwiuTy8A#wasDerivedFromhttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://data.gov.dk/ns/cm/energysupplyfacility&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhj4xP6Tf_to4zerso7YBnFBLni9QA

27

Common to Model Elements

The model elements that are created according to the model rules must have information that makes it possible for both humans and machines to reuse and interpret them. Therefore, a number of rules for naming elements and composing definitions and descriptions are provided so that the elements become comprehensible to subject matter experts, modellers and IT developers alike. Other rules govern for how elements can be identified uniquely across models and systems in such a way that machines (computers) can interpret and use them and the information they contain.

Reuse is also relevant for all items and all models. Therefore, rules for reuse and for how the history or provenance of the individual elements is to be conveyed are provided as well.

In order to ensure that the good models that are created apply as widely as possible, use of English will be required. This is also incorporated into the rules.

28

15 State meaningful UML names for model elements

Rule The names of model elements should facilitate reuse. Model elements must be labelled reflecting the terminology used in the field.




Rationale It is practical that the elements of the model are given meaningful terms as it is the intention that the model should be read, used and reused by others. In other words, even though one could in principle denote an element with a name that is not meaningful, e.g. KA00045, one should choose a term that reflects the most precise term that designates the concept that the element is supposed to represent, e.g. 'Wind power plant' [General 2008: 310]. Implications Model elements, including classes, associations, association ends and attributes must be given UML names that reflect applied terminology in the field. Examples

Building Case Number is a better attribute name than Case001 (relative to building cases) National church membership is a better class name than National church (relative to persons) Personal information protection is a better class name than Protection (relative to persons) Beach protection area is a better class name than Beach protection (relative to land)


29

16 Assign all model elements an identifier

Rule All model elements must have a fully qualified HTTP-URI as an identifier.

Level 2: Reuse


MAY SHOULD MUST MUST MUST MUST

Rationale Traceability of model elements, from concept model to technical implementation, requires unambiguous identification of the elements.

A means of ensuring coherence between models and between data is to use unique, unambiguous identifiers. W3C recommends using HTTP-URI, cf. https://www.w3.org/TR/dwbp/#DataIdentifiers (W3C 2017).

HTTP-URI function as both as a unambiguous identifier (~ unambiguous name) and potentially as unambiguous URL (~ unambiguous address), making it suitable both for unambiguously identifying elements and for subsequently finding further information about the element.

Implications Identifiers are formed by forming a fully qualified HTTP-URI as a combination of:

The HTTP-URI that identifies the model, the element belongs to. The model's HTTP-URI, ending with the fragment identifier, acts as the namespace of the item.

Fragment Name. In order to obtain internationally understandable HTTP-URIs, all fragment names must be in English.

Name: URI

Definition: Unique identification of a resource, (a class, an individual, a property or a value / literal)

Value space: HTTP-URI

Source: https://www.w3.org/TR/ld-glossary/#uniform-resource-identifier

Note that the UML element Generalization, as the only UML element, is not to be provided with this tag.

Examples

Model package for the energy supply system model has URI: http://data.gov.dk/ns/energysupplyfacility#

The fragment name of the element (one class) is: EnergySupplyFacility As a combination of these two, the full HTTP-URI is formed for the item:

http://data.gov.dk/ns/energysupplyfacility#EnergySupplyFacility

This rule is automatically met by the MDG-technology

https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=https://www.w3.org/TR/dwbp/&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgUG1Pntyp82J8oG2LML-Ya1QYYqw#DataIdentifiershttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=https://www.w3.org/TR/ld-glossary/&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgR05HiJ_voiwgv0F-M6AS7zhi1bg#uniform-resource-identifierhttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://data.gov.dk/ns/energysupplyfacility&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgmp677t9VWVaqszfbJ9-pI3s_c-whttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://data.gov.dk/ns/energysupplyfacility&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgmp677t9VWVaqszfbJ9-pI3s_c-w#EnergySupplyFacility

30

17 Generate element names that are qualified names based on the HTTP-URI of the element

Rule Then element names as qualified names based on the item's HTTP-URI.

Level 3: Coherence


- MAY SHOULD SHOULD MUST MUST

Rationale

A qualified name, or QName, is a shortened version of an HTTP-URI, where the namespace part has been

replaced by the preferred prefix. This ensures a more legible identification while endeavouring to preserve

uniqueness. Using QNames as names of the model elements facilitates reading the model and achieving an

overview of which elements are defined within the model’s own namespace and which are defined in other

namespaces.

Implications

Names of model elements are listed as QNames.

Examples


31

18 State terms in common language

Rule

Model elements must be provided with terms in a common language.

Level 2: Reuse



Rationale

Providing model elements with terms in common language reflects the terminology of the business area,

thus facilitating the search and reuse of model elements. In addition, it supports Section 2 of the Act on

Danish orthography stipulates that Danish standard orthography must be followed by all sections of public

administration.

Implications

The terms, as they are naturally used in the business area, must be recorded. Term in this context is to be

understood as a linguistic expression or name that designates a concept and thus has a specific meaning

within the technical terminology of the field.

As a minimum, the preferred term must be recorded, but if a term can be expressed by several synonymous accepted or deprecated terms, it is recommended that these are also recorded, even if it is not a requirement.

Terms are recorded using the element attributes' preferred term ', ‘accepted term' and 'deprecated term'.

Name: preferred term (prefLabel)

Definition: term considered to be the best of several synonymous expressions for a given term

Value space: text

Source: http://www.w3.org/2004/02/skos/core#prefLabel (skos: prefLabel)

Name: accepted term (altLabel)

Definition: term whose use is accepted but not preferred

Value space: text

Source: http://www.w3.org/2004/02/skos/core#altLabel (skos: altLabel)

Name: deprecated term (deprecatedLabel)

Definition: term that should not be used because it is undesirable, wrong or outdated

Value space: text

https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/2004/02/skos/core&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgR8QuWF__7t9VaRDZU4CfsJMyB9g#prefLabelhttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/2004/02/skos/core&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgR8QuWF__7t9VaRDZU4CfsJMyB9g#altLabel

32

Source: (Plus: deprecatedLabel)

Each of these three properties is available in at least two versions, one for Danish terms and one for English. For example, prefLabel (da) and prefLabel (en). The ISO standard for language codes [ISO 639-1] is used to designate the language. The term is recorded as the term occurs in the business area and must follow the language and spelling of the language in question.

Concept lists: Fill in the 'preferred term' and possibly 'accepted term' and 'deprecated term' in accordance with Appendix E. Terms, as used normally in the business area, must be recorded in the concept list. In the concept list, the preferred term will function as the entry point to the concept in question. If accepted and deprecated terms exist, please record these separately afterwards.

UML models: Fill in the tag 'prefLabel' and possibly 'altLabel' and 'deprecatedLabel' on the model element with terms as they are normally used in the business area. Models expressed in UML meet this rule when model elements in addition to their UML names are provided with labels implemented by the tag values that document the model in a natural language. Add as many labels to an item as necessary. When adding these labels, standardized name conventions should be followed, see Rule 'Use Standardized Name Conventions'. That labels are used to document core models in a natural language is also suggested by Tim Berners-Lee [Gómez-Pérez 2011: 113] and recommended by W3C [W3C 2014e]. The general tag label may be used if it has not been decided which term is preferred.

Examples

In core model elements:


33

19 State equivalent terms in English

Rule

Model elements are provided with equivalent terms in English for Danish-language terms.

Level 3: Coherence


SHOULD SHOULD SHOULD MAY MUST MAY

Rationale

Providing a model element with an equivalent English term prepares the element to be included in an

international context, and makes mapping against other international models possible.

Implications

English equivalent terms are stated and given the relevant language code for all model elements.

Concept lists: Equivalent English terms are listed in the concept list in accordance with the chosen format, i.e. in table format or according to the ISO standard. See Appendix D Example Models.

UML Models: Equivalent terms in English are recorded as labels in the form of a the tag value with indication of language [W3C 2014e]. The speech reproduction must be recorded as an addition in parenthesis to the relevant tag, e.g. prefLabel (en). See also rule State terms in common language.

Examples

Example recording equivalent terms in other languages in the concept list (here ISO format):

Example recording equivalent terms in other languages in the vocabulary:


34

20 Use standardized naming conventions

Rule The model and the elements it consists of must be provided with UML names and terms according to standardized naming conventions and best practices.

Level 2: Reuse



Rationale The naming of model elements should facilitate reuse. A consistent naming convention gives the model a consistent expression and makes it easier to identify and distinguish the different elements from each other. Implications

General Implications

Use a commonly used character set (Unicode) Use nouns in the singular form for concepts / classes cf. [General 2008: 311] and [Ambler 2005: 51] Use verb phrases in present tense for associations in concept models cf. [European Commission ISA

2011: 35]

Concept Models

Terms and relationship names are recorded with a lower case initial letter cf. [ISO 704] Terms and relationship names are recorded in accordance with current accepted spelling Use spaces to separate words Name classes and associations in a natural language (only concept diagrams)

Logical models

Regarding UML model elements: see [General 2008: 311] and [European Commission ISA 2011: 35]

Name classes and objects with "UpperCamelCase" - i.e. with an upper case initial letter in both the first word and all subsequent words in the name and without the use of spaces in the name.

Name association ends and attributes with "lowerCamelCase"

Regarding terms that are recorded, see rule 'Specifying terms in common language':

Enter terms and relationships with lower case initial letter [ISO 704] Enter terms and relationships according to current punctuation Use spaces to separate words

35

Examples

UML Class Name : WindPowerPlant, NamedRoad, UML Association Name : identifiedBy Term: prefLabel (da): wind power plant, term (on a relationship): prefLabel (da): identified by


36

21 Compose definitions or descriptions of the model elements

Rule The meaning of the model elements must be described fully in easy-to-understand Danish.




Rationale In order to ensure that elements used in a model are understood in the same way in all applications, it is necessary to explain the meaning in a comprehensive description. This is the basis for a broad application and for minimizing misinterpretations. Implications The rule is fulfilled by associating a description or definition in Danish with all model elements. Additional comments or information may be added as a comment, and additionally, examples may be given.

The element properties 'definition', 'comment' and 'example' should be used:

Name: definition

Definition: description of the meaning of a concept (7)

Value space: text

Source: http://www.w3.org/2004/02/skos/core#definition (skos: definition) "a statement or formal explanation of the meaning of a concept"

Name: comment

Definition: additional comment or information about the concept

Value space:

text

Source: http://www.w3.org/2000/01/rdf-schema#comment (rdfs: comment) "an instance of rdf: Property that may be used to provide a human-readable description of a resource"

Name: example

Definition: typical occurrence given in order to explain or illustrate

Value space: text

Source: http://www.w3.org/2004/02/skos/core#example (skos: example) "supplies an example of the use of a concept"

Concept lists Fill out 'definition' and possibly 'comment' and 'example' according to Appendix E UML models :

o (1st level - Communication): Enter 'definition' and possibly 'comment' and 'example' for each model element

https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/2004/02/skos/core&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgR8QuWF__7t9VaRDZU4CfsJMyB9g#definitionhttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/2000/01/rdf-schema&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhiz66mn0UURkGvVTO0A8vTvPE4tIw#commenthttps://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=http://www.w3.org/2004/02/skos/core&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhgR8QuWF__7t9VaRDZU4CfsJMyB9g#example

37

o (2nd level - Reuse): Fill in the tag 'definition' and possibly 'comment' and 'example' on the model element

In application models that reuse core model elements, these already have a definition that cannot be changed or adjusted. However, if needed, supplement a 'usage note' on how the item should be understood precisely in a particular dataset or in the IT system in which it will be used.

Name: application note

Definition: Note describing how a vocabulary element should be used and understood in a particular context

Value space: text

Source: plus: application note "note which describes how a vocabulary element should be applied and comprehended in a specific application context"

Application Models: Specify 'Application Note / Application Note' on the Model Element if needed Application profiles: Fill in the 'applicationNote' tag on the model element if needed

(7) Note that 'definition' is used to record both descriptions and actual definitions, which describe the meaning of a concept in a way that clearly delineates it from other concepts.

Examples

In concept list: 'definition' = power plant that converts wind energy into electricity In the core model: 'definition (da)' = power plant that converts wind energy into electricity


https://translate.googleusercontent.com/translate_c?depth=1&hl=da&rurl=translate.google.com&sl=da&sp=nmt4&tl=en&u=https://arkitektur.digst.dk/metoder/regler-begrebs-og-datamodellering/faellesoffentlige-regler-begrebs-og-datamodellering-18&xid=25657,15700022,15700043,15700124,15700149,15700168,15700186,15700189,15700190,15700201,15700205&usg=ALkJrhj-ABebmy9Z5nqKEqNOQAseyLACfA

38

22 Compose structured definitions in a standardized way

Rule Definitions of elements should be structured in a standardized way. Definitions should be formulated as intensional definitions, stating the genus (the nearest superordinate concept) and differentia (properties that differentiate the concept from other members of the genus). The definition should describe the meaning of a concept in a way that clearly delineates it from other concepts.

Level 2: Reuse


SHOULD SHOULD SHOULD - SHOULD -

Rationale By defining intesional definitions, you get short, clear and correct definitions that unambiguously and robustly convey the meaning of a concept, and, equally important, you avoid a number of inappropriate characteristics of other definition types (see examples of other definition types in the 'examples' section below) Implications In short, one must aim at defining a term by indicating the genus and the differentia, i.e. state "what kind" the concept and what characterizes this specific kind of thing in relation to other concepts within the same genus.

When defining elements, you must express yourself as briefly, clearly and accurately as possible. Cf. guidelines for defining definitions in accordance with applicable standards and best practices in the field [ISO 704, ISO 1087, Madsen 2007].

Examples

Good: wind power plant : power plant that converts wind energy to electricity (intensional definition where the superordinate concept "power plant" and the properties that differentiates a wind turbine relative to other power plants, namely that it "transforms wind energy into electricity")

Poor: wind power plant : Wind turbine (Definition by synonym – gives no further explanation) Poor: wind power plant: e.g. wind turbines, wind farms in rural areas (Definition by extension

(listing of subordinate concepts - have all been included and what is the meaning of these?) Poor: wind power plant: Power plants that do not convert chemical, electrical, heat, nuclear,

location or radiation energy (Negative definition as the term is defined by what it is "not"). Poor: wind power plant: consists of towers, hubs and wings (definition by components - have all

parts been included?)


39

23 Compose application neutral definitions

Rule The model elements must have application neutral definitions, so that they may also be used in other contexts. Definitions must be technically sound and generally applicable.

Level 2: Reuse


MUST MUST MUST - MUST -

Rationale Letting the usage context limit the meaning of the definition carries the risk of preventing reuse or of causing the element to be used inappropriately other models. Implications The definition must not contain elements that express an inappropriate limitation of the concept by, for example, describing technological, organizational or political dependencies. Additional context-related comments or examples should not be included in the definition as this information may not be relevant to the definition and may be prevent broad application of the concept. Examples

Good: wind power plant : power plant that converts wind energy to electricity Poor: date of filing: The date a case is created in the agency's case management system (limiting

the case management system to a particular organizational unit ('the agency') reduces the potential for reuse).

Poor: date of creation: Date expressed as YYYY-MM-DD (by limiting the technical format, the reuse potential is reduced).

Poor: tourist attraction: building structure of interest to tourists (by mentioning building structure as a superordinate concept, sights not constituted by this type of structure are excluded).


40

24 Compose English definitions

Rule

Model elements should be given definitions in English.

Level 3: Coherence


SHOULD SHOULD SHOULD MAY MUST MAY

Rationale

Providing a model element with an English definition prepares the element to be included international

contexts, and makes mapping against other international models possible. If English definitions (and English

terms according to 6.3.23) are given to model elements, it will be possible for international modellers to

interpret and reuse Danish models and thereby promote international interoperability.

Implications

Concept lists: English definitions are given in the concept list in accordance with the chosen format, i.e. in table format or according to the ISO standard. See Appendix D: Example Models

Concept models, core models, vocabularies: The English definition is recorded as a the tag value indicating language [W3C 2014e]. The language code must be recorded in a parenthesis added to the name of the tag 'definition', which is contained in the Plus-profile stereotypes 'ConceptModel', 'CoreModel' and 'ApplicationModel'

Application model, application profile: Met by uniquely identifying the vocabulary element used by the application profile (cf. rule Document the link between elements in core models and application models).

Examples

Example of giving definitions in other languages in the concept list (in this case ISO format):


41

25 Document the link between the legal basis and the model elements

Rule The link between the legal basis and the model elements must be documented by providing references to legal basis and standards within the field at the element level.

Level 2: Reuse



Rationale By visualizing and documenting the link between the legal basis and the model elements, legal and organizational interoperability is improved. When modelling, whenever possible, concepts with a legal basis should be used. Similarly, in the legislative work, concepts defined in concept models and vocabularies should be used. Implications Terms and definitions of concepts included in concept models should, whenever possible, be obtained from applicable legislation in the field, and the source of concept should be referenced. It is recommended that legislation be based on documented, accepted and non-redundant terms - corresponding to a concept model that promotes reuse.

Sources should be selected in the following prioritised order:

1. Laws and executive orders 2. National and international standards 3. Other sources

The rule is fulfilled by specifying references to laws and notices with the property 'legal source' and references to national and international standards and other sources with the 'source' property.

Name: legal source

Definition: reference to the legal basis from which the term is derived

42

Value space:

Expressed at elemental level as reference to legal text for the most precise reference to the term in question in a given law (for example, by providing ELI URI (European legislation identifier) reference which is presented at Retsinformation.dk ( https://www.retsinformation.dk / eli / dan )

Source: (Plus: Legal source) "A related legal resource from which the described resource is derived"

Name: source

Definition: Reference to resource from which the term is derived

Value space: Expressed at element level ideally with an URI, but may also be the source name

Source: http://purl.org/dc/terms/source (dcterms: source) "A related resource from which the described resource is derived"

Concept lists : Fill in 'legal source' and 'source' at the concept level according to Appendix E UML Models: Fill in the 'legal source' and 'source' tag on the model element

Examples

In concept list: 'legal source' = http://www.retsinformation.dk/eli/lta/2015/1736 In concept list: 'source' = http://www.electropedia.org (IEC 60050-415-01-02) In the core model: 'legalSource' = http://www.retsinformation.dk/eli/lta/2015/1736 In core model: 'source' = http://www.electropedia.org (IEC 60050-415-01-02)


https://translate.goog

rules for concept and data modelling · the model rules contribute to better data and increased...

Documents