NADM Data Model Design Team Meeting Notes
November 13-14, 2000, Reno,
NV
Attendees: Éric Boisvert (GSC), Boyan
Brodaric (GSC), Simon Cox (CSIRO), Peter Davenport (GSC), Jordan Hastings
(UCSB), Murray Journeay (GSC), Bruce Johnson (USGS), Rob Krumm (IGS), Jim
McDonald (OGS), Steve Richard (AGS), Peter Schweitzer (USGS), Ron Wahl (USGS),
Jerry Weisenfluh (KGS).
· Boyan Brodaric
Goals: our purpose is to develop criteria for evaluating and refining the data model. How:
(1) Establish data model requirements with scenarios or
use-cases; (2) Develop public document; (3) Use requirements to evaluate the
data model(s).
Method: Deconstruct
SLTT queries: categorize, generalizeàscenariosà require. document.
Discussion
results:
·
Bruce Johnson: example use case.
2. Process:
(a) Identify area:
(b) select db contents.
(c) display results on screen as a map.
3. Critical issues: noted above.
· Boyan Brodaric
1) Review of day one.
2) Objectives for the day:
a) Develop use-case structure appropriate for DMDT (emphasize dm issues).
b) Determine what broad types of use-cases are of interest to DMDT: e.g. related to age, rock composition, relationships (stratigraphic, topologic, etc.); keep in mind the scope of the data model—what should be included and excluded.
c) Prototype some use-cases.
d) Define tasks and working teams.
(1) Preamble: context, preconditions, assumptions
(2) The Question
(3) Dialog: user-system dialog to resolve the question.
(4) Issues, including:
· parameters
· exceptions
· alternatives
(5) Answer from the system.
(6) Examples
(7) Post-amble: concluding comments.
Note: use-cases are to be dm independent and map-oriented; not all parts are required.
Age, Composition, Relationships (between things), Process, Space, Metadata (who did this, how well did they do it), Orientation, Genesis.
Use-case 1, based on age:
Preamble:
- single source (one classification for age; e.g. one geologic time scale)
- specified map extent
- relative ages (e.g. stratigraphic ages)
Question: Display all Precambrian rock units.
- find spatial objects (rocks) in preC age
- assign symbology
-display
Dialog:
Can the system do this without further dialog?
What do we mean by “display” – to screen, printer, map, table?
User-interface details are not our interest here.
Issues:
- age classification hierarchy (i.e. pC includes all of its stages)
- absolute, relative or both?
- symbolization?
- ambiguous ages?
Result: map
[End of Use-Case 1]
Use Case 2, based on composition:
Preamble:
- non-spatial?
- map extent supplied.
- data sources provided.
Question: Find all map units containing limestone.
Issues:
· Related to “limestone”:
- need a classification scheme which defines limestone
- does “limestone” refer to a lithologic classification or rock name description?
- hierarchy (micrite and lime mudstone are limestones).
· Related to “containing”:
- how much limestone; i.e. what abundance?
- measure abundance by threshold or geographic position?
· Related to “map units”:
- map unit might have limestone outside the map extent specified (lateral variation).
- are we dealing with occurrences (polygons) or descriptions (the unit definitions themselves)?
- what do we mean by map unit? Surficial + rock?
- what about the case where a unit contains limestone in NW of state, not in SW?
- what about the case where limestone is observed at a location (in a polygon) but it isn’t in the unit definition (for some reason, such as it wasn’t significant).
- what is the difference between map units and rock units?
- what about geochem – e.g. pick units that contain CaCO3? Probably not…
Result: A list of map units containing limestone
Post-amble: Would help if the system is self-describing; e.g. tell us what it knows about “limestone”.
[End of Use-Case 2]
Use Case 3 – based on a relationship:
Preamble:
- single source information (i.e. from one map / body of data).
Question:
Identify intrusive contacts of [Cretaceous age (<!*!*>)] [granites] with [dominantly carbonate rock]; <!*!*> is a generalization for Cretaceous age.
Issues:
- classification scheme: is “carbonate” in a controlled vocabulary or just text?
- age + rock type:
See Use Case 2 for [dominantly carbonate rock]
See Use Case 2 for <!*!*> [granites] - to find both is a standard join operation.
- intrusive: contact properties explicitly tagged as intrusive versus deduced from age and rock type (e.g. granite against older sed. rock).
- occurrence relations required.
- the relationship is adjacency. 4.3 does permit encoding each contact with a relationship between adjacent polygons.
- topology – need for explicit topologic relations (but this is in the realm of the GIS?)
- is a fault a contact? This is a SLTT issue, not a data model issue.
-“intrusive” is a process.
- contacts can have an age distinct from the age the adjacent units (e.g. disconformity).
- *** reasoning: are knowledge base and associated rules needed in the data model. This is a huge issue. Defer for now. Note: could build a rule as a description (paragraph) or as an executable piece of code.
Result:
A list of contacts.
[End of Use-Case 3]
Preamble:
Question:
What is the [usable] [scale range] of [these data]?
Issues:
1. purpose/perspective
2. quality - accuracy
- resolution
3. metric - object
- cartographic
-At what level of granularity is scale information or one of its proxies maintained?
- Feature-level metadata versus information about data collection.
4. collections – many types, and things can be grouped into higher levels:
spatial objects
implicit objects such as datasets
5. Is usability (for a purpose) part of the data model? Probably not. System can return metrics from which a user could use to evaluate usability for their need.
Result possibilities:
- a pair of numbers (scale denominators) 1:x – 1:y
- original scale
- prototype object – user could choose an outcrop, unit, etc.
- category scale (regional, local, site-specific)
[End of Use-Case 4]
(1) Reduce the 400 questions from SLLT to a small number of characteristic questions:
- Representative questions that would be meaningful to people reading them.
- Representative questions that bring out issues in the model.
Note 1: Many of the questions are compound queries: break up into individual queries, then eliminate the duplicates.
Note 2: our purpose is to develop criteria for evaluating and refining the data model.
SPECIFIC TASKS:
1. Simon – supply questions from mineral exploration domain by January 1st.
2. Iterations (generating characteristic questions)
1. Steve By January 1, 2001
2. Jon “”
3. Bruce “”
4. Jerry/Jon – categorize concepts, ambiguous terms (rock), making use of Jon’s list of terms. Also could use AGI Glossary (also available in electronic form but there are use issues).
3. Normalize (find patterns and put into canonical form)
1. Jordan January 31, 2001
2. Boyan “”
4. Use-cases (mix of simple, compound and weird)
1. Jon/Steve March 31, 2001 generate
2. Todd/(Bedford/Ludington?) document
3. Jerry/Jim/Rob/Scott distribute for comment
5. Group meeting to finalize a single set of documented use-cases.
6. Completion of final document by end of April, 2001. Who: TBD.
7. Submit to Steering Committee by end of April for review for next NADMSC (at DMT’01).