The application guidelines specify how we apply the feedback model within GeoViQua. This document is one of several artifacts of the feedback model developed in Task 6.2.
The feedback model is generally intended for user feedback, and producer feedback that is changing more rapidly than official metadata for which more quality cotrol is implied.
The model is intended to connect GEOSS datasets and services to user data. User-centric information such as accounts and authentication and GEOSS concepts are therefore not represented directly, but are linked in at pre-defined junction points. These junction points are the user information and the target.
While the model sometimes refers to ISO191xx schema elements, it is not intended to be seen as metadata or directly related to it. The ISO elements are included to ease interoperability in cases where a producer decides to include user-suggested data into the official metadata he maintains, or other cases where a common data set is of advantage.
The feedback model consists of an Enterprise architect UML model and diagram, two xml schema files, and the application guidelines (this document). Likely, a JSON mapping will also be developed.
The feedback model’s main classes are
- User Information
- Feedback Item
- Feedback Target
in rough order from user to the data set in question.
The user information contains self-asserted information about the user which may be used to (assist in) qualifying the feedback he produces. The model contains this class as a clear handover point to the implementation’s user management, and to illustrate data an implementation should know about its users.
The feedback item is an instance of user feedback, for example, a comment on a data set backed by a report. Each item is associated to one or more targets, which define the context of the discussion in the item. Further, an item can be qualified e.g. with a subject or an application domain in which it applies.
The target points to a data set, resource, or something else which is pre-existent in the domain of discourse, and potentially also describes a sub-set of the resource to allow to narrow the discussion context as appropriate. The target as contained in the model is geared towards GEOSS resources.
The feedback model uses qualifiers to narrow the focus of an item. This intends to increase discoverability by enabling to submit and discover focused feedback. Some qualifiers are designed to be machine-comparable also for that reason.
In the following, the different types of qualifiers are discussed.
This is just a subject. A subject is used to qualify feedback that may be be sufficiently qualified by other means. It just contains a title/subject text and can be regarded as a sort of free-form qualification of input.
The feedback qualifier qualifies feedback to pertain to other feedback. In the primary role, this states the feedback to be an answer to some other feedback in the system.
The tag qualifier associates tags parts of a so-called folksonomy to the feedback item. Such free-form memes are often aggregated in “tag clouds”, allowing a community to reach an informal understanding of these tags. The precision of such features is debateable, but in social networks they are often considered essential.
The targets of an item describe its context, guided by one of the three possible roles primary, secondary and supplementary which define how a target is relevant to an item. Targets are intended to be comparable to each other, resulting in a comparison results such as “identical”, “overlapping” or “disjoint”, helping to establish an order of how relevant feedback is to a circumscribed issue.
Primary targets specify the subject of the item, i.e. point to the data sets or resources the feedback is about.
A secondary target refers to referenced resources, implying that the item might be releavant to the referenced resource.
A supplementary target adds additional references, for example, another region in another data set with similar problems. It is used to formally model references that somehow are related to the feedback item at hand, but does not imply that the feedback is relevant for the referenced subject. Giving an example should be modeled as a supplementary target.
This section discusses issues specific to the application of the feeback model to perform certain tasks. Since GeoViQua will implement some kind of feedback server or infrastructure, the tasks are derived from this setting.
A server answer is best encoded in a feedbackCollection xml schema element (or an equivalen in another encoding). All targets and feedback groups relevant in an answer can be placed in this element.
Submission should also be based on the feedbackCollection (or analoguous elements of other encodings). On submisson, applicable constraints should be checked by a server application in charge of persisting the information.
The application guidelines are intended to clarify how the model is to be applied. It is to become a “real” document, perhaps from input on this page. In the following, use cases and ther application is discussed.
- One feedback item
- with one primary target for the data set
- containing the rating (with justification if desired)
- the item has a “wheather forecasting” domain qualifier
This works as described for a domain-specific rating, except that the target will have its extent specified. If more than one “hotspot” is involved, multiple extents can be added to the target.
This would work by first finding a URN within the applicable ontology, e.g. GEMET concepts.
Then, all DominFocuses with the URN are identified and the feedback items which have the matching DomainFocus are being searched. This corresponds to a SQL join if the database schema is crafted carefully.
To the user, the containing feedback groups may be of most interest as they group the feedback to the units in which it is intended to be understood.
This section discusses constraints that (may) make sense within GeoViQua, but are not enforced at the conceptual model or XSD level.
This is a bit dependent on how large a feedback group makes sense. If we allow to extend feedback groups, e.g. to allow a group of people to submit feedback together, then this restriction is probably pointless.
We could require one or more domain foci to be added to each feedback item. With user accounts and sensible defaults this might lead to better qualified feedback.
The target is not really intended to be defined within the model. Potentially the target should solve the problem of creating referenceable hierarchies and could be shared with other models, i.e. from a feedback perspective it merely establishes the context that really lives outside in GEOSS.
It has been decided that, for the purpose of modelling feeback, the existence of a globally unique identifier for the referenced resources can be postulated.
As far as we could determine, that is not the case within GEOSS. For prototyping and evaluation that may be acceptable, but later on there would need to exist a service of some kind which is capable of canonicalizing dataset identifiers.
Not every feedback target can be assumed to have an identifier, because GEOSS datasets are of mixed granularity. As a result, targets need to be able to discern concepts that are accumulated at the granularity that can be identified using well-defined identifiers. In other words, it may well by needed to specify how resources known to exist can be identified in a “synthetic” manner to allow feedback submission and discovery.
For example, a dataset may be organized into layers which do not have a GEOSS identifier. To be able to target such a layer, the targets should be equipped with a locally unique (within the dataset) layer identifier (e.g. a name) and a parent target which contains the actual GEOSS identifier (possibly canonicalized).
The first user domain, if known, may be advertised as default in the UI for generating feedback. Thus, a default domain focus would be added which matches the user’s background.
GEMET concepts seems a good candidate for a domain ontology, which would be used to properly identify relevant feedback. Also see the search comments use case.