Glossary Improvements

[David OD]

I note that in v8, the Glossary functionality has been extended so that the list of available Types can be expanded beyond the standard Business and Technical.

However we would like to have additional functionality as follows:

• An optional abbreviation field.  If provdied, then context-sensitivity in elements would need to be able to pick up the term or the abbreviation.
• Alternatively, the ability to specify an abbreviation as a separate term, linked to the master definition.  This is less useful, but could be made to work.
• One (or more?) link fields to allow reference to an external URL (or file) which is the source of the definition.  This is necessary to validate/substantiate the definitions.  It can be done in the text, but would be better as a separate field(s).
• One or more cross-references between glossary definitions, such that "see also:" type references can be made between terms.

The rationale behind this is that EA already supports most of what is required in a good enterprise glossary, which is necessary for modelling purposes.  However the additional attributes listed above would allow EA to be the single source of the enterprise repository, avoiding duplication/integration and providing real benefit to people otehr than modelling staff.

[Paolo F Cantoni]

Hi David,

Sounds like you're specifying an Ontological model...  Something which I've long been toying with...

The problem with a Glossary is that it is essentially a linear artifact whereas the relationships between the terms are multi-dimensional.

I've built Ontological models directly in EA and they work quite well.

You can incorporate all your suggestions into them.

What I think we need is to be able to specify the root package of the ontology so that it is know th EA (in the same way as you can specify the Templates package).

EA could them map the term definitions into a structure that would allow it to recognize the terms within the other parts of the model.

My AU$0.05
Paolo

[David OD]

Paolo

Interesting.  I had not considered it that way, although there are many here who might.  However that was not really the intent.  

I am after a fairly flat structure rather than a complex beast.  The problem is, as always, EA provides a great deal of functionality, but not quite enough to stop people essentially duplicating the functionality in order to get that extra 5-10% of value.

If I had to assign priorities to my requests, they would be:

1.  Add an abbreviation field.
2.  Add a (single) URI field for references.
3.  Add the "see also" links. (bonus-type feature).

[Paolo F Cantoni]

[size=18]...[/size]
 The problem is, as always, EA provides a great deal of functionality, but not quite enough to stop people essentially duplicating the functionality in order to get that extra 5-10% of value.
[size=18]...[/size]

True words David (but with my emphasis). In my experience, the additional work can generate much more than 10% more value...

As I've said elsewhere, I've now come to view EA as an "engine" on which you place your modelling environment.

We've basically given up on waiting for Sparx, we just build functionality as we need it.  Now we have some facility with it, it changes the cost-benefit ratio.

Don't forget to submit a formal Feature Request...

Paolo

[Geert Bellekens]

I agree with Paolo,

We also model a "real" Ontology model (or Business Information Model as we call it).
This model stays pretty close to a business glossary, we don't add attributes, no associations etc..
What we do use is define a taxonomy relationship between the different elements ("duck" is a "bird")

These elements are used in a couple of area's in our analysis model
- as input and output of business processes
- in the "usecase communication overview diagram" in which we indicate what type of information we communicate with the world outside of our system
- in our traceability. We create traceability relations between our System Information Entities (the actual classes that usually get persisted) and the Business Information Model.

All of this would not be possible if we used the built-in glossary. Although you might believe now that the glossary fits your requirements keep in mind that those requirements might change if you get involved more in the business modelling side of things. If you then only have the glossary you're kind of stuck.

Geert

[David OD]

I've now come to view EA as an "engine" on which you place your modelling environment.

Yes!  I believe these types of products (and I've played with a couple now) are more than a simple modelling tool, but rather a platform in their own right.

We are already adding functionality in terms of the MDG technologies for our use as well.  However there are some things I would still prefer to see "in the box".  I will get that feature request raised.

[David OD]

We also model a "real" Ontology model (or Business Information Model as we call it).
This model stays pretty close to a business glossary, we don't add attributes, no associations etc..
What we do use is define a taxonomy relationship between the different elements ("duck" is a "bird")

Geert, that sounds interesting, and certainly has applicability for us as well (we work extensively with clinical terminologies).  I would certainly be interested in seeing an example of how you have achieved this.

However the glossary requirement is noting more than that, and so in that manner I will pursue the enhancement with Sparx.  

But you and Paolo have certainly given me some food for wider thoughts!

[Geert Bellekens]

David,

I was already writing an article about this subject (and in general about information modelling).
I'll let you know when it's published

Geert

[David OD]

I look forward to reading it Geert.