Artefact generation

[skodapetr]

Quote from https://semiceu.github.io/style-guide/public-review/arhitectural-clarifications.html

Relations between the artefacts are depicted in the figure above. 
The conceptual model is the source from which a) the data shapes, 
b) the formal ontology and c) the data specification document can 
be generated.

This may not necessarily be true, as the Conceptual model would not contain enough default to generate technical artefacts. We already address this issue while modeling using different models: Conceptual, Logical, Physical. As a result I would propose to consider another level bellow the conceptual that could be used as a single source of truth to generate, perhaps even automatically, other artefacts.

Note: It could be that you already consider all the necessary information to be available in the conceptual model. For me the conceptual model capture only the core entities with a little detail.

[csnyulas]

Indeed, the conceptual model (CM), by itself, does not contain ALL the information that would allow the generation of all the technical artefacts. However, we consider that the CM contains all the conceptual and modelling aspects that is needed to generate those artefacts. Besides these aspects, of course, there need to be instructions, configurations (including default values), etc. that would specify how would the CM elements be transformed into the artefacts. This, we consider to be dealt with by a "toolchain", which will do the transformation per se. Discussing how this transformation is done, and what are the further (non-conceptual, but rather more configurational) input specifications that are needed to realize these conversions, is outside of the scope of this Style Guide. We even have a statement regarding this at the end of the section from which you quoted (2-3 paragraphs below it):

The guidelines in this document enable and constrain the transformation process, making it precise enough to implement a toolchain that automatically performs conformance checking and necessary transformation operations. How this is done, however, is beyond the scope of this document, and the reader may refer to SEMIC toolchain [semic] or other similar implementations such as model2owl [model2owl] or OSLO toolchain [oslo-toolchain] projects.

Is this enough context @skodapetr? Should we have a mention of the toolchain earlier in this section, or on this page @costezki ?

[costezki]

Petr, you are right that we need more details to generate the technical artefacts. However, in the conceptual model we have everything we need to generate the semantic artefacts. That is why want to limit the scope of this style guide to the semantic interoperability layer only. We will address in the future the technical layer as well, and of course there we will have to factor in OTHER sources of (technical) information.

See for example:

• https://semiceu.github.io/style-guide/public-review/introduction.html#sec:scope
• https://semiceu.github.io/style-guide/public-review/arhitectural-clarifications.html#sec:technical-concerns-and-artefacts
• https://semiceu.github.io/style-guide/public-review/arhitectural-clarifications.html#sec:separation-of-concerns-in-SEMIC

[skodapetr]

Thank your both for your explanation, it does make sense.

@csnyulas, @costezki Just a small note. The shared links give me 404, is that an issue only on my side?