GEOSS Banner

3.3 The user quality model

The user quality model serves a purpose for both the user and the provider, which integrates any feedback from these two. The model is thought to provide a link between the data generated by a user (feedback data) and the GEOSS services or datasets (resources) which it refers to. These connections between user data and the resources are achieved by documenting the user information and its target.

To contribute to interoperability, ISO elements are included in the model for a producer to document data suggested by a user. This can be found in the GVQ_FeedbackItems.

 

    3.3.1 Classes of the conceptual model

    The user model’s main elements are the GVQ_FeedbackCollection, which contains one or more GVQ_FeedbackItems. These are individual feedback items that contain user information, feedback items, and the target.

GVQ_FeedbackItems can contain:

    • Mandatory information on the role of the user recording the feedback (e.g., ‘Commercial data producer’)
    • GVQ_UserInformation, the user information. (This may optionally contain information about the various roles in which the user has interacted with the resource on which they are commenting).
    • Information qualifying the focus of the feedback, such as its subject, application domain, whether it is a reply to other feedback and keyword tags
    • References to one or more targets (GVQ_FeedbackTarget); uniquely identified GEOSS resources or arbitrary subsets of those resources, qualified by the role they play within the feedback item.
    • References to other information related to the dataset (usages, citations, publications, comments,etc.)

   

The value of a feedback that a user provides could be assess through the information documented in the this class. The model contains this class as a clear handover point to the implementation’s user management, and to specify what an implementation should know about its users.

The feedback item (GVQ_FeedbackItem) is an instance of user feedback; for example, a comment on a data set backed by a report. Each item is associated with one or more targets, which define the context of the discussion in the item, this could be usefull when trying to identify significant feedback.

The target (GVQ_FeedbackTarget) defines the resource that it refers to, as well as describing a sub-set of it. The target as contained in the model is geared towards GEOSS resources.

These top‐level elements of the model are illustrated in Figure 20.

FeedbackCollection.png

Figure 20. A FeedbackCollection contains any number of FeedbackItems, which have targets referencing GEOSS resources

          

    3.3.1.1 Feedback foci and qualifiers

    An Item may refer to the entire resource or to an specific part of it. This can be done by using quilifiers or focis,  which could also be used for searching/discovery porposes. Some qualifiers are designed to be machine‐comparable for this reason. There are several types of focus and quilifiers:

  • GVQ_DataFocus quilifies the target by defining the extent (spatial, temporal, spectral bands,...) where the feedback apply, this is done as free text. The absence of a data‐centric focus for a target implies that the feedback applies over the entire resource. The relevant part of the model is shown in Figure 21.

          

    Data_centric.png

    Figure 21. Data-centric feedback focus defines the section of a target to which the feedback applies

  • Whithin the feedback item it can also be defined the Domain, which quilify the theme of the feedback (eg. 'health'). Here a URI should be provided to the ontology that follows a particular thesaurus. Feedback item may have 0 to many domain foci (see Figure 22).

  •          

  • Feedback Response qualifier (reply‐to) This qualifies a feedback item as pertaining to other feedback, which should be specified by a unique identifier. This states the feedback to be an answer to some other feedback in the system (see Figure 22).

        

  • Tag qualifier associates labels (tags) to the feedback item (see Figure 22). 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.

         

      Thedomain.png

      Figure 22. The domain, tags and reply-to qualifiers on a feedback item

  • Subject qualifier is just a subject. A subject is used to qualify feedback that may not 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(see Figure 23).

  • TheSubject.png

    Figure 23. The 'subject' qualifier of a feedback item

    3.3.1.2 Feedback target roles

    The targets of an item describes its context, guided by one of the three possible target roles: primary (dataset/resource to which the feedback refers to), secondary (it points to datasets/resources not directly related to the feedback, but which are important to the a user when searching for feedback  related to an specific dataset/resource) and supplementary ( additional information regarding other datasets that could have some similarities with the original dataset). They define how a target is relevant to an item. Targets are intended to be comparable to each other, resulting in a comparison result such as “identical”, “overlapping” or “disjoint”, helping to establish an order ofhow relevant feedback is to a circumscribed issue.

    Giving an example or pointing to data merely suspected to be relevant should be modeled as a supplementary target. As described, roles qualify the relevance of an item to a target. When trying to discover relevant feedback for a target, a possible way to deal with this could be ordering feedback linked by a primary role before any feedback which “is” secondary and then supplementary.

    All three types of target are illustrated in Figure 24.

    Targetsfeedback.png

    Figure 24. Primary, secondary and supplementary targets on a feedback item

3.3.2 Tasks

This section discusses issues specific to the application of the user model to perform certain tasks. (GeoViQua project is working to implement it)

    3.3.2.1 Encoding feedback catalogue answers

    A catalogue answer is best encoded in a FeedbackCollection XML element (or an equivalent in another encoding such as JSON). All feedback items relevant in an answer can be placed in this element.

    3.3.2.2 Submitting feedback

    Submission should also be based on the FeedbackCollection (or analogous elements of other encodings). On submission, applicable constraints should be checked by a server/catalogue service application.

3.3.3 Opportunities in the implementation of the user / feedback model

This section discusses constraints that (may) make sense within GeoViQua, but are not enforced at the conceptual model or XSD level. It also discusses options in the model which can allow the generation of tools to ease the production of metadata and user feedback.

    3.3.3.1 New elements

    3.3.3.1.1 Require domain qualifier

    We could require one or more domain qualifier to be added to each feedback item. With user accounts and sensible defaults this might lead to better qualified feedback.

    3.3.3.2 Default value recommendations for the user /feedback model

    To faciliate the population of the feedback model it is recomended to use some default values or automated usage reports. This automatisation could be of help and increase the use of the model. 

    3.3.3.2.1 Domain

    The first user domain, if known, may be advertised as default in the UI for generating feedback. Thus, a default domain qualifier would be added which matches the user’s background if s/he does not intervene.

    3.3.3.2.2 Role

    Some times a producer is also a consumer, and thus his/her role may vary depending on the situation. Therefore, each FeedbackItem contains a single mandatory role code which the user should specify. However, since there usually is an unproblematic default code (most users will just have one role) this could be offered as default in a UI. At the very least, the user information for a user could be recorded in a persistent manner and re‐used, allowing the user to choose from the subset of roles which they have specified in their user information, or to edit an existing user information record when they work in a new domain, without having to re‐enter contact details.

3.3.4 Application domain ontology

GEMET concepts seem a good candidate for a domain ontology, which would be used to properly identify relevant feedback. This is demonstrated in section 4.2.3, and the value of such domain information is illustrated with a search use case in section 5.9.


<<Prev T.O.C.  Next>>
Tag
none

Files (0)

 
You must login to post a comment.