This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Glossary Artifact Definition"

From HL7Wiki
Jump to navigation Jump to search
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:SAIF Artifact Definition]]
 
[[Category:SAIF Artifact Definition]]
 
[[:Category:SAIF Artifact Definition|Return to Artifact List]]
 
[[:Category:SAIF Artifact Definition|Return to Artifact List]]
=Glossary - incomplete=
+
=Glossary=
 
<!-- Artifact names should be descriptive and short.  They may change as we further refine the methodology -->
 
<!-- Artifact names should be descriptive and short.  They may change as we further refine the methodology -->
 
== Definition and Purpose ==
 
== Definition and Purpose ==
 
<!-- At a high level, what is this artifact and why is it needed?  Should ideally be only a few sentences -->
 
<!-- At a high level, what is this artifact and why is it needed?  Should ideally be only a few sentences -->
Is a '''collection of defined terms''' used in the specifications created for a particular domain or project.  It collects defined terms from a variety of sources and makes them and their definitions available for "re-use" in other standards and publications.
+
Is a '''collection of defined terms''' used in the specifications created for a particular [[Artifact Domain Artifact Definition#Domain|domain]] or project.  It collects defined terms from a variety of sources and makes them and their definitions available for "re-use" in other standards and publications.
PRELIMINARY NOTES:
 
MIF -  (bold is element)
 
*'''glossary'''
 
**title (0..1)
 
**secondaryId (0..1)
 
**:
 
**'''packageLocation (0..1)'''
 
***all standard elements
 
**:
 
**'''replaces (0..*)''' (glossary by ref)
 
**'''replacedBy (0..*)''' (glossary by ref)
 
**'''importedGlossary (0..*)''' (glossary by ref) "base glossary" whose terms will be overridden if defined in current glossary
 
**:
 
**'''termDefinition (1..*)'''
 
***term (1..1) note that this is the '''sole identifier''' at this level
 
***:
 
***'''definition (0..*)''' - despite being infinitely infinite, there is NO further identification except the "lang" in the text element
 
****''''text (1..*)''' (with language)
 
***:
 
***'''termTranslation (0..*)'''
 
****name (1..1) - translated term
 
****lang (0..1)
 
****'''realmNamespace (0..*)''' in which used or managed
 
*****value  (1..1)
 
***:
 
***'''seeAlso (0..*)''' type is a string holding a term to reference
 
 
 
identifier elements (min) reqd choices for publishing include : artifact realm domain name
 
 
 
gl identified by:
 
 
 
should be artifact (not defined in a domain like the RIM, DAM, DT, VO, DC , but these are NOT presently allowed a GL)
 
 
 
domain-realm
 
artifact-domain-realm
 
 
 
name-realm (Like core principles)
 
  
 
== SAIF Matrix Location ==
 
== SAIF Matrix Location ==
Line 78: Line 41:
 
== Requirements, Relationships and Content ==
 
== Requirements, Relationships and Content ==
 
<!-- What are the needs that this particular artifact was created to satisfy and why are those needs important.  (Should not be more than 10-15.) -->
 
<!-- What are the needs that this particular artifact was created to satisfy and why are those needs important.  (Should not be more than 10-15.) -->
# Each glossary '''term must have a unique name''' within the context in which it is defined.
+
# Each glossary '''term must be unique''' within the context in which it is defined.
## <i>Rationale</i>Terms are referenced by their names.  
+
## <i>Rationale</i> Terms are referenced by their names.  
# Each glossary term must be defined within a context that is one of:
+
# Each glossary term must be '''defined within a context''' that is one of:
#:*A domain-realm combination of a [[Artifact Domain Artifact Definition#Namespace Realm|namespace realm]] and an HL7 [[Artifact Domain Artifact Definition#Domain|domain level]]   
+
#:*A '''domain-realm combination''' of a [[Artifact Domain Artifact Definition#Namespace Realm|namespace realm]] and an HL7 [[Artifact Domain Artifact Definition#Domain|domain level]];
## <i>Rationale</i>Some other reason
+
#:*:
 +
#:*A specification '''document''' and the [[Artifact Domain Artifact Definition#Namespace Realm|namespace realm]] in which it is defined (such as "Core Principles" or an "Implementable Technology Specification" in the "universal" namespace.)
 +
#:*:
 +
#:*A '''"universal" artifact''' that is not within a domain, such as [[Reference Information Model Artifact Definition|RIM]], [[Vocabulary Model Artifact Definition|Vocabulary Model]] or Abstract Data Types Model Artifact Definition|Abstract Data Types Model]].  
 +
#:
 +
## <i>Rationale</i> Many technology areas use more-specific or variant definitions for common words. These contextual definitions need to be presented along with the common and there must be a way to link to the contextual definitions when publishing.  For example, the word "transport" when used in the context of Emergency Care as opposed to the context of a Transmission Protocol.
 +
#Each term must permit of '''alternate definitions in the same context'''.
 +
## <i>Rationale</i> Many words have multiple meanings in the HL7 context. Consider the word "document" as used as a noun in CDA and as a verb in writing SAIF Artifact definitions.  Also, see the definition for [http://www.hl7.org/v3ballot/html/help/glossary/glossary.html#domain domain] in the V3 Glossary.
 +
#It must be possible to record '''translations to various languages for each "term" and each "definition"''' of the terms.
 +
## <i>Rationale</i> The name of the organization is HL7 '''International'''
 +
#The glossary must permit '''alternate terms for a given definition''', such as "CMET" pointing to definition for "common model element type".
 +
## <i>Rationale</i> In an environment that is rife with acronyms, this provides the ability to link an acronym to both the full term and the definition thereof.
 +
#The "markup" of definitions needs to be sufficiently rich that a '''definition can be "included" in another document''' directly from the glossary source, rather than by copying.
 +
## <i>Rationale</i> Reuse of glossary definitions across multiple documents is crucial to the maintenance of consistent standards across HL7.
 
=== Relationships and traceability ===
 
=== Relationships and traceability ===
 
 
<!-- What are the other artifacts to which this artifact must or may be required to relate?  (Express those relationships that are "many-to-one" - that is where many of this artifact type will usually relate to one of the other artifact type.) How do they relate?  Why is the relationship important?  
 
<!-- What are the other artifacts to which this artifact must or may be required to relate?  (Express those relationships that are "many-to-one" - that is where many of this artifact type will usually relate to one of the other artifact type.) How do they relate?  Why is the relationship important?  
  
 
Follow with a bullet list of artifacts that may or must relate to this artifact, where many of the listed artifact type will relate to one of this artifact type.   
 
Follow with a bullet list of artifacts that may or must relate to this artifact, where many of the listed artifact type will relate to one of this artifact type.   
 
  -->
 
  -->
* Some relationship
+
* A glossary must be able to indicate which glossary it '''replaces'''.
** <i>Rationale</i>: Reason for relationship
+
**''Rationale:''' In glossary management this will permit a representation and tracing of the evolution of glossaries.
* Some other relationship
 
** <i>Rationale</i>: Reason for other relationship
 
  
 
<b>Artifact types that may or must relate to this artifact types:</b>
 
<b>Artifact types that may or must relate to this artifact types:</b>
* Many-related Artifact Type
+
* The '''documentation of any SAIF specification''' may desire to '''link to''' a particular glossary term, or to '''include a glossary term and its definition'''' in the body of the document.
* Another Many-related Artifact Type
 
  
 
=== Content ===
 
=== Content ===
 +
<!-- What elements or components are required to be part of this artifact, and what is their hierarchical structure?  How?  Why is the content important? (These can be expresses as a hierarchical set of content element names, with a brief phrase to describe each.) -->
 +
<b>glossary</b> - the collection itself
 +
*<b>glossary identifier</b> including elements for
 +
**'''''namespace realm''''' - universal or an affiliate realm
 +
**'''''domain''''' - in which glossary being defined
 +
**'''''artifact type''''' - for specifications like RIM, etc.
 +
**'''''specification name''''' - unique name to identify non-artifact documented specifications/
 +
*<b>term definitions</b> (1..*) - core content for the glossary
 +
**<b>term</b> (1..1) - the term being defined, which is also the primary identifier 
 +
***<b>definition</b> (0..*) - the text plus translations thereof
 +
****<i>definition properties</i> - additional properties for managing definitions
 +
*****<b>sequence</b> for distinguishing multiple definitions in same context
 +
*****<b>part of speech</b> - "noun", "verb", "adjective", "adverb", with default being "noun"
 +
*****<b>is preferred</b> - will select the preferred definition where there are multiples
 +
*****<b>secondary identifier</b> - to provide another index to the content (in addition to "term") that will allow aggregation of the content into a single namespace for publishing purposes.
 +
**<b>term translation</b> (0..*) - provides for translations of the term name.
 +
**<b>alternative term</b> (0..*) - provides a reference to another glossary term that either enhances the definition, or (if no definition is recorded above) provides the definition (as for an acronym). 
  
<!-- What elements or components are required to be part of this artifact, and what is their hierarchical structure?  How?  Why is the content important? (These can be expresses as a hierarchical set of content element names, with a brief phrase to describe each.) -->
+
<!-- PRELIMINARY NOTES:
* <b>Content element name</b> - Brief Description
+
MIF -  (bold is element)
* <b>Another content element name</b> - Brief Description
+
*'''glossary'''
** <b>Sub-element name</b> - Brief Description
+
**title (0..1)
* <b>Another content element name</b> - Brief Description
+
**secondaryId (0..1)
 +
**:
 +
**'''packageLocation (0..1)'''
 +
***all standard elements
 +
**:
 +
**'''replaces (0..*)''' (glossary by ref)
 +
**'''replacedBy (0..*)''' (glossary by ref)
 +
**'''importedGlossary (0..*)''' (glossary by ref) "base glossary" whose terms will be overridden if defined in current glossary
 +
**:
 +
**'''termDefinition (1..*)'''
 +
***term (1..1) note that this is the '''sole identifier''' at this level
 +
***:
 +
***'''definition (0..*)''' - despite being infinitely infinite, there is NO further identification except the "lang" in the text element
 +
****''''text (1..*)''' (with language)
 +
***:
 +
***'''termTranslation (0..*)'''
 +
****name (1..1) - translated term
 +
****lang (0..1)
 +
****'''realmNamespace (0..*)''' in which used or managed
 +
*****value  (1..1)
 +
***:
 +
***'''seeAlso (0..*)''' type is a string holding a term to reference
 +
 
 +
identifier elements (min) reqd choices for publishing include : artifact realm domain name
 +
 
 +
gl identified by:
 +
 
 +
should be artifact (not defined in a domain like the RIM, DAM, DT, VO, DC , but these are NOT presently allowed a GL)
 +
 
 +
domain-realm
 +
artifact-domain-realm
 +
 
 +
name-realm (Like core principles) -->
  
 
== Artifact Technology ==
 
== Artifact Technology ==
 +
Instances of this artifact type will be '''created, maintained and distributed''' as a file that conforms to the [http://www.hl7.org/v3ballot/html/infrastructure/mif/mif.html HL7 Model Interchange Format] (MIF).
  
<!-- What technological/standard solution has been selected for use in creating this artifact and why? -->
+
The '''underlying technology''' (as of April 2011) is:
Text here
+
*The '''"Core Glossary"''' (identifier is just the "namespace realm" for universal) is maintained in "publishing" xml but will be converted within months to MIF.
 
+
*'''"Local" glossaries''' for [[Artifact Domain Artifact Definition#Domain|domains]] is captured in that domain's [http://gforge.hl7.org/gf/project/pubdb/frs/ publication database] (Access).  When the domain content is extracted, a glossary file is also extracted for conversion to MIF and merger.
 +
*Glossaries for '''single documents''' are captured as:
 +
**'''Stand-alone xml''' files for conversion to MIF and merger
 +
**:
 +
**'''In-line term definitions''' that can be extracted to glossary MIF and will (in future) be replaced with "include" links to their glossary.
 +
*'''Editing''':
 +
**of definitions in the PubDb can be linked to '''XML-spy in a quasi-WYSIWYG GUI'''
 +
**'''XML-editor of choice''' with no special support for reviewing markup except by rapid transform to "final form", which is available through current [http://gforge.hl7.org/gf/project/xmlpublishing/frs/ V3 Publishing Tools].
 
=== Rationale ===
 
=== Rationale ===
 
 
<!-- What's the justification for selecting the chosen technology? -->
 
<!-- What's the justification for selecting the chosen technology? -->
* Some reason
+
* The whole of the HL7 specification management and publication process is based on the notion of producing "processable" content files in MIF that can be used to publish the ballot.  The glossaries have been managed in XML for over almost a decade. 
* Some other reason
+
* The objective of the evolution of these tools is to move to an open platform dependent (Java).  This is a work in progress. 
 
 
 
=== Alternatives ===
 
=== Alternatives ===
 
 
<!-- What other technical solutions might have been possible that were discarded, what did they offer and why were they not chosen? -->
 
<!-- What other technical solutions might have been possible that were discarded, what did they offer and why were they not chosen? -->
 
<b>Some technology</b>
 
* Some pro or con
 
* Some other pro or con
 
  
 
== Content Constraints ==
 
== Content Constraints ==
 
 
<!-- What are the formal rules about how the artifact can be constructed, including any extensions and constraints for the selected technology as well as the rationale for those rules.  These are rules that can reasonably be enforced or validated by tools. -->
 
<!-- What are the formal rules about how the artifact can be constructed, including any extensions and constraints for the selected technology as well as the rationale for those rules.  These are rules that can reasonably be enforced or validated by tools. -->
# Some rule
 
## <i>Rationale</i>: Some reason
 
# Some other rule
 
## <i>Rationale</i>: Some other reason
 
 
 
== Content Guidelines ==
 
== Content Guidelines ==
 
 
<!-- What are the informal guidelines about how the artifact content.  I.e. What constitutes good practice?  These guidelines should be used in the evaluation of artifact instances but generally can't be enforced or validated by tools. -->
 
<!-- What are the informal guidelines about how the artifact content.  I.e. What constitutes good practice?  These guidelines should be used in the evaluation of artifact instances but generally can't be enforced or validated by tools. -->
# Some rule
+
# "term" names should be all lower case unless they are specifically an acronym, or pointing a definition that is capitalized in '''general''' usage.  Thus the term should be "serialized information model" and the acronym term should be "SIM"
## <i>Rationale</i>: Some reason
+
## <i>Rationale</i>: This is start of a style guide.
# Some other rule
+
# "definitions" should start with a "noun phrase" that presupposes a lead in of "<term> is " to form a sentence. Subsequent elements of the definition should be complete sentences.
## <i>Rationale</i>: Some other reason
+
## <i>Rationale</i>: See [[Annotations_Best_Practices|HL7 annotation style guide]] for definitions.
 +
# All acronyms that are included as terms should link to their definition under a fully spelled out term.  Do not list a definition for an acronym.
 +
## <i>Rationale</i>: This is start of a style guide.
  
 
== Publishing Representation(s) ==
 
== Publishing Representation(s) ==
 
 
<!-- How will this artifact be shared and published as part of specifications? -->
 
<!-- How will this artifact be shared and published as part of specifications? -->
# Some text
+
# At present, standard publishing within HL7 produces:
## <i>Rationale</i>: Some rationale
+
#:*A universal "core" glossary at the level of the ballot itself that includes solely "global" or core content
# Some other text
+
#:*A domain- or document-specific glossary for each domain or document being balloted that includes both the  "core" glossary and the specific terms.
## <i>Rationale</i>: Some other rationale
 
  
 
== Publishing Constraints ==
 
== Publishing Constraints ==
 
 
<!-- What are the constraints imposed by the publishing process on how artifacts are constructed and submitted to HL7and what are the reasons behind such constraints? -->
 
<!-- What are the constraints imposed by the publishing process on how artifacts are constructed and submitted to HL7and what are the reasons behind such constraints? -->
# Some rule
 
## <i>Rationale</i>: Some reason
 
# Some other rule
 
## <i>Rationale</i>: Some other reason
 
  
 
== Tooling Considerations ==
 
== Tooling Considerations ==
 
 
<!-- What tooling features are required or "nice to have" to allow successful development, publication or other use of the artifact? -->
 
<!-- What tooling features are required or "nice to have" to allow successful development, publication or other use of the artifact? -->
# Nice-to-have|Required: Some feature
+
# Nice-to-have|Required: WYSIWYG editor for reviewing, editing and creating glossary content.
## <i>Rationale</i>: Some rationale
+
## <i>Rationale</i>: Too easy to skip glossary steps if it is not easy to use them.
# Nice-to-have|Required: Some other feature
 
## <i>Rationale</i>: Some other rationale
 
  
 
== Development Process Considerations ==
 
== Development Process Considerations ==
 
 
 
<!-- This section is optional.  It identifies thoughts or guidance around how the artifact will be used.  This may include development process, guidance on how many of this type of artifact are likely to exist within a domain or topic, etc. -->
 
<!-- This section is optional.  It identifies thoughts or guidance around how the artifact will be used.  This may include development process, guidance on how many of this type of artifact are likely to exist within a domain or topic, etc. -->
 
+
# Regardless of whether authors are writing a text document, creating an information model, etc., two critical elements should be available to them:
# Some text
+
#:#Ready access to the existing glossary content for review, and, perhaps for inclusion, in the specification they are creating; and
## <i>Rationale</i>: Some rationale
+
#:#A straightforward means of adding new glossary terms to their own domain.
# Some other text
+
## <i>Rationale</i>: Glossaries are often overlooked simply because they are secondary to the business of writing rather than integral thereto.
## <i>Rationale</i>: Some other rationale
 
  
 
== Governance Process Considerations ==
 
== Governance Process Considerations ==
 
 
 
<!-- This section is optional.  It identifies anticipated or existing governance processes that control or impact the development and adoption of this type of artifact.  -->
 
<!-- This section is optional.  It identifies anticipated or existing governance processes that control or impact the development and adoption of this type of artifact.  -->
 
# <b>Governance Process name</b> - Some process description
 
## <i>Rationale</i>: Some rationale
 
# <b>Another Governance Process name</b> - Process description
 
## <i>Rationale</i>: Some other rationale
 
 
 
== Issues ==
 
== Issues ==
 
 
 
<!-- This section is optional. It identifies any outstanding issues (methodology or otherwise) that need to be resolved/answered as part of the guidelines -->
 
<!-- This section is optional. It identifies any outstanding issues (methodology or otherwise) that need to be resolved/answered as part of the guidelines -->
 
* Some issue
 
* Some other issue
 

Latest revision as of 17:00, 21 April 2011

Return to Artifact List

Glossary

Definition and Purpose

Is a collection of defined terms used in the specifications created for a particular domain or project. It collects defined terms from a variety of sources and makes them and their definitions available for "re-use" in other standards and publications.

SAIF Matrix Location

This artifact is "Level-independent" because it is may be required at any level at which other artifacts or specifications are being defined. Glossaries are managed to serve all levels. Row(s)

  • Conceptual (CIM)
  • Logical (PIM)
  • Implementable (PSM)

Column(s)

  • Enterprise/Business
  • Information

Audience

The audience is all audiences because the definitional clarity provided by a glossary is intended to inform any audience.

Health Care Community Audiences:

  • General public
  • Health care practitioners
  • Health system administrators
  • Health care policy makers

Health Care Information Technology (IT) Audiences:

  • System designers and architects
  • System purchasers
  • Programmers/implementers
  • System vendor management

Applicability

This artifact should be created wherever new terminology is being introduced for use in HL7 specifications. Because of the management requirements of glossaries, they should be defined, in general, at the domain level rather than as part of artifacts of a lower scope.

Rationale:Glossary term definitions need to be overseen by the Work Groups that create them and must be managed, overall, for publishing in HL7. Thus the glossary content should be aggregated, to the degree possible, within Work Groups and domains.

Requirements, Relationships and Content

  1. Each glossary term must be unique within the context in which it is defined.
    1. Rationale Terms are referenced by their names.
  2. Each glossary term must be defined within a context that is one of:
    • A domain-realm combination of a namespace realm and an HL7 domain level;
    • A specification document and the namespace realm in which it is defined (such as "Core Principles" or an "Implementable Technology Specification" in the "universal" namespace.)
    • A "universal" artifact that is not within a domain, such as RIM, Vocabulary Model or Abstract Data Types Model Artifact Definition|Abstract Data Types Model]].
    1. Rationale Many technology areas use more-specific or variant definitions for common words. These contextual definitions need to be presented along with the common and there must be a way to link to the contextual definitions when publishing. For example, the word "transport" when used in the context of Emergency Care as opposed to the context of a Transmission Protocol.
  3. Each term must permit of alternate definitions in the same context.
    1. Rationale Many words have multiple meanings in the HL7 context. Consider the word "document" as used as a noun in CDA and as a verb in writing SAIF Artifact definitions. Also, see the definition for domain in the V3 Glossary.
  4. It must be possible to record translations to various languages for each "term" and each "definition" of the terms.
    1. Rationale The name of the organization is HL7 International
  5. The glossary must permit alternate terms for a given definition, such as "CMET" pointing to definition for "common model element type".
    1. Rationale In an environment that is rife with acronyms, this provides the ability to link an acronym to both the full term and the definition thereof.
  6. The "markup" of definitions needs to be sufficiently rich that a definition can be "included" in another document directly from the glossary source, rather than by copying.
    1. Rationale Reuse of glossary definitions across multiple documents is crucial to the maintenance of consistent standards across HL7.

Relationships and traceability

  • A glossary must be able to indicate which glossary it replaces.
    • Rationale:' In glossary management this will permit a representation and tracing of the evolution of glossaries.

Artifact types that may or must relate to this artifact types:

  • The documentation of any SAIF specification may desire to link to a particular glossary term, or to include a glossary term and its definition' in the body of the document.

Content

glossary - the collection itself

  • glossary identifier including elements for
    • namespace realm - universal or an affiliate realm
    • domain - in which glossary being defined
    • artifact type - for specifications like RIM, etc.
    • specification name - unique name to identify non-artifact documented specifications/
  • term definitions (1..*) - core content for the glossary
    • term (1..1) - the term being defined, which is also the primary identifier
      • definition (0..*) - the text plus translations thereof
        • definition properties - additional properties for managing definitions
          • sequence for distinguishing multiple definitions in same context
          • part of speech - "noun", "verb", "adjective", "adverb", with default being "noun"
          • is preferred - will select the preferred definition where there are multiples
          • secondary identifier - to provide another index to the content (in addition to "term") that will allow aggregation of the content into a single namespace for publishing purposes.
    • term translation (0..*) - provides for translations of the term name.
    • alternative term (0..*) - provides a reference to another glossary term that either enhances the definition, or (if no definition is recorded above) provides the definition (as for an acronym).


Artifact Technology

Instances of this artifact type will be created, maintained and distributed as a file that conforms to the HL7 Model Interchange Format (MIF).

The underlying technology (as of April 2011) is:

  • The "Core Glossary" (identifier is just the "namespace realm" for universal) is maintained in "publishing" xml but will be converted within months to MIF.
  • "Local" glossaries for domains is captured in that domain's publication database (Access). When the domain content is extracted, a glossary file is also extracted for conversion to MIF and merger.
  • Glossaries for single documents are captured as:
    • Stand-alone xml files for conversion to MIF and merger
    • In-line term definitions that can be extracted to glossary MIF and will (in future) be replaced with "include" links to their glossary.
  • Editing:
    • of definitions in the PubDb can be linked to XML-spy in a quasi-WYSIWYG GUI
    • XML-editor of choice with no special support for reviewing markup except by rapid transform to "final form", which is available through current V3 Publishing Tools.

Rationale

  • The whole of the HL7 specification management and publication process is based on the notion of producing "processable" content files in MIF that can be used to publish the ballot. The glossaries have been managed in XML for over almost a decade.
  • The objective of the evolution of these tools is to move to an open platform dependent (Java). This is a work in progress.

Alternatives

Content Constraints

Content Guidelines

  1. "term" names should be all lower case unless they are specifically an acronym, or pointing a definition that is capitalized in general usage. Thus the term should be "serialized information model" and the acronym term should be "SIM"
    1. Rationale: This is start of a style guide.
  2. "definitions" should start with a "noun phrase" that presupposes a lead in of "<term> is " to form a sentence. Subsequent elements of the definition should be complete sentences.
    1. Rationale: See HL7 annotation style guide for definitions.
  3. All acronyms that are included as terms should link to their definition under a fully spelled out term. Do not list a definition for an acronym.
    1. Rationale: This is start of a style guide.

Publishing Representation(s)

  1. At present, standard publishing within HL7 produces:
    • A universal "core" glossary at the level of the ballot itself that includes solely "global" or core content
    • A domain- or document-specific glossary for each domain or document being balloted that includes both the "core" glossary and the specific terms.

Publishing Constraints

Tooling Considerations

  1. Nice-to-have|Required: WYSIWYG editor for reviewing, editing and creating glossary content.
    1. Rationale: Too easy to skip glossary steps if it is not easy to use them.

Development Process Considerations

  1. Regardless of whether authors are writing a text document, creating an information model, etc., two critical elements should be available to them:
    1. Ready access to the existing glossary content for review, and, perhaps for inclusion, in the specification they are creating; and
    2. A straightforward means of adding new glossary terms to their own domain.
    1. Rationale: Glossaries are often overlooked simply because they are secondary to the business of writing rather than integral thereto.

Governance Process Considerations

Issues