The following content-related criteria are mentioned in Naumann (2002):

As previously argued, the value of data is highly customer-dependent. The same is true for the value-added. We want to approximate this through the other quality dimensions. Hence, it will not be further analysed to avoid recursion. Most other criteria cannot be calculated fully automatically, the exemption being completeness. All others require knowledge going beyond the actual data.

Regarding customer support and documentation, the existence and the extent can be evaluated. While this is a first step that allows for versioning, it does not say anything about the actual quality. Moreover, some criteria remain that cannot be automatically examined, namely interpretability and relevancy, as both require an in-depth understanding of users, which cannot be achieved in an automated way. Consequently, they cannot be used for versioning. For accuracy, it can be said that it cannot be (fully) automatically computed without external knowledge, it allows for the creation of numerous versions by lowering the accuracy. In this work – similar to Tang et al. (2013b), who suppose that the available accuracy is worth the full price – we assume that the accuracy is data inherent.

For completeness, differently complete versions can be created easily. At this point, it should be mentioned we suppose that all information about the data necessary for pricing is already contained within the data. In other words, we follow a Closed World Assumption (CWA) (Batini and Scannapieca, 2006). While this potentially restricts the model, for the purpose of this work, it is not particularly relevant why a value is missing. The fact is, it cannot be delivered to the customer. Completeness, as defined in Stahl (2015), Stahl and Vossen (2016a), will serve as an example later on. It is calculated as the number of non-null value cells divided by the overall number of cells:

Naumann (2002) mentions the following technical criteria:

Following the argument of value-added, price will be excluded. The remaining criteria can all be influenced by providers in the same way accuracy or completeness can, i.e. while there is a (technical) upper limit, they can be lowered. Thus, they all can be used for versioning. The exemption is quality of service for which it has to be defined what quality specifically means. Thus, it is overall not very precise and has, therefore, been excluded from further examination. Moreover, availability requires multiple measurements over time in order to be properly evaluated. As a second example, we will consider timeliness which we defined (Stahl, 2015; Stahl and Vossen, 2016a) as the average freshness of a tuple based on the delivery time, the last update timestamp and the usual volatility v for this type of data.

Next, the intellectual criteria shall be outlined:

All of these criteria are value drivers; however, regarding versioning, none of them can be used as it is difficult to influence them in the short run because they are perceived by the user rather than actively created.

Finally, the group of instantiation-related criteria will be discussed:

While the amount of data and the representational consistency can be assessed automatically, the other three cannot. Representational conciseness and understandability cannot be assessed automatically because only humans can judge whether the data format matches the data or whether they understand the data. Verifiability depends very much on the actual use-case and is hard to generalize. Thus, it has been categorized as not automatically assessable.

The amount of data and the representational consistency can be used for versioning. For representational consistency it is technically possible to change the representation (access API or data format); however, it seems inappropriate to do so just to adjust the quality of the product. Nevertheless, different versions could have different guarantee levels that the representation does not change over certain time intervals. Thus, it has been categorized as applicable to versioning. The representational conciseness can be used for versioning, in that there could be a low quality version that simply stores all data in one binary large object and a high-quality version in which the data is organized in an appropriate relational structure. As a further example, we will consider amount of data. More precisely, we will look at the amount of attributes or columns – $AoC$ – which we defined as Stahl (2015), where Y denotes chosen (or available) columns: $\mathit{AoC}(u):=\frac{|Y|}{|{X_{u}}|}$.

Having described the most relevant data quality criteria as well as having evaluated them with regards to versioning, they shall now be grouped into different sets for easy future reference. Regarding pricing and versioning, all criteria that allow for the dynamic creation of a large number of versions build the set $V=\{$Accuracy, Amount of Data, Availability, Completeness, Latency, Response Time, Timeliness}. Furthermore, there are criteria that generally allow for versioning but where the number of versions is strongly limited. For instance, it is not sensible to create a large number of customer support tiers. Sticking with the Goldilocks principle, it seems reasonable to provide three categories for all attributes in this set, which will be referred to as $G=\{$Customer Support, Documentation, Representational Conciseness, Representational Consistency, Security}. All of the criteria in this set but representational consistency and security are limited in their applicability as comparison criterion. As these are the only relevant quality criteria regarding versioning, they are combined in ${Q_{v}}=V\cup G$.

In our running example, the completeness, as an example for a criterion in V, can be calculated as follows: for provider A the maximum completeness is and for provider B it is $c(u)=0.6\bar{7}$; possible tiers for customer support, as an example for a criterion in G, are:

