2.1. administrative change

2.2. critical change

2.3. substantive change

3.1.  Scope

The GUF v2.0 OGC™ Standard defines a data model for encoding user feedback about geospatial datasets or metadata records describing datasets. It reuses and extends the v.1.0 of the GUF conceptual model (OGC 15-097r1) as well as ISO 19115-1:2024 data model and it is applicable to metadata catalogue servers and clients that want to exchange geospatial user feedback information.

Geospatial User Feedback as used in this standard encompasses: user comments, questions and answers, user reports of dataset problems and proposed solutions to those problems, ratings, usage reports, reproducible usage reports, citations of related datasets or publications describing usage, quality reports, relevant additional provenance information, significant events related to the use or interpretation of a dataset.

This document lists, classifies, and explains the new features of version 2.0 compared to version 1.0 of the GUF standard and their implications. Among these changes, the definition of the new requirement and the new QCM_ReproducibleUsage class stand out, as they enable the description of the specific use of a resource in a reproducible way for other users. It also describes critical and substantial changes due to the definition of new data types, name changes, or changes in cardinality in elements previously existing in version 1.0, as well as administrative changes to resolve minor errors or improve some definitions.

Although most of the changes are additions or error fixes, even small changes to an XML document can lead to validation errors if older applications are using previous versions of the XML schemas. For this reason, we chose not to label the XML encoding as v1.1, but rather as v2.0. While the conceptual model could still be considered v1.1 (since no significant changes were made to the original concepts), this could lead to confusion with the versioning of the XML encoding. Ultimately, we decided to synchronize the version numbers and designate both as v2.0.

3.2.  Document contributor contact points

All questions regarding this document should be directed to the contacts provided below or the referenced standard editor(s).

Table 1 — Contacts

4.1.  KEY

See Clause 5 for more information on critical changes and Clause 6 for more information on substantive changes.

4.2.  Change table

Table 2 — Change Log

5.1.  ED-03: “problemDateTime” Element Data Type Changes

In GUF version 1.0, Table 5 in section 6.3 describes the QCM_DiscoveredIssue Data Type which is used to report issues found while using a certain resource.

QCM_DiscoveredIssue contains an element named “problemDateTime” designed to define the date and time a problem is detected by a user of that resource.

In GUF v.1.0, “problemDateTime” was defined as a CI_Date element, requiring users to specify both a “date” and a “dateType.” This could lead to inconsistencies with the “problemDateTime” element definition. As the “type of date” is included in the element name itself, no “dateType” is needed. Therefore, GUF v.2.0 updates the “problemDateTime” data type from “CI_Date” to “DateTime.”

5.2.  ED-04: “expectedFixDate” Element Data Type Changes

Similar to ED-03.

In GUF version 1.0, Table 5 in section 6.3 describes the QCM_DiscoveredIssue Data Type and is used to report issues found while using a certain resource.

QCM_DiscoveredIssue contains an element named “expectedFixDate” designed to define the date when a solution is expected to be released by the provider in the form of a “fixedResource” or directly as a fix in the original target resource.

In GUF v.1.0, “expectedFixDate” was defined as a CI_Date element, requiring users to specify both a “date” and a “dateType.” This could lead to inconsistencies with the “expectedFixDate” element definition. As the “type of date” is included in the element name itself, no “dateType” is needed. Therefore, GUF v.2.0 updates the “expectedFixDate” data type from “CI_Date” to “Date.”

5.3.  ED-11: GUF_FeedbackItem Data Type Element Name Update

For clarity purposes, Table 7 in section 7.2 describing GUF_FeedbackItem data type, the GUF v.1.0 “additionalLineage” element name is updated to “additionalLineageSteps” in the version 2.0. This element is defined as “Additional lineage steps not included in the producer metadata,” making the new element name more self-explanatory.

5.4.  ED-12: “userDetails” Element Data Type Changes

GUF v.1.0 GUF_UserInformation Data Type included the element “userDetails” defined as a CI_Responsibility type element and also a “userRole” element defined as GUF_UserRoleCode.

As CI_Responsibility Data Type contains an element named “role,” inconsistencies with the role described in the “userRole” element may appear.

To avoid this source of inconsistencies, GUF v.2.0 changes the “userDetails” element Data Type to CI_Party.

5.5.  ED-14: “applicationDomain” Data Type Changes

