pyegeria 5.3.9.9.2__py3-none-any.whl → 5.3.9.9.4__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- md_processing/__init__.py +49 -0
- md_processing/commands.json +3252 -0
- md_processing/dr_egeria_inbox/archive/dr_egeria_intro.md +254 -0
- md_processing/dr_egeria_inbox/archive/dr_egeria_intro_more_terms.md +696 -0
- md_processing/dr_egeria_inbox/archive/dr_egeria_intro_part1.md +254 -0
- md_processing/dr_egeria_inbox/archive/dr_egeria_intro_part2.md +298 -0
- md_processing/dr_egeria_inbox/archive/dr_egeria_intro_part3.md +608 -0
- md_processing/dr_egeria_inbox/archive/dr_egeria_intro_part4.md +94 -0
- md_processing/dr_egeria_inbox/archive/freddie_intro.md +284 -0
- md_processing/dr_egeria_inbox/archive/freddie_intro_orig.md +275 -0
- md_processing/dr_egeria_inbox/archive/test-term.md +110 -0
- md_processing/dr_egeria_inbox/cat_test.md +100 -0
- md_processing/dr_egeria_inbox/data_field.md +54 -0
- md_processing/dr_egeria_inbox/data_spec.md +77 -0
- md_processing/dr_egeria_inbox/data_spec_test.md +2406 -0
- md_processing/dr_egeria_inbox/data_test.md +86 -0
- md_processing/dr_egeria_inbox/dr_egeria_intro_categories.md +168 -0
- md_processing/dr_egeria_inbox/dr_egeria_intro_part1.md +280 -0
- md_processing/dr_egeria_inbox/dr_egeria_intro_part2.md +313 -0
- md_processing/dr_egeria_inbox/dr_egeria_intro_part3.md +1073 -0
- md_processing/dr_egeria_inbox/dr_egeria_isc1.md +44 -0
- md_processing/dr_egeria_inbox/glossary_creation_experiment.ipynb +341 -0
- md_processing/dr_egeria_inbox/glossary_test1.md +324 -0
- md_processing/dr_egeria_inbox/rel.md +8 -0
- md_processing/dr_egeria_inbox/sb.md +119 -0
- md_processing/dr_egeria_inbox/search_test.md +39 -0
- md_processing/dr_egeria_inbox/solution-components.md +154 -0
- md_processing/dr_egeria_inbox/solution_blueprints.md +118 -0
- md_processing/dr_egeria_inbox/synonym_test.md +42 -0
- md_processing/dr_egeria_inbox/t1.md +0 -0
- md_processing/dr_egeria_inbox/t2.md +268 -0
- md_processing/dr_egeria_outbox/processed-2025-05-15 19:52-data_test.md +94 -0
- md_processing/dr_egeria_outbox/processed-2025-05-16 07:39-data_test.md +88 -0
- md_processing/dr_egeria_outbox/processed-2025-05-17 16:01-data_field.md +56 -0
- md_processing/dr_egeria_outbox/processed-2025-05-18 15:51-data_test.md +103 -0
- md_processing/dr_egeria_outbox/processed-2025-05-18 16:47-data_test.md +94 -0
- md_processing/dr_egeria_outbox/processed-2025-05-19 07:14-data_test.md +96 -0
- md_processing/dr_egeria_outbox/processed-2025-05-19 07:20-data_test.md +100 -0
- md_processing/dr_egeria_outbox/processed-2025-05-19 07:22-data_test.md +88 -0
- md_processing/md_commands/__init__.py +3 -0
- md_processing/md_commands/blueprint_commands.py +303 -0
- md_processing/md_commands/data_designer_commands.py +1182 -0
- md_processing/md_commands/glossary_commands.py +1144 -0
- md_processing/md_commands/project_commands.py +163 -0
- md_processing/md_processing_utils/__init__.py +4 -0
- md_processing/md_processing_utils/common_md_proc_utils.py +724 -0
- md_processing/md_processing_utils/common_md_utils.py +172 -0
- md_processing/md_processing_utils/extraction_utils.py +486 -0
- md_processing/md_processing_utils/md_processing_constants.py +112 -0
- md_processing/md_processing_utils/message_constants.py +19 -0
- {pyegeria-5.3.9.9.2.dist-info → pyegeria-5.3.9.9.4.dist-info}/METADATA +1 -2
- {pyegeria-5.3.9.9.2.dist-info → pyegeria-5.3.9.9.4.dist-info}/RECORD +55 -5
- {pyegeria-5.3.9.9.2.dist-info → pyegeria-5.3.9.9.4.dist-info}/LICENSE +0 -0
- {pyegeria-5.3.9.9.2.dist-info → pyegeria-5.3.9.9.4.dist-info}/WHEEL +0 -0
- {pyegeria-5.3.9.9.2.dist-info → pyegeria-5.3.9.9.4.dist-info}/entry_points.txt +0 -0
@@ -0,0 +1,254 @@
|
|
1
|
+
|
2
|
+
# Introduction to Dr.Egeria - an Egeria Markdown Processor
|
3
|
+
|
4
|
+
|
5
|
+
A constant challenge in managing information is gathering enough metadata about the information to
|
6
|
+
allow us to manage it. A common approach is to build fancy graphical user interfaces hoping that they
|
7
|
+
will be attractive enough and easy enough to use that people will do so.
|
8
|
+
|
9
|
+
Unfortunately, however, this ignores the fundamental fact that to use one of these nice GUI
|
10
|
+
applications, you have to step away from the tools and processes that you were in the midst of performing.
|
11
|
+
You have to leave your world and enter a new, often less familiar one.
|
12
|
+
|
13
|
+
Dr.Egeria, is an experiment in turning this around. Its not that fancy graphical user
|
14
|
+
interfaces don't have a role - but rather, to look at what we can do to support the
|
15
|
+
tools and approaches people already use. And maybe even make their day job a little
|
16
|
+
easier and a little more enjoyable.
|
17
|
+
|
18
|
+
So this is what we are exploring with Dr.Egeria. An Egeria Markdown language that allows
|
19
|
+
users to intermix requests to Egeria with other text through the use of standard Markdown. The markdown text
|
20
|
+
that we process can be in standard markdown (.md) files, in Jupyter notebooks, and perhaps other file formats.
|
21
|
+
|
22
|
+
This markdown file is an example. You will see that we intersperse normal narrative text (such as this)
|
23
|
+
with Commands to Egeria. We introduce a specific vocabulary to make Egeria requests.
|
24
|
+
|
25
|
+
In the example below we will create a new Egeria glossary to hold definitions related to Dr.Egeria.
|
26
|
+
We will then show how we can process this file which will record the information into Egeria and create a new
|
27
|
+
output file that acts as both a receipt showing what was processed as well as a starting point for making updates.
|
28
|
+
|
29
|
+
So here we go! First lets define a new glossary:
|
30
|
+
|
31
|
+
---
|
32
|
+
|
33
|
+
# Create Glossary
|
34
|
+
|
35
|
+
## Glossary Name
|
36
|
+
|
37
|
+
Egeria-Markdown
|
38
|
+
|
39
|
+
## Language
|
40
|
+
|
41
|
+
English
|
42
|
+
|
43
|
+
## Description
|
44
|
+
|
45
|
+
Glossary to describe the vocabulary of Dr.Egeria - an Egeria Markdown language to support the exchange of metadata in a
|
46
|
+
Markdown form.
|
47
|
+
Dr.Egeria allows users to input metadata using any text entry system that supports the entry of standard Markdown
|
48
|
+
notation and through post-processing
|
49
|
+
commands, validates the Egeria content and allows the requests to be sent to Egeria.
|
50
|
+
|
51
|
+
## Usage
|
52
|
+
|
53
|
+
1. (optional) load an example or template for the type of object from Egeria.
|
54
|
+
2. Create a new document (perhaps from a template) and edit it, adding in the content with the Dr.Egeria controlled Markdown language.
|
55
|
+
3. Process the document to validate and display it before you submit it, Validation may annotate your document with recommendations and potential issues.
|
56
|
+
4. Submit the document to Egeria using the Dr.Egeria commands.
|
57
|
+
|
58
|
+
## <Qualified Name>
|
59
|
+
|
60
|
+
## <GUID>
|
61
|
+
|
62
|
+
---
|
63
|
+
|
64
|
+
|
65
|
+
|
66
|
+
|
67
|
+
# First Walk-Through
|
68
|
+
The block of markdown above is a request to create a new Egeria Glossary called `Egeria-Markdown`. Let's briefly walk
|
69
|
+
through. The command starts when we see `# Create Glossary`. This is a known phrase in Dr.Egeria. When we see this
|
70
|
+
phrase we recognize that this is an Egeria markdown request block. The request block ends if we encounter another `#` or
|
71
|
+
`---`, or run out of text. Within this request block we note some **attributes** that begin with a `## `. The first that
|
72
|
+
we encounter is `## Glossary Name`. Not all attributes need to be filled in. Later, we'll process this file and demonstrate
|
73
|
+
how to tell - but first, lets look at the attributes shown:
|
74
|
+
|
75
|
+
* `## Glossary Name` - this is the display name of the glossary. In this case the name is `Egeria-Markdown` As you can
|
76
|
+
see, the value of the attribute is the plain text that follows it.
|
77
|
+
* `## Language` - what language will the terms of the glossary be in (yes there are ways to have mixed language but
|
78
|
+
Dr.Egeria strives to be as simple as possible).
|
79
|
+
* `## Description` - a description of the glossary and its purpose.
|
80
|
+
* `## Usage` - how the glossary is meant to be used and by whom.
|
81
|
+
* `## <Qualified Name>` - every element in Egeria must have a unique qualified name that we use to distinguish
|
82
|
+
it from all other elements. The qualified name is meant to be understandable by humans, although it may follow
|
83
|
+
formatting conventions. This attributes is in angle brackets because at this point we can't fill it in - we are just
|
84
|
+
in the midst of creating the glossary. A qualified name will be created for us as part of the glossary creation. We'll
|
85
|
+
see a little later how we get that.
|
86
|
+
* `## <GUID>` - same story as qualified name except that this is meant for automation and not people.
|
87
|
+
|
88
|
+
And that's it. That's all we need to do to specify the creation of a new glossary (well - mostly - we'll reveal a few
|
89
|
+
more details a bit later).
|
90
|
+
|
91
|
+
## Great! That was easy!
|
92
|
+
|
93
|
+
We now have a nice, clean, new...and empty...glossary - guess we better start filling it. Lets create a couple of terms.
|
94
|
+
|
95
|
+
---
|
96
|
+
|
97
|
+
# Create Term
|
98
|
+
|
99
|
+
## Term Name
|
100
|
+
|
101
|
+
Command
|
102
|
+
|
103
|
+
## In Glossary
|
104
|
+
|
105
|
+
Glossary:Egeria-Markdown
|
106
|
+
|
107
|
+
|
108
|
+
## Summary
|
109
|
+
|
110
|
+
Commands are how a user of the Freddie markdown language requests an action.
|
111
|
+
|
112
|
+
## Description
|
113
|
+
|
114
|
+
Commands are how a user can request Egeria to take an action such as Create or Update an Egeria element. Freddie
|
115
|
+
provides
|
116
|
+
a limited (but growing) set of commands. Freddie commands align with the pyegeria 'hey-egeria' command line interface.
|
117
|
+
|
118
|
+
## Abbreviation
|
119
|
+
|
120
|
+
## Examples
|
121
|
+
|
122
|
+
Create Glossary or
|
123
|
+
Update Glossary or
|
124
|
+
Create Term or
|
125
|
+
Update Term
|
126
|
+
|
127
|
+
## Usage
|
128
|
+
|
129
|
+
Commands are used in the Freddie Egeria markdown language.
|
130
|
+
|
131
|
+
## Version
|
132
|
+
|
133
|
+
|
134
|
+
|
135
|
+
## Status
|
136
|
+
|
137
|
+
|
138
|
+
## <Qualified Name>
|
139
|
+
|
140
|
+
## <GUID>
|
141
|
+
|
142
|
+
---
|
143
|
+
|
144
|
+
# Create Term
|
145
|
+
|
146
|
+
## In Glossary
|
147
|
+
|
148
|
+
Glossary:Egeria-Markdown
|
149
|
+
|
150
|
+
## Term Name
|
151
|
+
|
152
|
+
Source
|
153
|
+
|
154
|
+
## Summary
|
155
|
+
|
156
|
+
Source of the markdown content.
|
157
|
+
|
158
|
+
## Description
|
159
|
+
|
160
|
+
Source of the markdown content - could be jupter or plain markdown file.
|
161
|
+
|
162
|
+
## Abbreviation
|
163
|
+
|
164
|
+
## Examples
|
165
|
+
|
166
|
+
## Usage
|
167
|
+
|
168
|
+
## Version
|
169
|
+
|
170
|
+
0.1
|
171
|
+
|
172
|
+
## Status
|
173
|
+
|
174
|
+
DRAFT
|
175
|
+
|
176
|
+
|
177
|
+
---
|
178
|
+
|
179
|
+
# Create Term
|
180
|
+
|
181
|
+
## In Glossary
|
182
|
+
|
183
|
+
Glossary:Egeria-Markdown
|
184
|
+
|
185
|
+
## Term Name
|
186
|
+
|
187
|
+
Directive
|
188
|
+
|
189
|
+
## Summary
|
190
|
+
|
191
|
+
A directive defines how the command is to be processed.
|
192
|
+
|
193
|
+
## Description
|
194
|
+
|
195
|
+
Directives are one of:
|
196
|
+
|
197
|
+
* display - just display what we've found
|
198
|
+
* validate - check the validity of the requested action
|
199
|
+
* process - process the requested action
|
200
|
+
|
201
|
+
|
202
|
+
## Version
|
203
|
+
|
204
|
+
0.1
|
205
|
+
|
206
|
+
## Status
|
207
|
+
|
208
|
+
DRAFT
|
209
|
+
|
210
|
+
---
|
211
|
+
|
212
|
+
# Some terms specified - Now what?
|
213
|
+
|
214
|
+
Ok - we've now defined a glossary and three terms to go into the glossary. A few observations.
|
215
|
+
|
216
|
+
* There is a degree of freedom in writing the definitions. The attributes aren't always in the same
|
217
|
+
order and optional attributes don't need to be specified at all. We try to make things as easy as possible to use.
|
218
|
+
* We can run a definition file through a validation process to check our proposed definition and provide feedback.
|
219
|
+
* When we process a definition we will use the same validation process before trying to update Egeria
|
220
|
+
with the requested definitions - requests may get rejected or altered - this will be consistent with the feedback we
|
221
|
+
provide during validation.
|
222
|
+
|
223
|
+
Here is what we'll do next.
|
224
|
+
|
225
|
+
## Next
|
226
|
+
|
227
|
+
>Note: This is changing - so will be somewhat abstrct
|
228
|
+
|
229
|
+
We will run a small program called `dr.egeria.py` to operate on this markdown file. When we run this program we
|
230
|
+
tell it not just the name of the file to process but also provide a directive on what to do. Currently we have the
|
231
|
+
choice of:
|
232
|
+
|
233
|
+
1. Display - just parse the file, breaking it down into request blocks, and display what we find
|
234
|
+
2. Validate - parse the file and validate if the commands can be processed - showing information about what we observe.
|
235
|
+
3. Process - parse the request blocks and execute the commands - and produce a new output file to simplify further processing.
|
236
|
+
|
237
|
+
|
238
|
+
# Great --> let's give it a try!
|
239
|
+
|
240
|
+
Ok - its processed the file and generated output to the console that shows us what it has done.
|
241
|
+
We also now have a new file in the designated outbox (specified by an Environment Variable).
|
242
|
+
If we review that file, we see that it has similar content to this original file except that
|
243
|
+
the **Create** statements have been replaced with **Update** statements and
|
244
|
+
attributes such as **Qualified Naame** and **GUID** now contain the known values.
|
245
|
+
|
246
|
+
This means that if we want to make changes to the definitions that we have
|
247
|
+
created, all we need to do is to make changes to the updatable attributes in this
|
248
|
+
new document and resubmit it - pretty simple.
|
249
|
+
|
250
|
+
In the next section we'll see how we can update and extend what we have done by creating
|
251
|
+
some glossary categories and then assigning categories to the terms.
|
252
|
+
To do this we will copy the output document that we just created and call the
|
253
|
+
copy dr_egeria_intro_part2.md. The text of the document has also been updated
|
254
|
+
to reflect the purpose. Let's open that now!
|