A common assumption is that goods provide utility.1 Commonly, micro economists investigate utility functions for a set of g goods, which will be referred to as benefit function $b=f({x_{1}},\dots ,{x_{g}})$ (Pindyck and Rubinfeld, 2013) to not confuse utility and the universal relation. We here do not consider sets of goods, but focus on one relational data good and its quality attributes, the utility of which may be formalized as $b=f({q_{1}},\dots ,{q_{n}})$, where ${q_{i}}$ represents the quality scores for quality criterion ${q_{i}}$.

We consider quality criteria to be independent, i.e. the consumption of one quality criterion does not have an effect on the utility of another. While this is not the case for extremes, e.g. an incomplete data set is less likely to be accurate than a complete one, this is a necessary simplification to handle all dimensions in the following model. Furthermore, it can be argued that when looking at one item only, and keeping the others constant, it is a valid assumption.

Two well-known classes of functions can be used as utility functions, logarithm functions – for which the natural logarithm has been chosen as representative – as well as any root function $\sqrt[a]{x}$, $a\in {\mathbf{N}_{\geqslant 2}}$. Given that the quantity of a good cannot be negative, the relevant domain for both functions is ${\mathbf{R}_{0}^{+}}$.

Since we propose to create versions based on the expected utility, the utility function is used to create ${m_{l}}$ utility-based versions or levels so that ${b_{j}}-{b_{j-1}}=\mathrm{const}$, $1\leqslant j\leqslant {m_{l}}$. To this end, the quality scores which have been standardized to fit the domain $[0,1]$ will be scaled to match a sector of the utility function’s domain $[{x_{\min }},{x_{\max }}]$, e.g. $[0,100]$ for the square root. Note that data with some quality scores beneath a certain threshold ${t_{q}}$ are useless. To address this, it is also possible to transform only the interval $[{t_{q}},1]$, $0\leqslant {t_{q}}\leqslant 1$ from the original score to the representative sector of the utility function, i.e. at quality score ${t_{q}}$ the utility level of that quality score is 0. To arrive at the necessary minimum quality score for each utility level, the inverted utility function is used, e.g. ${x^{2}}$ for $\sqrt{x}$.

While for the square root model the utility-based levels increase linearly with x because the difference of two levels can be calculated as ${x^{2}}-{(x-1)^{2}}=2x-1$, for the natural logarithm they increase exponentially in x because the difference of two levels is ${\mathrm{e}^{x}}-1-({\mathrm{e}^{x-1}}-1)={\mathrm{e}^{x}}-\frac{{\mathrm{e}^{x}}}{\mathrm{e}}={\mathrm{e}^{x}}(1-\frac{1}{\mathrm{e}})$. Thus, in the following, the square root function will be used as it produces more illustrative utility levels. The case can be made that other root functions $\sqrt[a]{x}$, which scale polynomially with the degree $a-1$, could be used as well. However, this is a matter of implementation as the model is – as will be seen – independent of the function.

The utility-based quality level vector l contains the concrete values of the utility level ${l_{j}}$ in order. In the example manifestation presented here, it is supposed that ${l_{j}}=j$, $0\leqslant j\leqslant {m_{l}}$. While this applies for those quality criteria that allow for continuous versioning (i.e. $q\in V$), for those that only allow for discrete versioning (i.e. $q\in G$) a smaller number has to be chosen, here four utility levels ${l_{0}},{l_{3}},{l_{6}},{l_{9}}$ are chosen from the utility function for $q\in G$ – according to Goldilocks principle, proposed in Shapiro and Varian (1999). To differentiate between the utility level vectors of both sets, they have an according superscript, resulting in the two vectors ${l^{V}}$ and ${l^{G}}$. Since quality levels in ${l^{G}}$ do not correspond to concrete quality scores, determining a value for them is meaningless. It is rather advisable to manually determine the amount of service for each level. Sample figures for both variants are presented in Table 3, where levels for the second type have been marked with an X. The used utility function and according versions are depicted in Fig. 1.

While in reality utility does differ between customers, the general trend is the same, and will here be approximated by the same function. Furthermore, it is acknowledged that not all quality criteria have the same importance for customers. For example, completeness may be more important for a customer than timeliness because they want to do some time-independent analysis, while for another customer timeliness might be more important because they base time-critical decisions on the data. To represent this in the model, the utility gained from each ${q_{i}}$’s quality score is weighted with a user-provided ${\omega _{i}}$ that represents the importance of all quality criteria relative to each other.