In GUF version 1.0, the GUF_UserInformation class had two attributes: applicationDomain (a set of text strings that could contain multiple values, i.e., CharacterString [0..*]) and expertiseLevel (a single value of type GUF_RatingCode). This setup allowed multiple application domains to be associated with a user, but only one expertise level could be defined.

This design presented a significant issue: there was no way to specify which application domain the expertise level referred to. This was problematic because it is likely that a user may have different levels of expertise for different application domains, but the current configuration could not represent this distinction adequately.

To fix this issue, the original “expertiseLevel” attribute is deprecated, and the “applicationDomain” attribute type is now GUF_ApplicationDomain Data Type and has a [1..*] cardinality. This data type allows documenting several “domains” (Character String) and the “expertiseLevel” (GUF_RatingCode) corresponding to each of them.

Related to ED-15 substantive change.

5.6.  ED-20: Updating Element Names in UFS_FeedbackSummary

In the GUF v.1.0 Standard, UFS_FeedbackSummary contained two elements named “minimumPossibleRating” and “maximumPossibleRating.” The names of these elements suggest the minimum and maximum of the scale of rating used, but their description indicates that their content is the minimum and maximum rating received among all the feedback items for a particular resource.

To clarify the meaning of these elements, GUF v.2.0 overwrites “minimumPossibleRating” and “maximumPossibleRating” elements with “minimumRating” and “maximumRating” elements.

5.7.  ED-21: UFS_FeedbackSummary New “numberOfReproducibleUsageReports” Element

As GUF v.2.0 adds the QCM_ReproducibleUsage class to the model (see ED-07 and ED-08) it is relevant to add a new element “numberOfReproducibleUsageReports” to UFS_FeedbackSummary Data Type. This element is mandatory, and is used to document the total number of populated reproducible usage reports for a particular resource.

6.1.  ED-01: New attributes in QCM_Publication Class.

The QCM_Publication Class (Table 2 of the documentation) extends CI_Citation and is dedicated to describing a publication element. To enhance this description and better capture “knowledge,” two new attributes have been added in this new version: “highlights” and “keywords.”

The cardinality of these two new attributes is “zero or more.” As they are optional attributes, no compatibility issues are expected with previous versions.

6.2.  ED-05: Changing cardinality in QCM_DiscoveredIssue attribute.

QCM_DiscoveredIssue describes an issue on the actual resource the publication is about. QCM_DiscoveredIssue contains a fixedResource attribute to describe a new version of the target resource where the known problem is no longer present.

The fixedResource attribute has changed its cardinality to “zero or more,” maintaining its optionality but accepting more than one value. This means that more than one fixed resource, if they exist, can be documented.

As it is still an optional element, no compatibility problems are expected.

6.3.  ED-07: New QCM_ReproducibleUsage requirement added.

GUF v.2.0 defines a MD_USAGE extension for describing the specific usage in a reproducible way (introducing a code snippet or a linkage to a script) of a resource by a user. This is a new “MD_Usage” requirement “QCM_ReproducibleUsage”.

As describing usage is optional, no compatibility issues are expected with previous versions.

6.4.  ED-08: New class QCM_ReproducibleUsage.

The new “QCM_ReproducibleUsage” requirement supports the following attributes to describe usage (Table 6 of the documentation):

As describing usage is optional, no compatibility issues are expected with previous versions.

6.5.  ED-13: New attributes in GUF_UserInformation Data Type.

Information about users includes a new optional element named “description” that supports documenting a user’s short description or bio.

As it is an optional element, no compatibility issues are expected.

6.6.  ED-15: New “GUF_ApplicationDomain” Data Type added.

In GUF v.1.0, the GUF_UserInformation Class had two attributes named “applicationDomain” (CharacterString [0..*]) and “expertiseLevel (GUF_RatingCode).” This configuration causes several application domains to may be described, but only one expertise level can be defined. Moreover without specifying to which of the application domains it corresponds (as is likely that the expertise level is not the same for all the application domains).

To fix this issue, in GUF 2.0 the original “expertiseLevel” attribute has been deprecated, and the “applicationDomain” attribute type is now GUF_ApplicationDomain Data Type and has a [1..*] cardinality. This data type allows documenting several “domains” (Character String) and the “expertiseLevel” (GUF_RatingCode) corresponding to each of them.

Related to ED-14 critical change.

This change may cause compatibility issues with GUF elements encoded following previous versions.