ArthurChapman
commented
1 year ago Do we need to add a term for "Resource Type" or just rely on the OWL document @chicoreus
Open Tasilee opened 5 years ago
ArthurChapman
commented
1 year ago Do we need to add a term for "Resource Type" or just rely on the OWL document @chicoreus
ArthurChapman
commented
1 year ago Following ZOOM discussion of 2023-07-/03/04
The Note for Assertion was changed to:
The assertion concept consists of a specification (the technical description of a performed test), a data resource (initial values of input data expressed in terms of some controlled vocabulary), the mechanism (external service, actor, or code that performs the test), and a test result.
ArthurChapman
commented
1 year ago Updated comment for "Response" to
"Parent of RESULT and RESULT_STATUS in the Fitness for Use Framework (Viega et al. 2017)."
chicoreus
commented
1 year ago On Mon, 03 Jul 2023 17:50:42 -0700 Arthur Chapman @.***> wrote:
Do we need to add a term for "Resource Type" or just rely on the OWL document @chicoreus
That is a term in the ffdq owl. Definition there needs work.
ArthurChapman
commented
1 year ago Added following terms
| bdq:countryShapes | Polygons derived from a union of countries with their EEZs | Parameter | See COUNTRYCODE_FROM_COORDINATES (8c5fe9c9-4ba9-49ef-b15a-9ccd0424e6ae). |
| bdq:geospatialLand | Polygons derived from a union of Natural Earth vectors for Land and for Minor Islands at 1:10,000,000 resolution. | Parameter | See VALIDATION_COORDINATES_TERRESTRIALMARINE (b9c184ce-a859-410c-9d12-71a338200380) |
| bdq:taxonomyIsMarine | Marine/non-marine status obtained from the World Register of Marine Species (WORMS) database | Parameter | See VALIDATION_COORDINATES_TERRESTRIALMARINE (b9c184ce-a859-410c-9d12-71a338200380) |
Edited bdq:sourceAuthority to remove these three (previously included as bdq:sourceAuthority[countryshapes], bdq:sourceAuthority[geospatialland] and bdq:sourceAuthority[taxonomyismarine] respectively).
@chicoreus, @tucotuco, @Tasilee - please check the descriptions.
ArthurChapman
commented
1 year ago Slight mistake in last post corrected - i.e. "taxonomyIsMarine" changed to "bdq:taxonomyIsMarine"
Tasilee
commented
1 year ago For https://github.com/tdwg/bdq/issues/152#issuecomment-1619305370, I would suggest changing
"All the current tests are run on a single record and not designed to be run across multi records".
to
"All tests apply to a single Darwin Core record, but the results can be accumulated across multiple records".
ArthurChapman
commented
1 year ago Done
chicoreus
commented
1 year ago On Sun, 09 Jul 2023 15:09:14 -0700 Lee Belbin @.***> wrote:
"All the current tests are run on a single record and not designed to be run across multi records".
That should be:
"All the current tests are run on a SingleRecord (q.v.), of Darwin Core data, and not designed to be run across a MultiRecord (q.v.), except for MultiRecord Measures."
ArthurChapman
commented
1 year ago @chicoreus Do we keep just "single record" in the vocabulary - we don't have singleRecord or multiRecord in the vocabulary now - but I expect they are in the OWL document? How are these done in document - we have "single record" "Single Record" "singleRecord" and I think "SingleRecord" in various places (in the tests, in the Standards Document" etc.
chicoreus
commented
1 year ago On Sun, 09 Jul 2023 16:49:42 -0700 Arthur Chapman @.***> wrote:
@chicoreus Do we keep just "single record" in the vocabulary - we don't have singleRecord or multiRecord in the vocabulary now - but I expect they are in the OWL document? How are these done in document - we have "single record" "Single Record" "singleRecord" and I think "SingleRecord" in various places (in the tests, in the Standards Document" etc.
SingleRecord and MultiRecord are instances of ResourceType.
Currently these have IRIs in the form https://rs.tdwg.org/bdq/ffdq/ResourceType with rdfs:label values in the form "Resource Type" lang=en.
The column header in https://github.com/tdwg/bdq/blob/master/tg2/core/TG2_tests.csv uses "Resource Type", but the values are "SingleRecord", the column headers should probably track the IRIs rather than the labels.
ArthurChapman
commented
1 year ago Following discussion on #73 - I think we now need to delete bdq:countryShapes from the Vocabulary - is that correct?
Tasilee
commented
1 year ago Yes @ArthurChapman, I believe so. The only reference to bdq:countryShapes was #73 and that has been changed to bdq:sourceAuthority.
ArthurChapman
commented
1 year ago Deleted bdq:countryShapes in line with comments and changes to issue #73
Tasilee
commented
11 months ago In writing the standard document, note that "amended" is a Warning Type and a Response.status.
Tasilee
commented
11 months ago Ditto "Issue" is both a class of data quality test and a Warning type.
Tasilee
commented
11 months ago We are missing a definition of Warning Type = "Report". This applies only to MEASUREs.
ArthurChapman
commented
11 months ago AMENDED
In an an earlier version of the Vocabulary, we had two instances of Amended - one in lower case (Warning Type) and one in Upper Case (Response).
I notice that in the Supplement to our paper we only had one - the Warning Type (https://biss.pensoft.net/article/download/suppl/5449427/).
I suggest that the only way to fix this is to reinstate the Warning Type definition and having two instances.
| AMENDED | Used to indicate that a response for an AMENDMENT (q.v.) contains a proposed change to a record in the Response.result (q.v.). | Response Status |
| Amended | Used to report on a recommended change to a record. | Warning Type |
ArthurChapman
commented
11 months ago Issue - could be treated similarly
| ISSUE | A class of data quality test from the Fitness for Use Framework that flags problems. In the context of the tests, ISSUE(s) are all POTENTIAL_ISSUE(s) (q.v.) where potential problems are flagged and may need examination by the user to determine if data have quality for their use. | Test type |
| Issue | Used to draw attention to a non-empty value of a Darwin Core term | Warning Type |
ArthurChapman
commented
11 months ago Again, we had REPORT in the Supplement as a Response, not a Warning Type.
"A Response (q.v.) reporting on the status from a test of type Measure (q.v.)."
Perhaps this needs discussion as we use Report in so many contexts in the Document - e.g. Data Quality Reports.
Is it really a Warning Type? Isn't it a Response that applies to MEASURES as we had originally defined it? What is the Warning?
If we want it as a warning type - it would be nice to use another term as it is confusing.
AGENDA Item
ArthurChapman
commented
11 months ago Should we add ActedUpon to the Vocabulary - see #5.3 of draft Standards Document @chicoreus
ArthurChapman
commented
11 months ago Copy of Vocabulary before incorporation of Framework terms (bdqffdq) and before reformatting to include bdqffdq: and bdq: namespace representations
Terms in UPPER CASE are a Response (q.v.) an Information Element (q.v.), a Test Type (q.v.), or part of the name of a test; terms from the FFU Framework (Viega et al. 2017) are noted in the comments. Use the reference to the Framework Definitions for more details and examples.
Term | Definition | Context | Comment -- | -- | -- | -- Ambiguous | Used to report where the Data Quality Dimension: Conformance (q.v.) is not satisfied due to Information Elements (q.v.) not being unambiguously resolvable by a bdq:sourceAuthority (q.v.). | Warning Type | AMENDED | Used to indicate that a response for an AMENDMENT (q.v.) contains a proposed change to a record in the Response.result (q.v.). | Response.status | Applies only to an AMENDMENT. AMENDMENT | Data were amended by modification or addition of a value or values following defined Criteria (q.v.). One of four output Test types (q.v.). | Test Type | Formally in the Fitness for Use Framework (Veiga et al.), the description of a test that can propose a change is an Enhancement, while the corresponding report level concept is an Amendment. Tests tagged as Amendments are Enhancements at the data quality needs level. ASSUMEDDEFAULT | An AMENDMENT (q.v.) that replaces an EMPTY (q.v.) term with a predefined default parameter (q.v.) value. | Response | Would be used only in an extension or in Response.comment, Response.status value for this case is AMENDED. Assertion | A statement resulting from the application of a VALIDATION (q.v.), ISSUE (q.v.), MEASURE (q.v.) or AMENDMENT (q.v.) | Response | The assertion concept consists of a specification (the technical description of a performed test), a data resource (initial values of input data expressed in terms of some controlled vocabulary), the mechanism (external service, actor, or code that performs the test), and a test result. bdq:annotationAlertIf | Optionally establishes if an annotation exists within a bdq:annotationSystem (q.v.) by describing the criteria for relating annotations in the system to records in a Parameterized Test (q.v.)." | Parameter | Used in test "ANNOTATION_ISSUE_NOTEMPTY" (fecaa8a3-bbd8-4c5a-a424-13c37c4bb7b1). bdq:annotationSystem | Optionally established a system for annotations within a Parameterized Test (q.v.) with the default being the w3c Annotations Data Model's "oa:Annotation" | Parameter | Used in test "ANNOTATION_ISSUE_NOTEMPTY" (fecaa8a3-bbd8-4c5a-a424-13c37c4bb7b1). bdq:defaultGeodeticDatum | Optionally established the default datum in a parameterized test (q.v.). A default datum is supplied in cases where a parameter (q.v.) is not set at the time the test is run. | Parameter | See test AMENDMENT_GEODETICDATUM_ASSUMEDDEFAULT (7498ca76-c4d4-42e2-8103-acacccbdffa7). bdq:earliestValidDate | Optionally establishes the earliest date in a parameterized test (q.v.). A default date is supplied in cases where a parameter (q.v.) is not set at the time the test is run. | Parameter | bdq:geospatialLand | Polygons derived from a union of Natural Earth vectors for Land and for Minor Islands at 1:10,000,000 resolution. | Parameter | See VALIDATION_COORDINATES_TERRESTRIALMARINE (b9c184ce-a859-410c-9d12-71a338200380) bdq:includeEventDate | Allows dwc:eventDate to be excluded in a parameterized test (q.v.). The default is to include the event date in the test, but it may be excluded to allow an identification to be prior to the event date. | Parameter | Used in test "VALIDATION_DATEIDENTIFIED_INRANGE" (dc8aae4b-134f-4d75-8a71-c4186239178e). bdq:latestValidDate | Optionally establishes the latest date in a parameterized test (q.v.). A default date is supplied in cases where a parameter (q.v.) is not set at the time the test is run. | Parameter | bdq:maximumValidDepthInMeters | Optionally establishes the maximum depth in a parameterized test (q.v.). A default depth is supplied in cases where a parameter (q.v.) is not set at the time the test is run. | Parameter | bdq:maximumValidElevationInMeters | Optionally establishes the highest elevation in a parameterized test (q.v.). A default elevation is supplied in cases where a parameter (q.v.) is not set at the time the test is run. | Parameter | bdq:minimumValidDepthInMeters | Optionally establishes the minimum depth in a parameterized test (q.v.). A default depth is supplied in cases where a parameter (q.v.) is not set at the time the test is run. | Parameter | bdq:minimumValidElevationInMeters | Optionally establishes the lowest elevation in a parameterized test (q.v.). A default elevation is supplied in cases where a parameter (q.v.) is not set at the time the test is run. | Parameter | bdq:sourceAuthority | An authority using the "bdq" namespace that provides a reference for values required for a test evaluation. Where the test is a parameterized test (q.v.) a default source authority ("bdq:sourceAuthority default = xxx") is specified. | Parameter | bdq:spatialBufferInMeters | A buffer in meters from a polygon (geopolitical boundary, coastline, etc.). | Parameter | bdq:targetCRS | The Coordinate Reference System (CRS) used as the output when converting coordinates from one CRS to another. The default is EPSG:4326. | Parameter | Used in the test AMENDMENT_COORDINATES_CONVERTED (620749b9-7d9c-4890-97d2-be3d1cde6da8) bdq:taxonomyIsMarine | Marine/non-marine status obtained from the World Register of Marine Species (WORMS) database | Parameter | See VALIDATION_COORDINATES_TERRESTRIALMARINE (b9c184ce-a859-410c-9d12-71a338200380) COMPLETE | An assertion (q.v.) of a MEASURE (q.v.) where data are present and sufficiently comprehensive for use. | Response.result | Completeness | The extent to which data are present and sufficiently comprehensive for use. | Data Quality Dimension | Definition from the Fitness for Use Framework: Data Quality Dimensions Document (**Link needed to RDF document ** - https://github.com/tdwg/bdq/wiki/TG2-Data-Quality-Dimension). Conformance | Conforms to a format, syntax, data type, range, or standard of the Information Element (q.v.). | Data Quality Dimension | Definition from the Fitness for Use Framework: Data Quality Dimensions Document (**Link needed to RDF document ** - https://github.com/tdwg/bdq/wiki/TG2-Data-Quality-Dimension). COMPLIANT | An Expected Response (q.v.) of a VALIDATION (q.v.) where the data conforms to the Test Criteria (q.v.). | Response.result | Applies only to Validations (q.v.). This differs from the definition in the Fitness for Use Framework. Consistency | Agreement among related Information Elements (q.v.) that are present in the data. Note that missing Information Elements do not make a test Inconsistent. | Definition from the Fitness for Use Framework: Data Quality Dimensions Document (**Link needed to RDF document ** - https://github.com/tdwg/bdq/wiki/TG2-Data-Quality-Dimension). | CONSISTENT | Identifies inconsistency among values between Information Elements (q.v.). | Response.result | CONVERTED | A conversion has been proposed to values in the Information Elements (q.v.) to conform with a targeted reference system. | Response | See Test "AMENDMENT_COORDINATES_CONVERTED" (620749b9-7d9c-4890-97d2-be3d1cde6da8). COORDINATES | Represents the combination of the Darwin Core terms dwc:decimalLatitude and dwc:decimalLongitude. | Information Element | CORE | Fundamental tests of biodiversity data represented in Darwin Core terms that are widely applicable, informative, and straight forward to implement. Developed from use cases derived from needs analyzed by user stories. | Tests | Data Quality Dimension | Measurable attributes in an Information Element (q.v.) which can be individually assessed, interpreted, and improved. Includes Completeness (q.v.), Conformance (q.v.), Consistency (q.v.), Likeliness (q.v.), Reliability (q.v.), and Resolution (q.v.). | Fitness for Use Framework | Link to OWL Document Data Quality Report | An account of the responses from a set of VALIDATIONS (q.v.), ISSUES (q.v.), MEASURES (q.v.) and AMENDMENTS (q.v.) designed to assess the fitness for use of the tested data for a particular purpose. | Fitness For Use Framework | Link to OWL Document Default source authority | A default where a required Parameter (q.v.) or a bdq:sourceAuthority (q.v.) has not been provided. | Parameter | Default value | A preselected value (e.g. year, elevation) where a required Parameter (q.v.) value has not been provided. | Parameter | EMPTY | An information element that is either not present or does not contain any characters or values other than those in the range U+0000 to U+0020. | Data | Note: An information element containing invalid characters (e.g. letters in an information element that would be expected to contain integers) or values (including string serializations of the NULL value) are NOT_EMPTY and may be separately detected. EPSG: | A pseudo-namespace referenced in dwc:datum to indicate the EPSG API where the numeric value following the colon is used as the search key. Example: EPSG:4326. | Data | Examples | Provide one pass (i.e. COMPLIANT) example and one fail (NON_COMPLIANT) example for each test. | Parameter | Expected Response | A term used in place of Specification (q.v.) in the markdown of the tests in the bdq GitHub. | Response | EXTERNAL_PREREQUISITES_NOT_MET | A Response (q.v.) was not generated because a bdq:sourceAuthority (q.v.) was not available or was off-line. If the test is run at a later time, it may produce a different result. | Response.status | Caching - needs discussing? FILLED_IN | An AMENDMENT (q.v.) where a value has been proposed for an Information Element (q.v.) that has no value. | Response | FOUND | The value in an Information Element (q.v.) that matched a value in a bdq:sourceAuthority (q.v.). | Response | Use COMPLIANT for Response.result, and include this in Response.comments or Response.qualifier. gbif: | A pseudo-namespace referenced in dwc:taxonID to indicate the GBIF API where the numeric value following the colon is used as the search key. Example: gbif:8102122. | Data | GEOGRAPHY | A combination of Darwin Core administrative geography terms dwc:continent, dwc:country, dwc:countryCode, dwc:stateProvince, dwc:county, dwc:municipality. | Information Element | GUID | Gobally Unique Identifier. In this document, the GUID for a test is a UUID (128-bit universally unique identifier) which identifies the test. | Data | GUID is intended to identify the tests for machine consumption, "Label" is used for human consumption. https://en.wikipedia.org/wiki/Universally_unique_identifier Incomplete | Where an Information Element (q.v.) does not contain sufficient information to satisfy the scope of the test. | Warning Type | Inconsistent | Where the Data Quality Dimension (q.v.): Consistency (q.v.) is not satisfied due to inconsistent values between the different Information Elements (q.v.) of a single record. | Warning Type | Information Element | An abstraction or a concrete term that represents relevant content (e.g., coordinates; dwc.decimalLatitude, dwc:decimalLongitude). | Fitness for Use Framework | In the framework, Information Elements may be abstract or concrete. For the test descriptions, information elements are concrete Darwin Core terms, to remove ambiguity for implementors. INTERNAL_PREREQUISITES_NOT_MET | A Response.status (q.v.) where values of the Information Element were insufficient to run the test. If the test is run at a later time on unmodified data, it should produce the same Response. | Response.status | Interpreted As | (1) For Implementors, where Darwin Core data are serialized as strings, but the test refers to data as numeric or other non-string data type, can the string value be parsed into the target data type in the language of implementation (e.g., "1" as the integer 1), (2) matching a representation of a value unambiguously onto a controlled vocabulary (e.g., ‘WGS84’ to ’EPSG:4326’), or (3) interpreting the representation of a numeric value (e.g., a roman numeral) as a number (e.g., an integer). | Data | Invalid | Where the Data Quality Dimension (q.v.): Conformance (q.v.) is not satisfied due to Information Elements (q.v.) containing non-standard values. | Warning Type | ISSUE | A class of data quality test from the Fitness for Use Framework that flags problems. In the context of the tests, ISSUE(s) are all POTENTIAL_ISSUE(s) (q.v.) where potential problems are flagged and may need examination by the user to determine if data have quality for their use. | Test Type | IS_ISSUE | A Response.result (q.v.) for an ISSUE (q.v.) that flags where the data do not have sufficient quality for a use. | Response.result | Likeliness | The likelihood of Darwin Core Term(s) having true or expected values. | Data Quality Dimension | Definition from the Fitness for Use Framework: Data Quality Dimensions Document (**Link needed to RDF document ** - https://github.com/tdwg/bdq/wiki/TG2-Data-Quality-Dimension). MEASURE | A class of data quality test that reports numeric values of 1) the count of the number of tests of type VALIDATION (q.v.) run where the Response.result (q.v.) was "NOT_COMPLIANT", 2) the count of the number of tests of type VALIDATION (q.v.) run where the Response.status (q.v.) was "PREREQUISITES_NOT_MET", 3) count of the number of tests of type AMENDMENT (q.v.) run where the Response.status (q.v.) was "AMENDED" or 4) the duration of an event in seconds. | Test Type | Differs to the definition in the Fitness for Use Framework non-printing characters | ASCII 0-32 and 127 decimal. Non printing characters or formatting marks that are not displayed at printing. These may include pilcrow, space, non-breaking space, tab character. etc. For the purposes of the tests they are treated as EMPTY. | Data | NOT_AMENDED | A Result.status (q.v.) that indicates that a response for an AMENDMENT (q.v.) proposed no change. | Response.status | NOT_COMPLETE | An assertion of a MEASURE (q.v.) on a multi record where not all the VALIDATION (q.v.) Response.results (q.v.) from all included records in the dataset are COMPLIANT (q.v.). The scope in the Fitness of Use Framework is broader. | Response.result | NOT_COMPLIANT | A Response.result (q.v.) of a VALIDATION (q.v.) where the data do not conform to the Test Criteria (q.v.). | Data | NOT_ISSUE | The response of a test (q.v.) of type ISSUE (q.v.) where no potential problems were detected. | Response.result | NOTEMPTY | The value of an Information Element (q.v.) that is present and has content (cf. EMPTY (q.v.)) | Data | null | A value that is used in some databases to signify that a value is unknown or missing. It may be represented in serializations by "NULL", "Null", "null". "/n", "9999", etc. These should be treated as NOTEMPTY. | Data | OUTOFRANGE | The value in an Information Element (q.v.) that is outside an acceptable range for that Information Element. | Response | Use in Response.qualifier or Response.comment. parameter | A value provided to a test that changes the behavior of a test to fit a particular user need within the scope of the test. Either 1) a link to a bdq:sourceAuthority (q.v.) to find matching values, or 2) a value used to define limits for an Information Element (q.v.). | Data | paramaterized test | A test that allows a parameter (q.v.) to be set prior to the test being run. Where a parameter value has not been provided, a default is specified within the test. | Test attribute? | POLYNOMIAL | Represents a combination of the Darwin Core terms dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet. | Information Element | See test "VALIDATION_POLYNOMIAL_CONSISTENT" (17f03f1f-f74d-40c0-8071-2927cfc9487b) POTENTIAL_ISSUE | A Response.result (q.v.) for an ISSUE (q.v.) that flags where the data may not have sufficient quality for a use. See also ISSUE (q.v.) and NOT_ISSUE (q.v.). The user will need to evaluate if the data is fit for their particular use or not. | Response.result | PRECISIONINSECONDS | The length of the period of an event in seconds. | Response | This is description of the Response.result from this measure, where the result is a numeric value in seconds. See Test "MEASURE_EVENTDATE_DURATIONINSECONDS" (56b6c695-adf1-418e-95d2-da04cad7be53). PREREQUISITESNOTMET | A test of type MEASURE (q.v.) that counts the number of tests of type VALIDATION (q.v.) that did not run due to one or more prerequisites not being met (e.g. INTERNAL_PREREQUISITES_NOTMET (q.v.) and EXTERNAL_PREREQUISITES_NOTMET (q.v.)) | Response | See test "MEASURE_VALIDATIONTESTS_PREREQUISITESNOTMET" (49a94636-a562-4e6b-803c-665c80628a3d). PROPOSED | A test of type MEASURE (q.v.) that pertains to an AMENDMENT (q.v.) where an action to modify a value in some way through a change or addition is recommended. | Response | Example see test "MEASURE_AMENDMENTS_PROPOSED" (03049fe5-a575-404f-b564-ae63f5a1cf8b). rdfs:label | See: https://www.w3.org/TR/rdf-schema/#ch_label | RDF representations | skos:preferredLabel/skos:label may be prefered. Reliability | Measure of how the data values agree with an identified source of truth. The degree to which data correctly describes the truth (object, event or any abstract or real 'thing'). | Data Quality Dimension | Definition from the Fitness for Use Framework: Data Quality Dimensions Document (**Link needed to RDF document ** - https://github.com/tdwg/bdq/wiki/TG2-Data-Quality-Dimension). Resolution | Refers to the data having sufficiently detailed information. Measure of the granularity of the data, or the smallest measurable increment. | Data Quality Dimension | Definition from the Fitness for Use Framework: Data Quality Dimensions Document (**Link needed to RDF document ** - https://github.com/tdwg/bdq/wiki/TG2-Data-Quality-Dimension). Response | The report from a single execution of a single test, consisting of Response.status, Response.result, Response.comment, and optionally, Response.qualifier. | Response | Parent of RESULT and RESULT_STATUS in the Fitness for Use Framework (Viega et al. 2017). Response.comment | Human readable interpretation of the results of the test. | Response | Response.qualifier | Additional structured information that qualifies the Response (q.v.), intended as an extension point for uncertainty. | Response | Response.result | The element in a Response (q.v.) containing the value returned by the particular test (VALIDATION, AMENDMENT, MEASURE, or ISSUE) | Response | Response.status | A metadata element in a Response (q.v.) indicating whether a particular test (Validation, Amendment, Measure, or Issue) was able to be performed or not. | Response | Roman numerals | Roman numerals are interpreted as the equivalent integer for months (e.g. "X" as "10") in appropriate tests. Roman numerals may not be unambiguously interpreted for other Darwin Core terms such as dwc:day or in text fields as they may mean unknown or something else entirely. | Data | RUN_HAS_RESULT | A Response.status (q.v.) that implies that a result was correctly generated. | Response.status | Applies to VALIDATIONS, MEASURES, and ISSUES, but not AMENDMENTS. See Fitness for Use Framework definition in Need link to OWL Document @chicoreus. See also INTERNAL_PREREQUISITES_NOT_MET (q.v.) and EXTERNAL_PREREQUISITES_NOT_MET (q.v.) single record | A record from a dataset without dependencies on any other record. | Resource Type | All the current tests are run on a SingleRecord (q.v.), of Darwin Core data, and not designed to be run across a MultiRecord (q.v.), except for MultiRecord Measures. Specification | A technical description of the performed test upon which an implementation could be made. | Response | Source Authority | A vocabulary or standard to use to look up a value (or a supplied numerical value in a parameterized test) in an Information Element (q.v.). See also bdq:sourceAuthority (q.v.). | Parameter | STANDARD | An AMENDMENT (q.v.) where a value in an Information Element (q.v.) is proposed from a bdq:sourceAuthority (q.v.). | Response | Use in Response.qualifier (q.v.) or Response.comment (q.v.) STANDARDIZED | An AMENDMENT (q.v.) where a STANDARD (q.v.) value for an Information Element (q.v.) is proposed. | Response | Use AMENDED as the Response.status (q.v.), report STANDARDIZED in a Response.qualifier (q.v.) or in a Response.comment (q.v.). TERRESTRIALMARINE | A terrestrial taxon that has geographic coordinates that fall within terrestrial boundaries; or a marine taxon that has geographic coordinates that fall within marine boundaries. | Response | Use AMENDED as the Response.status (q.v.), report TERRESTRIALMARINE in a Response.qualifier (q.v.) or in a Response.comment (q.v.). See test "VALIDATION_COORDINATES_TERRESTRIALMARINE" (b9c184ce-a859-410c-9d12-71a338200380). Test prerequisite | Conditions that must be met for a test to be run (e.g., fields having values, tests that need to be run before the current test, availability of a bdq:sourceAuthority (q.v.)) | Test attribute | See for example, INTERNAL_PREREQUISTES_NOT-MET (q.v.) and EXTERNAL_PREREQUISITES_NOT_MET (q.v.). Test type | There are four types of tests, viz. VALIDATION (q.v.), AMENDMENT (q.v.), ISSUE (q.v.), and MEASURE (q.v.) | Test attribute | TRANSPOSED | The sign and/or value of one or more Information Elements (q.v.) were swapped. | Response | Use AMENDED as the Response.status (q.v.) report TRANSPOSED in a Response.qualifier (q.v.) or in a Response.comment (q.v.). See Test "AMENDMENT_COORDINATES_TRANSPOSED" (f2b4a50a-6b2f-4930-b9df-da87b6a21082). Unlikely | The Data Quality Dimension (q.v.): Likeliness (q.v.) is not satisfied due to the Information Elements (q.v.) containing a value that is not likely to occur (for example where the geographic coordinates are "0", "0"). | Warning Type | Needs a Response.qualifier (q.v.) response for the uncertainty. VALIDATION | Tests on one or more Darwin Core terms within a single record (q.v.) based on defined Test Criteria (q.v.) and with a Response.result (q.v.) of either COMPLIANT (q.v.) or NOT_COMPLIANT (q.v.). | Test Type | Varies from the definition in the Fitness for Use Framework. VERBATIM | An original value. | Information Element | Warning Type | Assertion resulting from running a test, one of: Ambiguous (q.v.), Incomplete (q.v.), Inconsistent (q.v.), Invalid (q.v.), Unlikely (q.v.). | Test Descriptions | Currently categorization in the human readable test descriptions only, not carried into the formal definitions. White space | 1) A field that only includes white space (blanks) is treated as EMPTY (q.v.). 2) In VALIDATION tests (q.v.) that require the looking up a Source Authority (q.v.), leading and/or trailing white space will cause the test to fail as no preprocessing is carried out on the data. These leading and trailing white spaces may be stripped out in a subsequent AMENDMENT (q.v.). and thus pass when the VALIDATION test is run again. | Data | YEARMONTHDAY | Represents a combination of the Darwin Core terms dwc:year, dwc:month, dwc:day. | Information Element | YEARSTARTDAYOFYEARENDDAYOFYEAR | Represents a combination of the Darwin Core terms dwc:year, dwc:startDayOfYear, dwc:endDayofYear. | Information Element |ArthurChapman
commented
11 months ago OK - I have added all the bdqffdq: terms from Paul's OWL into the Vocabulary (#152).
In doing so, I have made a number of spelling corrections, Upper/lower case corrections, etc. and added the bdqffdq: prefix to the terms within the definitions.
I have added all the terms into the Vocabulary in alphabetical order ignoring the namespace prefix.
@chicoreus: I have added the Contexts as
"FFU Framework: Class"
"FFU Framework: ObjectProperty"
"FFU Framework :individualName"My next step is to look at all the other terms (bdq: etc.) and other terms in the document that don't need a prefix as they are common english terms.
I think there may be quite a few other issues that will arise during that exercise and that may need some modification of the tests - for example if we are using terms that have a space in them, then they will not expand to a useable URI (e.g. single record" - I've yet to look, but there may be others and if so, we will need to change the format of that term etc.)
@chicoreus has stated that we do not need to add bdq: as a prefix within the specifications but that they should be added into the Vocabulary, and a note must be made in the Document to the effect TODO
that the use of a vocabulary term in a test specification means the bdq: or bdqffdq: namespace appliesI have identified a number of issues that need discussing or where a decision needs to be made. Below are some issues that I have identified
1. **Duplications:** These need to be combined or we have two terms (bdq: and bdqffdq:) I see some advantages in having two definitions (as we can then use upper case terms for AMENDMENT, VALIDATION, etc. in the tests, but we could also combine them under the bdqffdq with a Note to their use in the Tests. This has been partly done by @chicoreus in the bdqffdq definitions, but it needs work. I think Measure and Issue are OK as is, but with mention of the Upper Case? **TODO - Especially wrt reference to All UPPER CASE**
bdqffdq:Amendment versus bdq:AMENDMENT
bdqffdq:Validation versus bdq:VALIDATION
bdqffdq:Measure versus bdq:MEASURE
bdqffdq:ISSUE versus bdq:ISSUE
2. Some of the definitions in the bdqffdq could be improved more in line with the bdq: definitions as some are cyclical (see bdqffdq:DataResource and bdqffdq:Enhancement) in their definition and many repeat the term unnecessarily in the definition.
3. Two terms need looking at (similarly to 1 (above) with respect to combining) - perhaps we need to roll Data Quality Dimension into bdqffdq:Dimension or combine into a new term bdqffdq:DataQualityDimension. I believe we are using Dimension in a more restricted way than is generally accepted in the literature, so perhaps refining the name to **dqffdq:DataQualityDimension** may be a sensible way to go. In any case - something needs to be done as "bdq:Data Quality Dimension" won't work. If kept as two terms we'd need to change the name of the bdq: term. Note - a similar situation applies to Report **TODO**
bdqffdq:Dimension versus bdq:Data Quality Dimension
bdqffdq:Report versus bdq:Data Quality Report
4. I have combined the "bdq:Information Element" with bdqffdq:InformationElement. This is another where the space would not have worked - perhaps we need to change the name of the term in the Document and in the tests to InformationElement **TO DISCUSS**
5. I changed Paul’s definition of **bdqffdq:ResultStatus** from:Depending on the assertion type would have values of COMPLIANT or NON_COMPLIANT for a Validation, COMPLETE or NOT_COMPLETE for a Measure, CURATED, FILLED_IN,TRANSPOSED, NO_CHANGE for an Amendment and HAS_PROBLEM NO_PROBLEM for a Problem
To:Depending on the assertion type would have values of COMPLIANT or NON_COMPLIANT for a bdqffdq:Validation, COMPLETE or NOT_COMPLETE for a bdqffdq:Measure, AMENDED, FILLED_IN, TRANSPOSED, NOT_AMENDED for an bdqffdq:Amendment and IS_ISSUE, POTENTIAL_ISSUE or NOT_ISSUE for a bdqffdq:Issue
However, this definition doesn't seem right for MEASURE - We don't have COMPLETE and NOT_COMPLETE for Measure in the tests **TO DISCUSS**
7. Throughout the definitions we have “FFDQ” mentioned in the definitions (e.g. “The report bdqffdq:Result concept in FFDQ is represented as a value or a status …” I think we could dispense with “in FFDQ” in most instances.
8. I have changed the following form Paul's OWL
bdqffdq:ProblemProperties to bdqffdq:IssueProperties
bdqffdq:ProblemMethod to bdqffdq:IssueMethod
bdqffdq:ProblemPolicy to bdqffdq:IssuePolicyTerms in the bdq:name space that will need modification because of included space: Suggestions are in Brackets - note that these may cause changes to the Tests as well as the Standards Document
ArthurChapman
commented
11 months ago Changed Context "Test attribute" to "Tests" in two terms (Test prerequisite and Test Type)
ArthurChapman
commented
11 months ago "Warning Type" Removed from Vocabulary and a note added to bdq:DataQualityDimension" to cater for the Fail of NOT_COMPLIANT Assertions of Unlikely, Invalid, etc.)
ArthurChapman
commented
11 months ago I have extensively revamped and edited the Vocabulary including
A few issues:
chicoreus
commented
11 months ago On Fri, 08 Sep 2023 14:50:43 -0700 Arthur Chapman @.***> wrote:
- Need to add "ActedUpon and a definition provided @.***)
If we choose to do so, will also need Consulted. If we do, we will need to add these to each information element (that's done for all the implemented tests, as the java implementations provide @Consulted or @ActedUpon annotation for each information element.
ActedUpon, an information element that a test makes an assertion about.
Consulted, an information element that a test examines the content of in making assertions about one or more ActedUpon information elements.
- Can we delete bdq:ExpectedResponse in GitHub and Vocabulary and replace with bdqffdq:Specification?
We probably can't. The Specification in the csv of the tests is built from the combination of Expected Response and Source Authority.
Expected Response shouldn't go in the vocabulary, just in the supplement at the end of the text that describes the rows in the markdown table.
A Specification is a technical description of a test, and for our tests that isn't complete unless we include both the expected response logic and the source authorities referenced in that logic.
- Need a definition for bdqffdq:MultiRecord @.***)
Stake in the ground:
"A data set composed of one or more SingleRecord."
- Should bdq:Specification be a bdqffdq:Specification Cf. bdqffdq:Mechanism @.***)
Yes, Specification is in the bdqffdq namespace.
-Paul
-- Paul J. Morris Biodiversity Informatics Manager Museum of Comparative Zoölogy, Harvard University @.*** AA3SD PGP public key available
ArthurChapman
commented
11 months ago Added : bdq:ActedUpon and bdq:Consulted and definition of bdqffdq:MultiRecord as above comment by @chicoreus
ArthurChapman
commented
11 months ago @chicoreus - please check wording of these
Added;
| bdqffdq:AmendmentReport | AmendmentReport | A Data Quality report level concept that results from a bdqffdq:Amendment that proposed changes to a bdqffdq:InformationElement. | FFU Framework: Class | Veiga et al. (2017). |
| bdqffdq:IssuesReport | IssuesReport | A Data Quality report level concept that results from a bdqffdq:Issue that flagged a problem in a test as bdq:IS_ISSUE, bdq:POTENTIAL_ISSUE or bdq:NOT_ISSUE. | FFU Framework: Class | Veiga et al. (2017). |
| bdqffdq:MeasurementReport | MeasurementReport | A Data Quality report level concept that describes the results of a run of a test that performs a measurement according to some data quality dimension. | FFU Framework: Class | Veiga et al. (2017). |
| bdqffdq:ValidationReport | ValidationReport | A Data Quality report level concept that reports the results of a run of a bdqffdq:Validation test on some data. | FFU Framework: Class | Veiga et al. (2017). |
Amended Wording (largely) to change to needs level concepts
| bdqffdq:Amendment | Amendment | A Data Quality needs level concept that describes a run of a test that proposes changes based on some data quality enhancement. The AMENDMENT concept in the Tests involves data that were amended by modification or addition of a value or values following defined bdqffdq:Criteria of a run result that includes a status of (bdq:AMENDED, bdq:FILLED_IN, bdq:TRANSPOSED, etc) as well as the proposed changes to values from the original data. | FFU Framework: Class | Formally in the Fitness for Use Framework (Veiga et al. 2017), the description of a test that can propose a change is a bdqffdq:Enhancement, while the corresponding report level concept is a bdqffdq:Amendment. |
| bdqffdq:Issue | Issue | A Data Quality needs level concept that flags issue or problems with the data. In the context of the tests, bdqffdq:Issue(s) are all either bdq:POTENTIAL_ISSUE, bdq:IS_ISSUE or bdq:NOT_ISSUE where potential problems are flagged and may need examination by the user to determine if data have quality for their use, or bdq:NOT_ISSUE . | FFU Framework: Class | Veiga et al (2017). |
| bdqffdq:Measure | Measure | A Data Quality needs level concept that describes a run of a test that performs a measurement according to some data quality dimension. In FFDQ, the Measure concept consists of a run result of COMPLETE or NOT_COMPLETE, a value of the measurement (i.e. a measure of dwc:eventDate duration in seconds) or counts of the number of tests from a run where bdq:Response.result was bdq:NOT_COMPLIANT, or bdq:PREREQUISITES_NOT_MET in bdqffdq:Validation tests, or was bdq:AMENDED in bdqffdq:Amendment tests. | FFU Framework: Class | Veiga et al. (2017). |
| bdqffdq:Validation | Validation | A Data Quality needs level concept that describes a run of a test for validity. The bdqfdfq:Validation concept in the Tests consists of a run with a bdq:Response:result of bdq:COMPLIANT or bdq:NOT_COMPLIANT and a bdqffdq:Criterion that describes the conditions for validity that result in a status of bdq:COMPLIANT. | FFU Framework: Class | Veiga et al. (2017). |
ArthurChapman
commented
11 months ago Modified description of DataQualityDimension to:
| bdqffdq:DataQualityDimension | DataQualityDimension | Describes the aspect of data quality (accuracy, precision, completeness, etc.) that a test examines. For example, "precision" in "coordinate percision of single records". Includes Completeness (q.v.), Conformance (q.v.), Consistency (q.v.), Likeliness (q.v.), Reliability (q.v.), and Resolution (q.v.). | FFU Framework: Class | Note that the fail (bdq:NOT_COMPLIANT) assertions from running a test are one of: bdq:Ambiguous, bdq:Incomplete, bdq:Inconsistent, bdq:Invalid, or bdq:Unlikely. |
And deleted bdqffdq:Dimension
ArthurChapman
commented
11 months ago Rolled bdqffdq:Report into bdqffdq:DataQualityReport. deleted bdqffdq:Report @chicoreus please check the wording
| bdqffdq:DataQualityReport | DataQualityReport | A set of bdqffdq:Assertions (bdqffdq:Measures, bdqffdq:Validations bdqffd:Issues and bdqffdq:Amendments) that represent the output of a test run produced by a bdqffdq:Mechanism and designed to assess the fitness for use of the tested data for a particular purpose. | FFU Framework: Class | Veiga et al. (2017). | Fitness For Use Framework | |
ArthurChapman
commented
11 months ago Modified the definition of bdqExpectedResponse to:
| bdq:ExpectedResponse | ExpectedResponse | bdq:ExpectedReponse is one of the properties of a bdqffdq:Specification used in the markdown of the tests in the bdq GitHub. | bdq:Response | |
ArthurChapman
commented
11 months ago Added a new tern
| bdq:testField | testField | Column heading in the markdown of the tests in the bdq GitHub that list all the normative and informative metadata elements that describe a Data Quality Test | Test | |
ArthurChapman
commented
11 months ago Modified the definitions of:
| bdq:ActedUpon | ActedUpon | A bdqffdq:InformationElement that is the primary focus of a test | bdqffdq:InformationElement | |
| bdq:Consulted | Consulted | A bdqffdq:InformationElement that was referenced in a test but was not the primary focus of the test. | bdqffdq:InformationElements | |
Tasilee
commented
11 months ago Added three entries relating to the three unique column headers in the ValidationData
"LineNumber","dataID","LineForTest" to vocabulary under bdq: namespace.
Please check. I am unsure how we format these and 'Validation Data'/'ValidationData' etc.
ArthurChapman
commented
11 months ago Added term for @Tasilee additions above and changed Context from ValidationData to bdq:ValidationData
| bdq:ValidationData | ValidationData | Test data set established for testing Test Implementations | Data | |
ArthurChapman
commented
11 months ago Finished pass through edit especially of all bdq: and bdqffdq: name spaces.
ArthurChapman
commented
11 months ago Changed bdq:ActedUpon and bdq:Consulted to "bdqffdq:ActedUpon and bdqffdq:Consulted following email from @chicoreus
ArthurChapman
commented
9 months ago Changed the name or the Issue to better reflect the current situation where the Vocabulary includes all terms being used for the proposed Standard.
ymgan
commented
7 months ago From the standards document section 1.7
Contexts (Contextualized Criterion, Contextualized Dimension, ContextualizedEnhancement, ContextualizedIssue) relate the specification of a need, such as a Validation, to the information elements that need to be examined, and to the resource type that is operated on.
I think we missed the term bdqffdq:ContextualizedDimension in this issue
ArthurChapman
commented
7 months ago @chicoreus. I think @ymgan is correct here (good pick up)- I note we do have have "bdqffdq:dimensionInContext" which references bdqffdq:ContextualizedDimension. Do you have the definition in your files or should I attempt to define?
Tasilee
commented
7 months ago @ArthurChapman : Ming has (neatly) picked up that "ContextualizedDimension" is used by Paul in Section 1.7 of the standard doc but not in the Vocabulary.
ArthurChapman
commented
6 months ago @ymgan - Contextualized Dimension was in the vocabulary, but was missing a leading "|" and thus followed on the previous definition. All fixed
ArthurChapman
commented
6 months ago I have updated the Table. I have created a Supplement at the end of the table for terms that will not form part of the Standard - they include the GitHub Label terms that we use to manage the GitHub, and TestField terms from the GitHub Test Specifications. Many of the definitions of the TestField terms have been taken from the draft Standards Document.
Please check the definitions, making special note of any TestField definitions as these, if changed, will need to be updated in the Standards Document.
@tasilee - I notice that in the Standards Document there is not a definition of References - only examples. This will need updating.
Tasilee
commented
6 months ago Suggest change for "Supplementary" definition
A tests that is regarded as not CORE for a number of reasons such as not being widely applicable, informative, or straight forward to implement. cf bdq:CORE
to
A non-CORE (cf bdq:CORE) test defined as one or more of: Not being widely applicable; not informative concerning the 'quality' or lack of quality of the data; likely to return a high percentage of either bdq:COMPLIANT or bdq:NOT_COMPLIANT results (cf bdq:Response.result). A Supplementary test may be implemented as CORE if a suitable use case exists.
Tasilee
commented
6 months ago Suggest changing definition of DO NOT IMPLEMENT from
A potential test that it is not recommended be implemented because it is too difficult (e.g. because available vocabularies are ambiguous), it is too difficult to code, or implementation could lead to ambiguous of inaccurate results.
to
A non-CORE (cf bdq:CORE) test not recommended to be implemented with the level of understanding at the time, for one or more of the reasons: Unavailable controlled vocabularies; available vocabularies are ambiguous; too complex to implement; implementation could lead to ambiguous or inaccurate results.
ArthurChapman
commented
6 months ago @tasilee - You suggest DO NOT IMPLEMENT because of "Unavailable controlled vocabularies" - in those cases I would suggest they belong in "Immature/Incomplete".
So suggest DO NOT IMPLEMENT
A test that is not CORE (cf bdq:CORE) and not recommended to be implemented with the current level of understanding, for one or more of the reasons: available vocabularies are ambiguous; the test is too complex to implement; implementation could lead to ambiguous or inaccurate results.
chicoreus
commented
6 months ago Current definition of CORE needs correction.
"CORE Fundamental tests of biodiversity data represented in Darwin Core terms that are widely applicable, informative, and straight forward to implement. Developed from use cases derived from needs analyzed by user stories."
This is conflating two different concepts of CORE (which we have been able to get away with up until recently because they have entirely overlapped, but can't any more as there are new tests under discussion that fit only one concept but not the other).
Concept 1: CORE: this is the UseCase (sensu the framework) developed by TG3, and is what is meant by "Developed from use cases derived from needs analyzed by user stories." This is the UseCase of research analysis of data indicating what organisms occurred where when.
Concept 2: CORE: The set of mature tests that TG2 is putting forward as part of the standard. This is the bit meant by "Darwin Core terms that are widely applicable, informative, and straight forward to implement" This concept (now) includes multiple UseCases, of which the first concept of CORE is one, but quality control of checklist data with relationship to invasive species is another (less clearly spelled out use case).
We need to fix CORE to mean exactly one of these two things, and coin a term for the other.
Multiple discussions in issues about what is CORE and what is supplementary are confused by the conflation of these two distinct concepts.
Also, "Fundamental tests of biodiversity data" needs to include the phrase "fitness for use".
Tasilee
commented
6 months ago My understanding is that TG3 use cases 'informed' but didn't 'circumscribe' our CORE tests. TG3 has been closed for years and use cases are continually evolving (along with Darwin Core). Could I suggest something like
Tests of biodiversity data (represented by Darwin Core term values) that have been informed by TG3 use cases, that are widely applicable, informative in terms of fitness-for-use (or lack of it), and are readily implementable without ambiguity. Tests that are not considered CORE are bdqtag:Supplementary or bdqtab:NO NOT IMPLEMENT or bdq:Immature/Incomplete.
Terms in the bdqffdq namespace are from the Fitness for Use Framework (Viega et al. 2017). Use the reference to the Framework Definitions for more details and examples. The use of a vocabulary term in a test specification without a namespace prefix (sometimes represented in all UPPER CASE), implies that the bdq: or bdqffdq: namespace is applicable. Note that wherever "DQ" is used in a definition it implies "Data Quality" and wherever "FFU Framework" is used it refers to the "Fitness for Use Framework" (Veiga et al. 2017).
Note: There are two tables in this issue, the first is for vocabulary for the standard, the second is for additional terms for supplement files that will go into tables in those documents rather than controlled vocabularies.
Do not edit, moved to csv files
Pending further splits, this vocabulary moved to https://github.com/tdwg/bdq/blob/master/tg2/vocabularies/combined_vocabulary.csv
Supplement: GitHub Label Terms These are terms that are outside the Standard but that have been used as either GitHub Labels or TestFields in the BDQ GitHub
Do not edit, moved to csv files
Pending further moves, this vocabulary moved to https://github.com/tdwg/bdq/blob/master/tg2/vocabularies/glossary_terms.csv