To receive ${\omega _{i}}$, users are asked to express their preferences. This results in a stack of utility functions in which different aspects have a different influence on the overall utility for any individual customer. This is illustrated in Fig. 2. Moreover, this results in a weight vector ω such that:

Based on all this, a benefit matrix b can be calculated for each user. This matrix shows for which quality criterion ${q_{i}}$ with an according weight ${\omega _{i}}$ what actual utility ${b_{ij}}$ can be reached for the different utility levels ${l_{j}^{V}}$ and ${l_{j}^{G}}$. It is calculated as follows:

For future reference, the subscript i refers to elements in Q and j to elements in ${L_{V}}$ or ${L_{G}}$, respectively.

Having extensively discussed for each quality criterion how a utility level is arrived at, we now elaborate on how prices can be attached to the different levels. Besides the overall ask price P providers want to achieve, they have to specify the importance of different quality criteria from their point of view. This may either be done based on the cost the different quality criteria caused when being created or based on the perceived utility of the different criteria. As argued before, the utility-based approach is preferable; however, the cost-based approach can serve as point of reference if no further information is available. Additionally, it is also an option to attribute an equal weight to all quality criteria. Whatever method is chosen, the weights may be adapted in the course of time when providers learn about their customers. Similar to the user weighting vector ω, providers define a weight vector κ such that:

For the actual distribution of the overall ask price P to the different quality levels and quality criteria two fundamentally different approaches can be implemented. Prices can either be attributed to the different quality levels using the utility levels or using the relative satisfaction of each quality criterion. In any case the overall price would be distributed to the different quality criteria using κ. The first will lead to linear prices corresponding to the benefit, which is arguably a fair way of pricing a data product. In this case, the price ${w_{ij}}$ for each quality criterion ${q_{i}}$ at each quality level ${l_{j}}$ is calculated using a formula of the form ${w_{ij}}({b_{ij}})$, in detail: ${w_{ij}}=P\times {\kappa _{i}}\times \frac{{b_{ij}}}{{b_{i,{n_{q}}}}}$.

The alternative is to model prices linearly to the actual quality scores required to reach this level. This will result in increasing prices for the utility levels. However, looking at it from the discount perspective, this means that the biggest discount is granted for the sacrifice of the first utility level and then it decreases. Put differently, in this way customers will receive a product of comparably high quality at a very reasonable price. The calculation of ${w_{ij}}$ in this case is conducted based on the inverted utility function ${w_{ij}}(x)=P\times {\kappa _{i}}\times {b^{-1}}(x)$, in this case ${b^{-1}}(x)={x^{2}}$ and the overall utility levels in l:

It cannot be decided per se which of the two alternatives is the better one. There are some quality scores, such as the amount of data, for which it is sensible to grant a good discount if less data is to be delivered. In other cases, such as accuracy, it might make more sense to scale prices according to the utility levels. That being said, what model to choose is a business decision that has to be made for each individual criterion depending on the attributes of the criterion as well as on the intended fairness of the pricing model. Given the stronger decrease when using the inverted utility function, the average price across all levels is smaller than in the linear case; this speaks in favour of the latter model from a customer’s perspective. After all, it is not important what product is actually delivered as the cost of creating it is marginal. What is more important is that customers get a fair discount for their sacrifice of quality. This is achieved by either of the two.

Having shown how to attribute utility as well as a price to different quality criteria for relational data products, we now demonstrate that the pricing problem can be perceived as a Multiple-Choise Knapsack Problem (MCKP).

The objective of the knapsack problem, which we describe according to Kellerer et al. (2004), is to fit items (numbered from 1 to ${m_{l}}$) with a benefit ${b_{i}}$ and a weight ${w_{i}}$ into a knapsack, in a way that maximizes the utility given a maximum weight W. This standard knapsack problem has been extended in several ways. One of the most flexible knapsack models is the herein-applied MCKP (Kellerer et al., 2004). In a MCKP, items are chosen from ${n_{q}}$ sets of available items rather than from just one set of available items, an additional restriction being that from each set exactly one item has to be chosen. Using the variables from the previous sections and extending the vector a, which stores for each available item whether or not it has been put in the knapsack as ${a_{i}}\in \{0,1\}$, to a matrix, pricing can be formalized using the MCKP as presented in Kellerer et al. (2004). In the following, Eq. (3) extends the original knapsack problem to multiple sets to choose from. Equation (4) restricts the choice to one item per set and determines that items are indivisible.

