A lap jelenlegi, 2025. május 26., 14:21-kori változata

This discussion page helps to interpret what should be done in a particular chapter and why...
Final product: https://miau.my-x.hu/mediawiki/index.php/CT_00
History of the final product: https://miau.my-x.hu/mediawiki/index.php?title=CT_00&action=history
History of the discussion page: https://miau.my-x.hu/mediawiki/index.php?title=Vita:CT_00&action=history

Recommended rules waiting for being integrated: https://miau.my-x.hu/temp/2025tavasz/rules/
Experimental interpretations (c.f. KNUTH: https://miau.my-x.hu/miau2009/index_tki.php3?_filterText0=*knuth) concerning automation challenges: 
https://miau.my-x.hu/miau/323/robot_lektor/

Worth knowing: https://miau.my-x.hu/mediawiki/index.php/BPROF_Thesis_Structure
+ https://miau.my-x.hu/mediawiki/index.php/BPROF:zarovizsga

Recommended literature: https://www.facebook.com/groups/263175136143745/permalink/725750149886239/?rdid=KQzoaiQuSkaMLEzd#

Title

Optimization challenge: the better is a title the more is the number of keywords but the less is the length of the text

When breaking a title into multiple lines with a line break, it is expected that words representing a single thought unit should be included in one line.

CORRECT:

• When breaking a title into multiple lines with a line break,
• it is expected that words representing a single thought unit should be included in one line.

INCORRECT:

• When breaking a title into multiple lines with a line break, it is
• expected that words representing a single thought unit should be included in one line.

Subtitle

(a new aspect can be visualized based on the same principle as before in case of the title)

Authors

names (https://orcid.org/...),

Institutions

expected cover-sheet-elements incl. university, department, etc.

Abstract

One-pager-like chapter for conferences (c.f. IKSAD/Türkiye: https://miau.my-x.hu/miau2009/index_en.php3?x=e080). The abstract is not the summary, where citations might quasi only be listed about the most relevant statements of the publication. The abstract should deliver a kind of motivating information package - quasi without any citations: e.g. history of the project, descriptive core information about the problem, own steps and their results, future - maximal one single page.

Chapter#1. Introduction

Between to chapters (e.g. 1. and 1.1.), it is necessary to have explaining texts - mostly about a kind of detailed/specific table of content with argumentations...

Chapter#1.1. Aims/objectives

A final thesis (a publication in general) might not formulate more aims than being really covered through the publication. In order to avoide the suspicions about potential realistic, but not realized aims/objectives, each promise should have a "CHAPTER#..."-sign, where the Readers will be capable of checking the real performaces behind each promise - immediately. These chapter#-signs can be empty, if the whole structure (table of content) is still fluid. But each empty sing should be filled with the appropriate numbers, if the details behind a promise could be formulated as a finally existing subchapter (mostly in chapter#3 - own development).

The aims may only be listed, if the basic definitions are given. The keywords of the (sub)title and each further relevant term should always and immediately be defined after the first using.

It is not forbidden to work with arbitrary high complexity. In this case: the Readers have to understand the XLSX-files before going on...

Important and general rule: if a plural form is used, then it is necessary to present examples: e.g. philosophycal challenges (e.g. automation, nature/level of vierification), or arbitrary systems (c.f. encryption/decryption tasks for unknown-cyphers) or relevant keywords ... (c.f. concepts, verification, partial log-data) or different steps (task1, task2, task3, task4:interpretation of the hidden file), etc. Examples for plural terms can be formatted as numbered lists or list with bullet point or even with parentheses: (e.g., 1. Example 1, 2. Example 2). (c.f. https://miau.my-x.hu/temp/2025tavasz/ct2/suggestion_frame_for_change_tracking3.docx)

Recommended literature about keyhole-challenges: https://miau.my-x.hu/myx-free/index_en.php3?x=fbl, https://miau.my-x.hu/myx-free/index_en.php3?x=iq

Chapter#1.2. Tasks

Rules: The list of the particular tasks should deliver a clear classification of steps without any overlapping effects and/or without any lacks. BTW: this expectation is valid for each lists in general. Tasks are also promises (as aims/objectives), therefore, it is also necessary to have a chapter#-sign for each task. Tasks are decisions of the Author(s), therefore, it is necessary to deliver argumentations for the rationality of these decisions.

Chapter#1.3. Targeted groups

Rules: each potential targeted groups should be listed (see without overlapping and lacks) - and the argumentations must be given: why is a listed element rational? Targeted groups are potential customers, who should be capable of paying for the results of this project based on a real information added-value estimated by the Authors themselfes.

Chapter#1.4. Utilities (estimation of informational added-values)

Rules: For each targeted group should be made an as far as exact estimation in USD or EUR about the information added-value. It is expected, that the estimations are positive values! Negative values means: parasitism through the IT-experts concerning their customers! Estimations have two layers: incomes and costs in the bechmark situation AND incomes and costs based on the results of the projects.

Chapter#1.5. Motivation

Quasi arbitrary argumentation (in dependence with targeted groups AND informational added-values)...

Chapter#1.6. About the structure of the publication

In this subchapter, it is necessary to write about ALL aspects which will only be mentioned but without deep details.

In this subchapter, it is also necessary to clarify ALL the used formats.

In this subchapter, the structure of the publication must be defined in advance.

In personalized cases, such as student assignments or context-specific case studies, examples must be listed in bullet point format to ensure clarity and flexibility for descriptive, non-sequential items. For example:

• Concept A: Energy efficiency analysis based on e-car log data.
• Concept B: IT-security evaluation for educational platforms. To ensure consistency across Vita:CT_00 and CT_00, the following additional formatting guidelines apply:
• Numbered lists (1., 2., etc.) must be used for sequential or prioritized examples, such as structured analyses in CT_00.
• Lettered listings (a), (b), etc., should be avoided unless referring to pre-defined categories labeled with letters.
• Use bold for key terms or section headers, and italics for emphasis (e.g., cautionary notes or highlights). Avoid underlines unless required (e.g., for links).
• All formatting choices must be applied consistently throughout the article to enhance readability and avoid confusion. These rules complement CT_00’s formatting guidelines (see CT_00, Chapter#1.6), ensuring alignment between formal and discussion content. (c.f. https://miau.my-x.hu/temp/2025tavasz/ct2/suggestion_frame_for_change_tracking2.docx)

Recommendation Font and Size: For readability and professionalism, especially if exported to a Word document or PDF, the following are recommended:

• Font: Use a clean, professional font such as Times New Roman, Arial, or Calibri. Calibri is modern and widely accepted in academic and professional settings.
• Font Size: Use 12-point font for body text and 14-point for headings to ensure readability. Subheadings can use 12-point bold to differentiate from body text.
• Line Spacing: Use 1.15 or 1.5 line spacing to improve readability, but never use blank lines, double spaces, tabulators, etc. - it means the old "type-writer-solutions"...
• Justification: Use justified text alignment for a polished look, ensuring consistent spacing. (c.f. https://miau.my-x.hu/temp/2025tavasz/ct2/suggestion_frame_for_change_tracking4.docx)

Chapter#2. Literature

Between two chapter-titles, it is necessary to have explanations about the structure of the particular subchapters.

This chapter is dedicated for all definitions, which are necessary to understand the own development, results. It is forbidden to have subchapters without any citation(s). Here, it is important to use citations with sources. Between two citations, it is expected, that the Author(s) deliver(s) argumentations about each citation: is a citation is to integrated or even to avoid? More precisely: each citation should be evaluated by the Author(s): either in a positive way (the particural statement of the citation will be integrated: chapter#... or in a negative way: the particural statement of the citation is to avoide).

Rule: Consistent Use of Parenthetical Citations for Sources

Description: All citations in the text must use the footnote-section OR the parenthetical format (e.g., (Source: https://example.com)) immediately following the cited information, including a brief source description and URL where applicable.

Rationale: The wiki-based document here and now uses parenthetical citations (e.g., “Source: https://en.wikipedia.org/wiki/Software_testing” in Chapter#2.1), but Vita:CT_00 for the time being still lacks a formal rule standardizing this format (because this is the task of Students who are writing the own rules for themselves). A consistent citation style improves readability and verifiability, similar to how bullet points standardize example presentation. The subchapter about the list of references must follow one of the so called standardr formats: https://pitt.libguides.com/citationhelp (c.f. https://miau.my-x.hu/temp/2025tavasz/ct2/suggestion_frame_for_change_tracking7.docx)

Chapter#2.1. ...

Chapter#2.2. ...

Chapter#2.3. ...

Chapter#2.4. ...

Chapter#2.5. ...

Chapter#2.6. ...

Chapter#2.7. ...

Chapter#3. Own developments

The presentation of the own developments, experiments, idea, etc. must strict use the keywords inroduced (mostly based on citations, but also in form of own interpretation to the definition in the literature in chapter#2.

Application of Category Types in Real-Life Projects: This main chapter bridges theory and practice by illustrating how category types (e.g., KPIs, testing frameworks) are applied in case studies (e.g., e-car log analysis, student projects). Include: Step-by-step workflows (e.g., task1 → task4 from Chapter 1.2 - incl. subtasks!) / Automation scripts (e.g., COCO Y0 for concept testing) / Student assignments / etc.

The main chapter about the own developments illustrates how category types are applied in real-life projects, including case studies from student assignments adapting industry examples being describe in chapter#2. Each example will highlight the decision-making process and outcomes (c.f. reproducibility - https://miau.my-x.hu/temp/2025tavasz/ct2/suggestion_frame_for_change_tracking8.docx)

Chapter#4. Discussions

The chapter "discussions" should present a kind of self-critical interpretation of the publication.

Chapter#5. Conclusions

The chapter "conclusions" should present a kind of negotiation concerning the previous self-critical interpretation of the publication.

Chapter#6. Future

Chapter#7. Summary

Chapter#8. Annexes

Chapter#.8.1. Abbreviations

Chapter#.8.2. Figures

Each publication must consist at least one figure from the literature and at least one own figure.

It is required to include full bibliographic data and licensing details for all image sources, especially those taken from external literature, to ensure proper attribution and maintain academic integrity. Visual elements such as charts and tables should be designed for maximum readability and clarity (incl. units). Each visual aid must include: A clear caption describing its content, Visible and labeled axes, columns, or rows, readable text and elements (e.g., font size, colors, line thickness), and proper spacing and contrast to ensure all data is distinguishable. (c.f. https://miau.my-x.hu/temp/2025tavasz/ct2/suggestion_frame_for_change_tracking.docx)

Every figure must include:

• Number/Tag: "Figure X:" (sequential numbering) - and this number should be mentioned at least one single time in the main text, where the explanations (e.g. vertical/horizontal, left/right interpretations, arrows and their directions, colours, shapes, etc.) are.
• Descriptive Title: Clearly state the figure’s purpose (e.g., "Flow Chart of Risk Assessment").
• Source:
  • Author-generated: "Source: Author’s own work, 2025."
  • AI-assisted: "Source: ChatGPT-4 simulation; validated via Excel."
  • External: "Source: [MIAU_XLSX_URL]."
  • Validation Note: Briefly explain verification (e.g., "Data confirmed via COCO Y0 analysis in Section 3.1.6").

(c.f. https://miau.my-x.hu/temp/2025tavasz/ct2/suggestion_frame_for_change_tracking6.docx)

Chapter#.8.3. References

https://miau.my-x.hu/mediawiki/index.php/BPROF_Thesis_Structure / https://miau.my-x.hu/bprof/Deepl%20-%20Thesis%20specialities%20of%20the%20BPROF%20training%20at%20the%20KJE.docx / https://miau.my-x.hu/temp/2025tavasz/?C=M;O=D

Chapter#.8.4. Conversations with LLMs

Each publication must have at least one chapter, where relevant information units come from ChatGPT/Copilot (e.g. potential keywords, definitions, etc.). The entire conversations (prompts+ouputs) must be presented in the annex and the used details (citation) must be evaluated mostly in chapter#2.