 |
Page History
| Wiki Markup |
|---|
{scrollbar:icons=false}
h1. { |
| Scrollbar | ||
|---|---|---|
|
page-info |
...
Initial Analysis:
...
Item
...
Information/Response
...
Date:
:title} h2. Initial Analysis: || Item || Information/Response || | {color:#000000}{*}Date{*}{color}{color:#000000}: {color} | 02/02/2010 |
...
| | {color:#000000}{*}Requirement # unique id{*}{color} _<SemConOps Initiative>.<analysts initials><requirement number> |
...
_ \\ e.g. Init1dbw1 |
...
Init1dbw11
\\ (eventually linked to Use Cases) | Init1dbw11 | | *Originator/Customer's Name*: |
...
| Dianne |
...
Reeves | | *Originator/Customer's Company*: |
...
| CBIIT Manual based metadata content |
...
Summary of requirement initial analysis, by Reviewer: (as unambiguously as possible, describe who (List of Actors) is interacting with the system, what the business goal is and how the system might support the actor's ability to acheive their goal)
...
When a Metadata Curator or Information Modeler creates data element annotations using our current tools, we string together concepts to create the semantic description, making the meaning of the data unambiguous. If the class or attribute being described includes an adjective, or qualifier, there is sometimes debate over how many of those qualifiers belong in the single, coordinated concept vs. stringing together the terms out of atomic concepts to form the semantic description.
Example: If you are creating a data element for 'second laparotomy procedure findings', I would string together concepts of second + laparotomy + surgical procedure + results (or findings). This is the postcoordinated method.
By contrast, the precoordinated method would state that 'second laparatomy procedure' is all one concept, and requires a new NCI thesaurus concept.
The problem would be that some people will use the postcoordinated method, and others the precoordinated - but does it make a difference when looking up content on the grid, or exchanging content? Additionally, we find that submitters with lesser expertise in a domain area area faster to request precoordinated terms than SMEs or experienced curators who may be more comfortable finding terms that can be strung together.
There needs to be a way to support both approaches without sacrificing the ability to find, reuse, and share content
...
Recommended Next Step Enter one: Follow-up interview, Observe, Use Case Template (text), Use Case Model (formalized/UML diagram), Group Discussion, Prototype, Waiting Room
...
Use Case Model
...
developers \\ |
| *Summary of requirement initial analysis, by Reviewer:* (as unambiguously as possible, describe who ([List of Actors|https://wiki.nci.nih.gov/x/ewtyAQ]) is interacting with the system, what the business goal is and how the system might support the actor's ability to acheive their goal) | When a Metadata Curator or Information Modeler creates data element annotations using our current tools, we string together concepts to create the semantic description, making the meaning of the data unambiguous. If the class or attribute being described includes an adjective, or qualifier, there is sometimes debate over how many of those qualifiers belong in the single, coordinated concept vs. stringing together the terms out of atomic concepts to form the semantic description. \\
Example: If you are creating a data element for 'second laparotomy procedure findings', I would string together concepts of second + laparotomy + surgical procedure + results (or findings). This is the postcoordinated method. \\
By contrast, the precoordinated method would state that 'second laparatomy procedure' is all one concept, and requires a new NCI thesaurus concept. \\
The problem would be that some people will use the postcoordinated method, and others the precoordinated - but does it make a difference when looking up content on the grid, or exchanging content? Additionally, we find that submitters with lesser expertise in a domain area area faster to request precoordinated terms than SMEs or experienced curators who may be more comfortable finding terms that can be strung together. \\
There needs to be a way to support both approaches without sacrificing the ability to find, reuse, and share content |
| *Recommended Next Step* Enter one: Follow-up interview, Observe, Use Case Template (text), Use Case Model (formalized/UML diagram), Group Discussion, Prototype, Waiting Room | Use Case Model |
\\
{scrollbar:icons=false} |