In order to create a custom-tailored relational data product, the Multiple-Choice Knapsack Pricing Problem (MCKPP) has to be solved. Despite the fact that MCKP is $\mathcal{NP}$-complete, it can be solved in pseudo-polynomial time using, for instance, dynamic programming; several algorithms have been presented to achieve this (Pisinger, 1995). Most algorithms start by solving the linear MCKP to obtain an upper bound. For the linear MCKP the restriction ${a_{ij}}\in \{0;1\}$ has been relaxed to ${a_{ij}}\in [0,1]$, which means it allows the choosing of a fraction of an item (Pisinger, 1995).

Algorithm 5.1 presents a general greedy algorithm to solve the MCKPP. It has been adapted from the one outlined in Kellerer et al. (2004). The main difference is that the original algorithm contains a preparation step which is not necessary for the MCKPP. The algorithm eventually results in a matrix a indicating which items to choose, a value $W-\bar{c}$, which represents the total cost of these items, and a score z, indicating the total utility achieved.

The greedy algorithm, presented in a pricing-tailored form in Algorithm 5.1, has a runtime of $\mathcal{O}({n_{t}}\log {n_{t}})$ – with ${n_{t}}$ being the total number of items over all quality criteria ${n_{t}}={\textstyle\sum _{i=1}^{{n_{q}}}}{{m_{l}}_{i}}{n_{t}}={\textstyle\sum _{i=1}^{{n_{q}}}}{{m_{l}}_{i}}$ – owing to the sorting in Line 13. This form of a greedy-type algorithm is often used as a starting point for further procedures such as branch and bound (Kellerer et al., 2004). Furthermore, the split solution is generally a good heuristic solution; however, it has to be pointed out that as a solution algorithm – despite being illustrative – it is unsuited. The reason for this is that its performance is arbitrarily bad, i.e. while performing quickly, the solution is not guaranteed to be the optimal solution (Kellerer et al., 2004).

Further approximation algorithms exist that do have certain performance guarantees. Gens and Levner (1998) have presented a binary search approximation algorithm running in time $\mathcal{O}({n_{t}}\log {n_{q}})$, where ${n_{q}}$ is the number of quality criteria. At this point, it should be mentioned that ${{m_{l}}_{i}}$ is used here to indicate that depending on whether ${q_{i}}\in V$ or ${q_{i}}\in G$, ${{m_{l}}^{G}}$ or ${{m_{l}}^{V}}$ has to be substituted. However, the guarantee is $\epsilon =0.8$, which is still a considerably bad result – 0 being the perfect solution – even though the authors argue that the actual performance may be much better than that. Using dynamic programming, a fully polynomial time approximation scheme can be developed (Kellerer et al., 2004). Lawler (1977) presents an ϵ-approximation that runs in $\mathcal{O}({n_{t}}\log {n_{t}}+\frac{{n_{t}}{n_{q}}}{\epsilon })$, the first term being due to sorting which might be omitted here. A similar approach is also presented in Kellerer et al. (2004).

Approaches to solve the MCKP to optimality include branch and bound (Dyer et al., 1984), dynamic programming (Dudzinski and Walukiewicz, 1987) (which is often used to solve dynamic pricing challenges (Narahari et al., 2005)), hybrid algorithms of the former (Dyer et al., 1995), and expanding core algorithms (Pisinger, 1995). Pisinger (1995) presents a minimal expanding core algorithm solving the MCKP to optimality. It is based on the idea that the problem is first solved for a core set of classes, i.e. quality criteria, $C\subseteq {Q_{v}}$ based on the split item. Then, gradually more classes are added. This results in a runtime of $\mathcal{O}({n_{t}}+W{\textstyle\sum _{{q_{i}}\in C}}{{m_{l}}_{i}})$, where W denotes the weight limit. This results in a linear solution time for a minimal core and pseudo-polynomial time for larger cores (Pisinger, 1995).

Notwithstanding this, the MCKP can commonly be solved quickly in practise (Dyer et al., 1995). Given that in the MCKPP the weights correlate with the benefits per definition, this results in strongly correlated data instances, which are particularly hard for knapsack algorithms, as no dominated items exist (Pisinger, 1995; Kellerer et al., 2004).

