Open lbtgnn68 opened 5 years ago
Dear @lbtgnn68 could you please check whether the assigned labels fit as use cases for your user story? Please check this table to find a better or additional use case which matches better your user story.
Hi @Mabablue, I would add data annotation & metadata annotation. Thanks!
Could you do it for me?
yes I could do, but we decided to have only 3 labels for each user story. So either we decide to delete one of the other labels or we don't add annotation. Please reconsider your proposal. Thanks
As a
Soil data manager
I want to
normalize (both) the collected (and collectable) soil information in agreement with the INSPIRE directive (https://inspire.ec.europa.eu/id/document/tg/so; https://inspire.ec.europa.eu/data-model/approved/r4618-ir/html/ - Themes>Annex III>SO) ) according to the Observation and Measurement Standard (https://www.opengeospatial.org/standards/om),
so that
observableProperties (together with UnitsOfMeasure, and Processes) would result in unambiguous descriptions.
Domain(s)
Soil; Geographic information; Biology; Biochemistry; Microbiology; Chemistry; Mineralogy; Pedology; Physics; Hydrology; Micromorphology
Addition Information
Usually, relational databases store data according to a physical implementation into tables, records, and columns where tables partly identify natural entities, columns identify properties (parameters) and records the recorded data (semantic representation). Unnormalized structures are unfortunately characterized by different notations of the same parameter, or feature-of-interest, related to different natural entities. Searching for all properties related to nitrogen in an unnormalized database means checking manually all coding for every column and table (hundreds of fields). No query automatically implements such a simple search. Normalizing the database would allow for a simple query to enable such a search. The achievement of a standard goes through the normalizing step.