Pisinger (1995) presented computational experiments on commodity hardware for his algorithm. Nearly a decade later, in 2004, results for the same algorithm on more recent commodity hardware were presented in Kellerer et al. (2004). Table 4 shows the results relevant for strongly correlated data instances in the problem scope of MCKPP. Two realistic cases will be presented for each year: Case 1 considers 100 quality dimensions and 10 quality levels and Case 2 considers 100 quality dimensions and 100 quality levels. Furthermore, two different maximum bid prices are considered Max Bid 1 which is set to $1,000$ and Max Bid 2 which is set to $10,000$. The time is reported in seconds.

Returning to our weather example, suppose that the customer has opted to buy data from provider A presented in Table 1 before it is modified, i.e. u. The advertised price P is $ 1200.00 for both providers; however, the customer is only willing to pay $W=1000.00$. For reasons of clarity and comprehensibility this section investigates only three quality attributes, namely: For customer service, the provider offers the three service levels described previously:

Furthermore, at quality level 0 no support is provided. The customer-provided preferences for the different quality criteria are: $\omega =(0.35,0.5,0.15)$ and the provider specifies $\kappa =(0.5,0.3,0.2)$. In the following, the index i (rows) refers to quality criteria and the index j (columns) refers to utility levels. Based on this the utility matrix b, the weight matrix w as well as the incremental utility matrix $\tilde{b}$ and the incremental weight matrix $\tilde{w}$ can be calculated. Eventually, this can be used to arrive at the incremental efficiency $\tilde{e}$:

This results in the following ordered list of ${\tilde{e}_{ij}}$. Nota bene, ${\tilde{e}_{1,1}},{\tilde{e}_{21}}$, and ${\tilde{e}_{31}}$ are missing because they are used to initialize the knapsack. The knapsack is initialized as follows:

Then, the MCKPP is solved using Algorithm 5.1. The sequence of $\bar{c}$, and the selected ${\tilde{e}_{ij}}$ in each step is shown in Table 5. Again, it has to be pointed out that this is just for illustrative purposes as better but less easy to comprehend algorithms exist to solve this.

As can be seen in Table 5, the items that do not fit in the knapsack are ${\tilde{e}_{3,3}}$ and ${\tilde{e}_{1,10}}$.2 By implication, this means that items ${x_{1,9}}$, ${x_{2,10}}$ and ${x_{3,2}}$ are chosen, i.e. timeliness at level 9, amount of data at full level and customer support at level 2. Thus, customer support is served as 9 to 5 telephone support and 24 hours response time e-mail support.

Note that MCKPP can be applied to multiple vendors as well. In this case not the scores of one provider have to be mapped to the quality levels but only the best scores of all providers. This results in a problem scenario, where some providers might not be able to deliver all quality criteria to the highest level. To this end, consider one customer who is unsure which provider to buy from. Given that the average timeliness of both providers is the same, we now look at:

Again, customer service does not need to be calculated and the three levels stated above are considered here, too. For the other two criteria, the maximum scores for each provider have to be calculated. For provider A completeness was = 1 and amount of columns is $0.6\bar{7}$; provider B offers a maximum completeness of 0.8125 and an AoC of 1. Both provide the service levels as stated above. From this it can be concluded that the relevant mapping overall again is 0 to 1. However, it has to be stated that no provider can satisfy the highest level of all categories.

As with the previous example, the customer-provided preferences for the different quality criteria are: $\omega =(0.35,0.5,0.15)$ and the provider specifies $\kappa =(0.5,0.3,0.2)$. Therefore, the above calculus can be reused. As a result, the items that do not fit in the knapsack are ${\tilde{e}_{3,3}}$ and ${\tilde{e}_{1,10}}$; in this case customer support at level 3 and completeness at level 10. Consequently, the customer should chose/will be served by provider B because they can provide the data that has been found to be optimal. In contrast, provider can provide AoC only up to level 8, this is illustrated in Table 6.

However, if the customer favoured completeness over AoC, and supposing the same weights, the result would be different. In this case, provider A while being able to provide full completeness, still lacks the ability to provide AoC greater than level 8. Making up for this the algorithm would also suggest customer support at level 3 leaving a weight of 16 unused. Provider B in the same scenario is not able to offer completeness at level 10 but at level 9. Furthermore, provider B will in this case also offer AoC at level 9 and customer support at level 2. Given the customer’s preferences provider B is not a good choice despite leaving a residuum of less than 2. All this shows that while solving the MCKPP for all providers given a customer’s query and preference, it can also be determined which provider offers the best product for a customer.

For any of the quality measures presented previously an algorithm can easily be stated that creates a quality-adjusted relational data product according to a proposed discount. For accuracy, this has extensively been described in Tang et al. (2013b). Largely, modifications to the quality can be grouped into three categories:

As examples this section will present algorithms to modify the completeness as representation of the second as well as timeliness and amount of data as representation of the third. No representation for the first will be given as this is a rather trivial contractual task and does not affect the data as such. Nevertheless, an example will be provided in the next subsection.

Obviously, the order in which the quality is decreased plays an important role. For instance, if null values are inserted first and then the accuracy is reduced, the accuracy reduction might build on a wrong distribution. Here, it is suggested to apply criteria first that reduce the size, i.e. criteria of the third type and also accuracy, before the rest of the quality is lowered.

The first quality measure to be looked at in more detail is completeness as presented in Eq. (1). This implies that in order to reduce the completeness further, null values have to be inserted at random. In the following u is the universal relation to be sold before any modification and ${u^{\ast }}$ afterwards. The same applies to all other relevant variables, ${n_{v}}$ is the number of null values before and ${{n_{v}}_{t}}$ after the quality modification. The suffix t indicates a target value. Furthermore, ${x_{\max }}$ denotes the maximum of the domain of the utility function and x the utility score at the chosen level. To lower the completeness the actual value for completeness has to be determined and the target value for completeness has to be calculated based on the selected quality level: Based on this the target number of null values ${{n_{v}}_{t}}$ can be calculated: Resulting in:

Note that the ceiling function has to be used in Eq. (7) to ensure ${n_{t}}$ is an integer as no half null values exist. Alternatively, the floor function could be used, this is at the provider’s discretion but would result in a slightly different product version. Based on this target value for null values ${n_{t}}$ Algorithm 5.3 presents an exemplary method to achieve the modified data set u.

Given ${\mathit{AoC}_{t}}=\frac{{y_{t}}}{{x_{\max }}}$, ${y_{t}}=|Y|$ can be calculated. Similar to completeness, the ceiling function is used to ensure that ${y_{t}}$ is an integer.

Furthermore, it is supposed that the customer provides a list of attributes $Z\subseteq {X_{u}}$ in decreasing order of their liking, such that the first attribute is the most important and the last is the least important. If Z is not provided, it is at the provider’s discretion which attributes actually to deliver. While this could also be the standard, giving customers the choice seems more fair. Algorithm 5.2 presents a sample method to achieve $Y\subseteq {X_{u}}$ provided ${y_{t}},u,Z$.

Timeliness does not require an algorithm as it is concerned with delayed delivery. However, it requires some calculus, presented in the following building on Eq. (2). For better readability $\mu [\text{LastUpdated}]$ will be denoted as LU and DeliveryTime will be denoted as DT. Furthermore, the max function can be omitted supposing that the target score ${t_{\mathrm{target}}}=\frac{x}{{x_{\max }}}$ is positive. Additionally $|u|$ will be represented by n. Thus: Plugging in a target value ${t_{\mathrm{target}}}$ yields Given that only LU is variable: Eq. (12) shows what the average timeliness depending on the target value ${t_{\mathrm{target}}}$ should be and could also be written as: The delivery time will always be the current time. Thus, it will be represented by the variable now, which will be replaced by the current timestamp upon query time. This allows for further modification to result in: Introducing a delay function: At first sight one might require each data set to have an average timeliness not greater than $L{U_{\mathrm{target}}}$. However, using the overall average of a data set is slightly problematic, as this allows the selection of data that is very old together with very fresh data and then only use the fresh data. To avoid this, the timeliness of any record is required to be not greater than ${\mathit{LU}_{\mathrm{target}}}$. In this way it is ensured that records with a timeliness worse than or equal to what has been paid for is delivered. In practical terms customers do query a view ${u^{\ast }}$ on u such that: In this model it is important that when records are updated, the original record is kept so that customers can still access the older record rather than receiving an empty result set.

Continuing our example, remember that timeliness was to be provided at level 9, amount of data at full level and customer support at level 2. The last dimension counts as a contractual category that does not influence the data. Since amount of data is served at full level it also does not influence the data. Therefore, $u={u^{\ast }}$ holds as no modifications to the data have to be made. However, given that time restrictions apply, in that the data cannot be queried as soon as it is entered into the system, a view has to be derived at. Here, the assumption is made that the volatility of weather forecast data is 24 hours. Given that the target quality score of ${t_{t}}=\frac{81}{100}=0.81$ is a result of the optimization process, based on the quality level 9, now the delay may be calculated using Eq. (13): Having identified a delay of 4.45 hours and supposing that constant now is expressed in hours, too, the final delivery view can be expressed as: