Ali Kassem

Gergely Acs

Claude Castelluccia

Catuscia Palamidessi

Gergely Ács

Differential Inference Testing A Practical Approach to Evaluate Anonymized Data

Keywords: Sanitization, Inferences, Machine Learning, k-anonymity, -Diversity, Differential Privacy

In order to protect individuals' privacy, data have to be "wellsanitized" ( "well-anonymized") before sharing them, i.e. one has to remove any personal information before sharing data. However, it is not always clear when data shall be deemed well-sanitized. In this paper, we argue that the evaluation of sanitized data should be based on whether the data allows the inference of sensitive information that is specific to an individual, instead of being centered around the concept of re-identification. We propose a framework to evaluate the effectiveness of different sanitization techniques on a given dataset by measuring how much an individual's record from the sanitized dataset influences the inference of his/her own sensitive attribute. Our intent is not to accurately predict any sensitive attribute but rather to measure the impact of a single record on the inference of sensitive information. We demonstrate our approach by sanitizing two real datasets in different privacy models (k-anonymity, -diversity, and differential privacy) and evaluate/compare each sanitized dataset in our framework.

Introduction

Nowadays, organizations own large volumes of data about individuals. Sharing those data provides several benefits for both organizations and individuals. But, at the same time, it puts individuals' privacy at high risk. A 1 straightforward countermeasure to protect individuals' privacy, known as pseudoanonymization, is to exclude explicit identifiers such as name, address, and phone number. However, it has been shown that pseudoanonymization is not sufficient to protect individuals' privacy as the remaining information such as date of birth, gender, and zip code can be used to re-identify individuals [START_REF] Sweeney | Uniqueness of simple demographics in the us population[END_REF][START_REF] Woodward | The computer-based patient record and confidentiality[END_REF].

In order to provide more guarantees about individuals' privacy, more sophisticated techniques have been proposed to sanitize data from information that may lead to re-identification. Examples of such sanitization techniques are mechanisms that rely on data suppression and generalization (known as anonymization techniques) [START_REF] Li | t-closeness: Privacy beyond k-anonymity and l-diversity[END_REF][START_REF] Machanavajjhala | L-diversity: Privacy beyond k -anonymity[END_REF][START_REF] Samarati | Protecting privacy when disclosing information: k-anonymity and its enforcement through generalization and suppression[END_REF], and those that rely on noise addition like in differential privacy [START_REF] Dwork | Differential privacy[END_REF]. Nevertheless, there is neither well-defined scheme to evaluate the robustness of sanitization techniques, nor a clear understanding for "when data is regarded as well-sanitized". The European General Data Protection Regulation considers data as properly sanitized (anonymized) if "data subject is no longer identifiable". A more specific approach can be found in the Working Party 29 opinion on 05/2014 about "Anonymization Techniques", which considers the following three privacy risks: "re-identification", "linkability" and "inference".

In this paper, we argue that inferences should be the primary concern when it comes to individuals' privacy. In particular, we see identity disclosure as one way among others to infer information about individuals. Actually, mitigating "identity disclosure" is the primary goal of pseudoanonymization, however, it is not always relevant to data sanitization. Indeed, if a dataset is "completely-sanitized", then assigning an identity to a certain record is pointless as the records will be highly noised or aggregated. However, as far as the effectiveness of sanitization is concerned, we should be aware about the precise meaning of information inference as preventing any kind of inferences usually lead to useless data [START_REF] Emam | A critical appraisal of the article 29 working party opinion 05/2014 on data anonymization techniques[END_REF]. Indeed, the ultimate usefulness of a dataset is always to infer new information. So, as a trade off between privacy and utility, sanitized data should not allow the inferences of "private" information1 , but at the same time, they have to allow the inference of some "public" information about the population, i.e., the acquisition of any generalizable knowledge. The acceptability or unacceptability of an inference can be based on two criteria:

1. The basis of the inference: is the inference performed on the records of one (or a small group of) individual(s) or a large group of individuals. We will call these kinds of inferences private and public, respectively.

2. The nature of the inference: can the inference be used to discriminate users? Can it have a very negative (for example social or financial) impact?

The intuition behind the first criterion is that if an adversary cannot prove that the records of a user were used to generate the inference, then, by definition, these records are "protected". Note that, it might happen that a model which is exclusively built on population characteristics also accurately predicts some sensitive information of individuals who are member of this population [START_REF] Cormode | Personal privacy vs population privacy: learning to attack anonymization[END_REF]. However, we do not consider this to be a privacy breach as long as the population, which is used to build the model, is large enough. Instead, as in [START_REF] Machanavajjhala | Designing statistical privacy for your data[END_REF], we believe that there are acceptable and unacceptable disclosures: "learning statistics about a large population of individuals is acceptable, but learning how an individual differs from the population is a privacy breach". For instance, inferring an attribute value about the population of a large city, or a rule like "a man smoking between 1 and 4 cigarettes per day is 3 times more likely to die from lung cancer than a non-smoker" should be acceptable. But, deriving some information about the inhabitants of a building may or may not be acceptable depending on the number of people in the building.

As regards the second criterion, the inference nature is partly subjective and involves ethical and legal considerations [START_REF] Emam | A critical appraisal of the article 29 working party opinion 05/2014 on data anonymization techniques[END_REF]. In this paper, we focus on the first criterion and propose a framework called Differential Inference Testing to assess the inference basis. However, we believe that the decisions to release a dataset should always be part of a rigorous privacy risk analysis, which systematically identifies the risks and the potential benefits of publishing the datasets [START_REF] De | Privacy Risk Analysis[END_REF]; especially that, certain public inferences can still be harmful. Namely, we make the following contributions:

• We propose an inference-based framework that can be used to evaluate the robustness of a given sanitized dataset against a specific adversary that is modeled by an inference algorithm (Section 3). In particular, the adversary builds a machine learning model in order to infer an individual's sensitive attribute from his publicly known attributes in the sanitized dataset. We consider the attack successful (and the data not "well-sanitized") if the adversary obtains sufficiently different (but perhaps inaccurate) results depending on whether the target individual's record was used to train the model or not, i.e., the output of the inference potentially leaks some individual specific information aside from more general population characteristics. Our approach is reminiscent of Differential Privacy [START_REF] Dwork | Differential privacy[END_REF], however, it also differs from that in several aspects that we detail in Section 2.2. A key feature of our testing procedure is that it needs to have access only to the sanitized data itself and requires no knowledge about the sanitization technique. Thus, it can be used to assess datasets that are sanitized by organizations which may prefer not to disclose their sanitization techniques.

Even more, the verifier (e.g., Data Protection Authority) of a sanitization process does not need to understand or analytically analyze its privacy guarantees which can be very tedious and error-prone [START_REF] Lyu | Understanding the sparse vector technique for differential privacy[END_REF].

• We use our framework to evaluate two datasets after being sanitized in the k-anonymity, -diversity, and differential privacy (Section 4) models. In this paper, we consider microdata, but our solution is general and can be applied to any type of datasets, such as aggregated data.

In addition, the paper discusses related work in Section 2 and provides a conclusion in Section 5.

2 Related Work

Testing Data Sanitization

To the best of our knowledge, our approach is the first one that proposes a general practical test to evaluate sanitized datasets by making distinction between acceptable and unacceptable inferences. Yet, there are some prior related works [START_REF] Bichsel | Dp-finder: Finding differential privacy violations by sampling and optimization[END_REF][START_REF] Cormode | Empirical privacy and empirical utility of anonymized data[END_REF][START_REF] Ding | Detecting violations of differential privacy[END_REF][START_REF] Pyrgelis | Knock knock, who's there? membership inference on aggregate location data[END_REF]. The authors of [START_REF] Cormode | Empirical privacy and empirical utility of anonymized data[END_REF] propose a framework to test whether a machine learning (ML) model can predict sensitive attribute values from a given sanitized dataset. But, they consider all types of inferences as privacy breaches. More precisely, their framework tests, for every record, whether the ML model can predict the true value of the sensitive attribute. If the ML model succeeds to predict the true value (what they call "empirical utility"), then the sanitization technique does not pass the test. Note that the framework does not consider whether the prediction was obtained from the record of the target individual (that was somehow poorly sanitized) or from the records of other users (that happen to be correlated with the target individual). By contrast, we propose a framework that does not consider data utility (i.e., ignores the accuracy of inferences in absolute sense), but instead tests whether an inference is private (depends on the target individual) or public. In our framework, a dataset is deemed "well-sanitized" if it can be shown that, for any user, the resulting inferences based on this dataset do not depend on the contribution of a single user but on the contribution of all users together: the inference accuracy should not change too much whether the user's record is included or not in the dataset. Such a dataset protects against "private" inferences while still allowing "public" inferences.

Recently, [START_REF] Bichsel | Dp-finder: Finding differential privacy violations by sampling and optimization[END_REF] and [START_REF] Ding | Detecting violations of differential privacy[END_REF] have proposed statistical techniques to identify the violations of differential privacy. Unlike these approaches, our method considers the sanitization technique as a black-box and only requires access to the sanitized datasets. This can be a favorable feature if the sanitization schemes are proprietary and their exact operations are not published. Also, our testing procedure is more general as it can be applied beyond differential privacy.

Pyrgelis et al. [START_REF] Pyrgelis | Knock knock, who's there? membership inference on aggregate location data[END_REF] used machine learning for membership inference on aggregated location data. They build a single binary classifier to predict a given individual's presence in the sanitized data. By contrast, we follow a more general approach and measure how much the inference of a particular sensitive information/attribute is affected by a single individual's data using a specified distance measure. For this purpose, we build two classifiers; one which predicts the sensitive attribute using all the sanitized dataset and another one which uses the sanitized data excluding the individual's data, then report the difference between the output of these classifiers according to the chosen distance measure. Of course, we can easily turn our approach into membership inference by combining the output of the two models into a single binary classifier to infer membership. However, the choice of different distance measures allows to incorporate different privacy requirements into our framework which makes our approach more general. For instance, membership may be already publicly known, but not some sensitive attributes.

Differential Inference Testing vs. Differential Privacy

Our approach is inspired by differential privacy [START_REF] Dwork | Differential privacy[END_REF]. Indeed like differential privacy, it guarantees that the inferences one can derive from a sanitized dataset are similar, whether or not the record of a certain individual is included. However it differs from differential privacy in several aspects:

• Our approach provides a method to measure the robustness of sanitized datasets, and to compare different sanitizations of the same dataset. Differential privacy, on the other hand, is a property of the sanitization scheme and not of the sanitized dataset.

• For differential privacy to hold, the sanitization must be done probabilistically (typically, by adding controlled noise to the answer to the query). Our approach, on the contrary, can also be applied to deterministic techniques, such as k-anonymity [START_REF] Samarati | Protecting privacy when disclosing information: k-anonymity and its enforcement through generalization and suppression[END_REF] and -diversity [START_REF] Machanavajjhala | L-diversity: Privacy beyond k -anonymity[END_REF], as well as to probabilistic ones.

• The possible inferences one can make in differential privacy are strictly related to the query for which the mechanism is defined without any further restrictions on how the inference model is built. In our case the inferences are produced by a machine learning algorithm, which constitutes a parameter of the framework.

• In differential privacy the metric used to compare the inferences in the dataset with and without a certain individual is fixed and based on the upper bound to the likelihood ration. In our setting, the comparison is based on a parametric notion of distance between distributions.

• Differential privacy relies on tedious and error-prone analytical analyses of the privacy guarantee, while our approach uses easy-to-implement empirical evaluation of a very similar (but weaker) guarantee [START_REF] Bichsel | Dp-finder: Finding differential privacy violations by sampling and optimization[END_REF][START_REF] Lyu | Understanding the sparse vector technique for differential privacy[END_REF]. This also makes different sanitizations of the same dataset comparable within our framework.

Differential Inference Testing

In this section, we introduce the notion of indifferentiability (Section 3.1), then we propose a testing procedure in order to evaluate the indifferentiability of a given sanitized dataset against a certain inference model (Section 3.2).

Model

Given a sanitized dataset, our approach tests whether the inference of some sensitive attribute(s) is influenced by the presence of any single individual in the dataset. If the "amount" of this influence is large, then the inference leaks some private information, i.e., any information that potentially differentiates the individual from the rest. In this case, the dataset is not sanitized properly. Conversely, smaller influence indicates stronger sanitization. In order to measure such an influence, we propose the notion of δ-indifferentiability defined in Definition 1. Without loss of generality, we express the sensitive attribute(s) to be inferred using a single attribute S, which can be any function of other attributes. Note that, the explicit distinction between quasi and sensitive attributes is only for demonstration purposes. Moreover, we assume that the contribution of every individual i to D is a single record (q i , s i ) where q i represents his quasi-identifiers and s i represents his sensitive value.

Definition 1 (Indifferentiability) Let D be a dataset (Q, S) where Q is a tuple of quasi-identifiers and S is a sensitive attribute. Let D -i denote the dataset obtained from D by removing the record (q i , s i ) of individual i. Let A be a (possibly randomized) inference algorithm, and let f be a sanitization technique. Let M f (D) and M f (D -i ) denote the random variables describing the output of the models M f (D) and M f (D -i ) which are built according to A respectively using f (D) and f (D -i ) to provide each, given a quasi-identifier tuple from Q, a prediction distribution over the domain of the attribute S.

We say that f (D) is δ-indifferentiable with respect to A, if we have that

∀(q i , s i ) ∈ D, distance M f (D) , M f (D -i ) ≤ δ
where distance is a statistical distance measure.

Somewhat abusing the notation, M denotes both the model and the random variable describing its output henceforth.

The evaluation of the sanitized dataset f (D) depends on the value of δ. If δ is small enough (depending on the case study) then, for every individual i in D, the inference about i's sensitive value does not strongly depend on the i's record (i.e., public inference). On the other hand, for larger δ's, there may exist i's in D such that the inference about the i's sensitive value depends on the i's record (private inference).

Definition 1 does not consider any external knowledge about i or D, however, it can be generalized in a straightforward way to capture any such possible knowledge. For instance, in case of Bayesian inference, auxiliary information can be used to compute the prior probabilities, and thus favorizing one value of the sensitive attribute over the others.

The inference algorithm A represents the adversarial strategy to predict/infer the value of the sensitive attribute. The choice of inference algorithm A depends on the case study and is a task of the analyst. Indeed, the differentiability δ of sanitized dataset f (D) depends on the considered inference algorithm A. In this paper, we use Bayesian inference as an inference algorithm for it is simplicity and popularity. Note that, the aim of our framework is not to accurately predict any sensitive attribute but rather to measure the impact of a single record on the inference of sensitive information.

We note that M f (D) and M f (D -i ) belong to the same model family since they are built using the same algorithm A. For instance, if M f (D) is a neural network then M f (D -i ) is also a neural network with the same architecture and with the same hyper parameters, but with potentially different model parameters as they are trained using two different training datasets f (D) and f (D -i ). In the rest of the paper, we may use M and M -i to refer to M f (D) and M f (D -i ) , respectively. Definition 1 assumes that the output of a model M is a vector of probability values, i.e., a prediction distribution on the possible values of the sensitive attribute. Specifically, if there are n possible sensitive values s 1 , . . . , s n , then for some record (q i , s i ), M(q i ) = {(s 1 , p i 1 ), . . . , (s n , p i n )} where p i j denotes M's confidence that s i = s j . In the rest of the document, we refer to the number of possible sensitive values by n, and we write M(q i ) = (p i 1 , . . . , p i n ) when the related sensitive values are clear from the context. Similarly for model M -i , we write M -i (q i ) = (p -i 1 , . . . , p -i n ). Finally, distance denotes a distance measure (such as total variation distance, KL-divergence, etc.) chosen by the analyst. The choice of distance should depend on the privacy requirements, and it fundamentally impacts the result of our approach.

Testing Procedure

We propose a procedure to find, given a sanitized dataset f (D) and an inference algorithm A, the minimal distance δ such that f (D) is δ-indifferentiable with respect to A (that is the the minimal δ that satisfies Definition 1). In order to perform the test, one should also have access to f (D -i ) for every (q i , s i ) ∈ D. Nevertheless, the sanitization technique f itself is not needed by our testing procedure. The testing procedure runs through the following steps:

1. Choose a record (q i , s i ) ∈ D for some individual i.

Use

A to build two models M and M -i respectively using datasets f (D) and f (D -i ). For example, in the case where A is a machine learning algorithm, then f (D) and f (D -i ) will act as training datasets.

3. Provide q i as an input to the model M. The output of M takes values from the set of all prediction distributions which corresponds to an ndimensional simplex in R n (i.e., M(q i ) = (p i 1 , . . . , p i n ) over the domain of the sensitive attribute S, where n j=1 p i j = 1).

4. Repeat the last step for M -i whose output also takes values from the set of all prediction distributions (i.e., M -i (q i ) = (p -i 1 , . . . , p -i n ) over the domain of the sensitive attribute S, where n j=1 p -i j = 1).

Compute the distance

d i = distance(M, M -i ).
6. Repeat Steps 1-5 for every individual i in D.

7. Return the maximal distance d i for every i ∈ D, as δ.

The outputs of M and M -i can be described by random variables whose output range is the n-dimensional simplex in R n . Indeed, the sanitization algorithm f is a possibly randomized black-box mechanism, which means that the output distributions of M i and M -i can only be approximated by sampling. However, sampling from the n-dimensional simplex is not scalable if n is large and/or there are many records in D. Hence, in this paper, we rely on the following simplification; we approximate the distribution of every coordinate of the prediction distribution independently, and compare the approximated distributions of the corresponding coordinates. More precisely, for every 1 ≤ j ≤ n, let P i j and P -i j denote the random variables describing the values of p i j and p -i j , respectively. Then, distance(M, M -i ) = n j=1 div(P i j , P -i j ), where div is a distance measure (or divergence) between distributions. In this paper, we use the 1 st Wasserstein distance (or Earth Mover's Distance, shortly EMD) as such a distance measure, that is, div(P i j , P -i j ) = EMD(P i j ,

P -i j ) = inf π R R |x -y|dπ(x, y),
where the infimum is taken over all probability measures π on R × R with marginals P i j and P -i j . Intuitively, EMD measures how far one has to move the probability mass of P i j to turn it into P -i j , where "farness" between the values of P i j and P -i j is measured by their absolute distance2 . We approximate the empirical measures of P i j and P -i j and compute the EMD between these empirical measures (see [START_REF] Bobkov | One-dimensional empirical measures, order statistics,and kantorovich transport distances[END_REF] for details). In particular, if x i 1 , . . . , x i N and x -i 1 , . . . , x -i N denote the samples taken from the distributions of P i j and P -i j , respectively, then EMD(P i j , P -i j ) can be approximated by:

EMD( Pi j , P-i j ) = 1 N N k=1 |x i (k) -x -i (k) | (1)
where Pi j and P-i j denote the empirical measures of P i j and P -i j , respectively, and x i (k) denote the k th order statistic (k th smallest value) of samples x i 1 , . . . , x i N (analogously to x -i (k) ). We use EMD as it makes randomized and deterministic sanitizations comparable in our framework. In particular, the uncertainty of the adversary has two sources; one is measured deterministically by the inference algorithm and represented by the prediction confidences of each sensitive value in its output. The second source of uncertainty stems from the "artificially" introduced perturbation in the sanitization process (e.g., by the Laplace Mechanism in differential privacy) which induces a probability distribution on these (deterministic) confidences. Unlike traditional divergences like total variation distance or the max-ratio distance used in differential privacy, EMD also considers the value of the inference algorithm's output and not only the distribution of these values.

Example. Consider the dataset presented in Table 1a. It has two quasiidentifier attributes: "Age" (an integer) and "Gender" (M:Male or F:Female), and a sensitive attribute: "Disease" which can take two values (Flu and Cancer). Table 2 represents a 2-anonymous version of this dataset (as every record is syntactically indistinguishable from at least another record considering their quasi-identifiers) 3 .

Let i denote the individual that corresponds to record 4 from Table 1a. If we know that i is a 53 years old male, then we can infer from Table 2a the following prediction distribution about his disease: P r[Flu | (53, M)] = 2 3 and P r[Cancer | (53, M)] = 1 3 , i.e., M(q 4 ) = {(Flu, 2 3 ), (Cancer, 1 3 )}, as (53, M) belongs to the second equivalence class of Table 2a which is composed of the last three records (Step 3). Notice that we used a very simple inference algorithm A here for simplicity (i.e., computing the probability of a sensitive (b) M(q i ), M -i (q i ), and

d i . # M(q i ) M -i (q i ) d i 1 (1, 0) (1/2, 1/2) 1 2 (1, 0) (1/2, 1/2) 1 3 (2/3, 1/3) (1, 0) 2/3 4 (2/3, 1/3) (1/2, 1/2) 1/3 5 (2/3, 1/3) (1/2, 1/2) 1/3
value conditioned on the values of all the quasi-identifiers), though one can use any sophisticated inference model in practice. Now, if we remove the 4 th record from the original dataset (Table 1a) then apply 2-anonymity we obtain Table 2b. It is important to remove the record from the original dataset before applying sanitization again. Hence, the new sanitized dataset f (D -4 ) (after removing the record) can be different from the first sanitized dataset f (D) (obtained by sanitizing the whole original dataset). The prediction distribution after removing the 4 th record is M -i (q 4 ) = {(Flu, 1 2 ), (Cancer, 1 2 )} (Step 4). Finally, considering EMD distance, then

d i = distance(M 4 , M -4 ) = distance(M(q 4 ), M -i (q 4 )) = n j=1 p 4 j -p -4 j = 1 3 (Step 5) since M(q 4
) and M -i (q 4 ) are the only possible output of M and M -4 , respectively (i.e., the sanitization scheme is deterministic). After repeating the previous steps for every record in the dataset (Step 6), the maximal distance δ = max i∈D d i can be computed (that is the the minimal distance that satisfies Dentition 1), which is δ = 1 = max{1, 1, 2 3 , 1 3 , 1 3 } in our example. Table 1b depicts the distributions M(q i ), M -i (q i ) and the distance d i for every record i in the dataset of Table 1a.

Notice that using a different distance metric the results can completely change. For example, if distance denotes the total variation distance (TVD), then distance(M 4 , M -4 ) = distance(M(q 4 ), M -i (q 4 )) = 1 + 1 = 2 which suggests that the data is blatantly non-private as distance(M i , M -i ) ≤ n for any i.

Evaluation

Datasets

We demonstrate our approach using two datasets: the UCI Adult (Census Income) dataset 4 and the "General Demographics" dataset from Internet "education attainment" "hours per week" "major occupation" "native country" "marital status" SA "occupation" "household income" n 14 9

Sanitization

For sanitization techniques, we consider the basic Mondrian k-anonymity [START_REF] Gong | Implementation of basic mondrian k-anonymity[END_REF], Mondrian -diversity [START_REF] Gong | Implementation of mondrian l-diversity[END_REF], and data perturbation required to satisfy differential privacy [START_REF] Dwork | Differential privacy[END_REF].

k-anonymity and -diversity

The Mondrian sanitization algorithm modifies the records by generalizing the quasi-identifiers until each record becomes syntactically indistinguishable from k -1 other records (k-anonymity), or the correct sensitive value of any individual cannot be predicted with probability more than 1/ (diversity) 6 . After being generalized, the data is then published with the related sensitive values.

Differential Privacy

As for differential privacy, noisy statistics of the microdata are computed which are then used to compute the prediction distribution of each record.

In particular, contrary to k-anonymity and -diversity, differential privacy provides weak utility when it is directly applied on microdata. Instead of generating sanitized microdata, the differentially private prediction distributions M(q i ) and M -i (q i ) are directly computed from the original dataset, and these distributions are compared in Step 5 of the Differential Inference Test described in Section 3. In other words, our differential private sanitization technique f is with a simple inference algorithm A that we describe below.

The sanitization technique f consists of releasing the perturbed conditional probabilities P r[s|q] for all sensitive attribute value s and value of quasi-identifier tuple q. These conditional probabilities are directly used as the prediction distributions M(q i ) and M -i (q i ) in our Differential Inference Test (see Section 3). Specifically, in order to obtain the differential private prediction distributions M(q i ) and M -i (q i ) for a quasi-identifier tuple q i = (q i 1 , . . . , q i m ), we compute

P r[s k |q i ] = P r[s k , q i ] P r[q i ] (2)
In Eq. ( 2), we calculate the joint probability P r[s k , q i ] as

P r[s k , q i ] = C ik i k C ik (3)
and the marginal probability P r[q i ] as

P r[q i ] = k P r[s k , q i ] ( 4
)
where C ik = 1 + max(0, |{(q, s) ∈ D : q = q i ∧ s = s k }| + noise) and the noise is drawn from the Laplacian distribution L(0, 1/ ) with zero mean and variance 2/ 2 . This perturbation technique is also referred to as the Laplace Mechanism in the literature of differential privacy7 . Note that the addition of 1 to C ik is the standard Laplacian correction in order to avoid zero value of the denominator in Eq. ( 3). The privacy guarantee of differential privacy comes from the randomness of the Laplace Mechanism; if the variance of the added noise is larger, we have stronger guarantee (i.e., smaller ε), and the reverse direction holds for small variance. Differential privacy is formally defined in Definition 2.

Definition 2 ( -differential privacy [START_REF] Dwork | Differential privacy[END_REF]) A sanitization algorithm f guarantees -differential privacy if for any database D and D , differing on at most one record, and for any possible output

O ⊆ Range(f ), e -≤ P r[f (D)∈O] P r[f (D )∈O] ≤ e .
In our case, the range of f is the space of all prediction distributions (i.e., vectors from an n-dimensional simplex), and an output O of f is a random vector from this space.

Pre-processing

Many sanitization techniques (such as Mondrian) generalize the attribute values according to a specific generalization hierarchy. In order to feed the learning algorithm with generalized data in our experiments, we use an encoding mechanism that is relative to the target record selected in Step 1 of our testing procedure (see Section 3.2) and works as follows: a generalized quasi-attribute value q (e.g., an interval or set) is represented by 1, if the corresponding quasi-attribute value q of the target record can also be generalized to q (i.e., q is inside q if q is an interval, or q is a member of q if it is a set). Otherwise, q is represented by 0.

For example, consider the two generalized records: [START_REF] Lyu | Understanding the sparse vector technique for differential privacy[END_REF]25], Female, {France, Germany}) [START_REF] Machanavajjhala | Designing statistical privacy for your data[END_REF][START_REF] Samarati | Protecting privacy when disclosing information: k-anonymity and its enforcement through generalization and suppression[END_REF], Male, {Italy, Germany})

r 1 = ([
r 2 = ([
Assuming that the target record, which is selected in the first step of our testing procedure, is r t = (16, Male, France), then r 1 and r 2 will be encoded as follows: encode(r 1 , r t ) = (1, 0, 1) because 16 ∈ [15, 25], Male = Female, and France ∈ {France, Germany}. Similarly, encode(r 2 , r t ) = (0, 1, 0) because 16 / ∈ [START_REF] Machanavajjhala | Designing statistical privacy for your data[END_REF][START_REF] Samarati | Protecting privacy when disclosing information: k-anonymity and its enforcement through generalization and suppression[END_REF], Male = Male, and France / ∈ {Italy, Germany}. An advantage of this encoding technique is that it depends on the target record which will be used as an input for the inference model. This may increase the sensitivity to the presence of the target record in the dataset, and thus help to better capture the difference between the two intended distributions. Another advantage of this approach is that it is very fast to compute and has to be done only once for each record (other approaches may require different encodings of the same record for the computation of M and M -i ). Nevertheless, any encoding mechanism can be used in our framework as long as the encodings of each record is sufficiently different from that of the target record.

Differential Inference Test

Inference algorithm

For the purpose of inference A and the computation of the prediction distributions M(q i ) and M -i (q i ), we use a Naive Bayes classifier8 . in the case of k-anonymity and -diversity, and the noised conditional probabilities in Eq. ( 3) in the case of differential privacy. In both cases, the inference algorithms use the encoded sanitized data to build the models M and M -i . The Naive Bayes classifier has been used by several prior works [START_REF] Cormode | Personal privacy vs population privacy: learning to attack anonymization[END_REF][START_REF] Cormode | Empirical privacy and empirical utility of anonymized data[END_REF][START_REF] Kifer | Attacks on privacy and definetti's theorem[END_REF] to perform inference on sanitized data. Although Naive Bayes makes the simplistic assumption that the quasi-identifiers are independent, it usually performs remarkably well, especially when the size of the training dataset is not so large.

After choosing the encoding mechanism and the inference algorithm, we proceed according to the Differential Inference Test described in Section 3.2: for every record r i in the dataset, we train a model M where D includes r i , and also train another model M -i where D -i excludes r i . Then, the corresponding two prediction distributions of M and M -i are approximated by sampling, and the distance d i = distance(M, M -i ) is computed for every i. Finally, we obtain the minimal distance δ that satisfies Dentition 1, i.e., δ = max

i∈D d i .
In what follows, "minimal δ" refers to the minimal distance δ that satisfies Dentition 1.

We emphasize that the (in)differentiability of a sanitized dataset depends on the inference algorithm A, which represents the adversarial algorithm to infer sensitive information from the dataset. This is in stark contrast to differential privacy, which provides the same guarantee (i.e., the same value) against all inference algorithms. On the other hand, (in)differentiability (in Definition 1) can be empirically evaluated unlike differential privacy (in Definition 2) which relies on analytical evaluation that is often tedious and error-prone.

Results

k-anonymity and -diversity

Adult Dataset Figure 1 depicts the minimal δ (that satisfies Dentition 1 in the case of Adult dataset) depending on the privacy parameter (k or

). The cases of k = 1 and = 1 implies the absence of sanitization, i.e., the testing procedure is applied directly on the original data without any sanitization.

From Figure 1, we can notice that: • δ is smaller for -diversity than for k-anonymity when k and have identical values. This is expected as, unlike k-anonymity, -diversity was designed to mitigate inference attacks, though not the same type of inference that we measure in our approach. Specifically, -diversity addresses the absolute accuracy of inferences, where privacy breach occurs if the sensitive attribute of an individual can be inferred with too large accuracy. By contrast, we focus on the relative accuracy of inferences, i.e., the difference in inference accuracy caused by the inclusion/exclusion of an individual's record.

• δ decreases when the privacy parameter (k or ) increases, however not monotonically. For instance, counterintuitively, the minimal δ increases when k increases from 8 to 16 and when increases from 2 to 3.

The second observation above shows that increasing the value of the privacy parameter may decrease the privacy guarantees against private inferences for some individuals (worst-case privacy), even if the guarantees on average (average-case privacy) can be stronger. In particular, Figure 2 presents the Cumulative Distribution Function (CDF) of d i . The CDF is the sum of the relative frequencies for all values that are less than or equal to the given value of d i . Figure 2 shows that, for both k-anonymity and -diversity, the majority of d i values are smaller for larger k or . The CDF illustrates the level of the average-case privacy, which increases if the value of the privacy parameter also increases (as one could expect for k-anonymity and -diversity). This emphasizes the fact that average-case privacy, which is usually adopted by companies and governments' regulations, does not always imply worst-case privacy, which is considered in our framework. Indeed, Dentition 1 has to be satisfied for every record in the dataset.

A closer investigation reveals that there are only few outlier records with large value of d i when = 3 or k = 16. For example, when = 3, there is only one record r i whose d i value is greater than 10 -1 (for this record, d i = 0.21), which is the minimal δ in this case. Similarly, for 16-anonymity, there are only 3 outlier records which have much larger d i values than others.

In order to achieve stronger sanitization (smaller δ), we remove the outlier records identified above from the original dataset, then repeat the entire testing procedure to compute a new value of minimal δ (remember that it is not sufficient to remove the outlier records only from the sanitized dataset). For = 2, we obtain the following new values of minimal δ: 0.165 for = 2 and 0.092 for = 3, what one naturally expects when increases. Internet Usage Dataset Figures 3 and4 present the minimal δ and the CDF of d i , respectively, for the Internet Usage dataset. The results confirm the conclusion that average-case guarantees against private inferences often differs from the worst-case guarantees in practice due to the existence of a few outlier records with much worse privacy guarantee than the average. However, on average, increasing the privacy parameters k and results in stronger guarantee against private inferences using the Mondrian sanitization scheme.

Differential Privacy

Adult Dataset Figure 5 presents the CDF and δ for the Adult dataset in the case of differential privacy (DP). We quantized the "age" and "hours per week" attributes, each, into 5 quantiles. This results into 2952 distinct records (instead of 7960) out of 10K records. = ∞ corresponds to the case when no Laplace noise is added to the counts in Eq (2). We performed N = 25K samples per record in order to have an estimate of the prediction distribution for every individual. From these noisy predictions, we can compute the minimal δ (in Figure 5a) as it is described in Section 3.2. The minimal δ curve shows that smaller indeed yields stronger protection, for every individual, against private inferences, as δ is monotonically decreasing with as one would expect. The CDF and minimal δ curves (in Figure 6) show similar trends to the Adult dataset and confirm our observation that, for every individual, smaller yields stronger protection against private inferences.

Finally, we note that, for both datasets, the values of δ are smaller for kanonymity and -diversity on average than for differential privacy (Figures 1, 3, 5, and 6). Hence, differential privacy even with = 0.1 may provide weaker protection on average against private inferences if we use the EMD distance measure defined in Eq. ( 1), but it is worst-case guarantee is superior to k-anonymity and even to -diversity if < 5.

Computation time

All the experiments that are presented above were conducted on a machine with a 2.6 GHz Intel Core i7 Processor and 16 GB RAM. Table 4 summarizes the average computation time of the differential inference test per privacy parameter (excluding the raw data case, i.e., where k = = 1 and = ∞). Note that the computation can be substantially improved since the sanitizations of the dataset (per user) are highly parallelizable.

Conclusion

This paper presents an inference-based framework to evaluate the effectiveness of sanitization performed on a given dataset. In particular, we empirically measured how the sanitized dataset prevents the private inferences of sensitive attribute values. We demonstrated the usage of this framework on two datasets. Our framework allows to compare different sanitized datasets that might use different privacy models, such as k-anonymity, -diversity or differential privacy. It can potentially be employed by companies or DPAs (Data Protection Authorities) to test the robustness of sanitized datasets.

It is important to note that our solution tests the robustness of sanitized datasets, not that of the underlying sanitization technique.

Our case study shows that -diversity and k-anonymity can provide stronger average protection against private inferences in our framework than differential privacy if is chosen to be too large. This result should be handled with caution, since these techniques have quite different adversary models and some attacks which are hard to be modeled using a machine learning algorithm in our framework can have devastating effect on -diversity and k-anonymity yet still difficult to launch against a differentially private dataset [START_REF] Ganta | Composition attacks and auxiliary information in data privacy[END_REF]. In particular, our model considers only a specific adversarial inference attack as well as some potentially defined extra background knowledge of the adversary. We also showed that increasing the value of k and results in stronger protection on average, but can also entail weaker worst-case guarantee when each individual is considered.

We believe that there is a need for a toolkit to test the robustness of sanitized datasets by implementing different re-identification or inference attacks. Our framework could be one component of such a toolkit. One benefit of the proposed testing tool is that the sanitized dataset is analyzed as a "black box", i.e. the sanitization algorithm does not need to be published. It is enough for the verifier to get access to an oracle that, given a dataset, outputs its sanitized version. We believe this is a desirable property for at least two reasons: (i) many companies are unwilling, for different reasons, to publish their sanitization algorithms, and (ii) the verifier does not need to go through the difficulty of understanding and analyzing the underlying algorithm.

In the proposed framework, the verifier can use his favorite inference models. This paper uses a Naive Bayes classifier, but other classifiers could be used. Evaluating our framework with other classifiers is part of our future work.

Figure 1 :

 1 Figure 1: Minimal δ (Adult data).

Figure 2 :

 2 Figure 2: CDF of d i (Adult data).

Figure 3 :

 3 Figure 3: Minimal δ (Internet Usage data).

Figure 4 :

 4 Figure 4: CDF of d i (Internet Usage data).

  CDF of d i .

Figure 5 :

 5 Figure 5: CDF and δ (DP, Adult data, N = 25K).

  CDF of d i .

Figure 6 :

 6 Figure 6: CDF and δ (DP, Internet Usage data, N = 25K).

Table 1 :

 1 Original dataset, and related result.

			(a) Dataset.
	# Age Gender Disease
	1	28	M	Flu
	2	36	M	Flu
	3	47	F	Cancer
	4	53	M	Flu
	5	72	F	Flu

Table 2 :

 2 2-anonymous versions of Table1a. . Table3summarizes, for each dataset, its size (|D|), number of distinct record (|D † |), quasi-identifiers (QI), and sensitive attribute (SA) as well as the number of values that SA can take (n).

	(a) f (D) (with i = 4).	(b) f (D -4 ) (without i = 4).
	# Age Gender Disease	# Age Gender Disease
	1 < 45	M	Flu	1 < 45	M	Flu
	2 < 45	M	Flu	2 < 45	M	Flu
	3 ≥ 45 {M, F} Cancer	3 ≥ 45 {M, F} Cancer
	4 ≥ 45 {M, F}	Flu	5 ≥ 45 {M, F}	Flu
	5 ≥ 45 {M, F}	Flu
	Usage data 5

Table 3 :

 3 Datasets description.

	Dataset	Adult	Internet Usage
	|D|	10,000	9,799
	|D † |	7,960	7,049
		"age", "education"	"age", "race"
	QI	"marital status"

  Internet Usage Dataset Figure6presents the CDF and δ for the Internet Usage dataset. Again, we have quantized the "age" attribute into 5 quantiles. This results into 2926 distinct records (instead of 7049) out of 9799 records.

	0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09
	0.1	0.5	1.0

(a) Minimal δ.

Table 4 :

 4 Average computation time.

	Dataset	k-Anonymity	-Diversity Differential Privacy
	Adult data	60m 24s	76m 6s	5h 41m 51s
	Internet data	47m 30s	50m 12s	4h 23m 22s

We regard private information as defined in[START_REF] Klucar | Lunchtime for data privacy[END_REF], where a distinction between "personal information" and "private information" has been made. Private information is seen as "secrets that you can keep by withholding your data" whereas "personal information" could be derived from datasets in which you are not necessarily involved.

EMD permits different "farness" measures other than the absolute difference |x -y|. We chose this metric due to its simplicity and fast computation.

In our example, the sanitization technique f is k-anonymity[START_REF] Samarati | Protecting privacy when disclosing information: k-anonymity and its enforcement through generalization and suppression[END_REF].

https://archive.ics.uci.edu/ml/datasets/Adult

http://www.cc.gatech.edu/gvu/user_surveys/survey-1997-10

Using only f (D) as a background knowledge for inference.

The scale parameter of the Laplace noise is adjusted to the global sensitivity of the counts C ik which is 1 in our application.

We use the Bernoulli Naive Bayes from the sklearn python module http:// scikit-learn.org/stable/index.html.


Franck Michel
email: franck.michel@cnrs.fr

Catherine Faron-Zucker

Olivier Corby
email: olivier.corby@inria.fr

Fabien Gandon
email: fabien.gandon@inria.fr

Enabling Automatic Discovery and Querying of Web APIs at Web Scale using Linked Data Standards

Keywords: SPARQL, Web API, discovery, dataset, Web service, Linked Data

To help in making sense of the ever-increasing number of data sources available on the Web, in this article we tackle the problem of enabling automatic discovery and querying of data sources at Web scale. To pursue this goal, we suggest to (1) provision rich descriptions of data sources and query services thereof, (2) leverage the power of Web search engines to discover data sources, and (3) rely on simple, well-adopted standards that come with extensive tooling. We apply these principles to the concrete case of SPARQL micro-services that aim at querying Web APIs using SPARQL. The proposed solution leverages SPARQL Service Description, SHACL, DCAT, VoID, Schema.org and Hydra to express a rich functional description that allows a software agent to decide whether a microservice can help in carrying out a certain task. This description can be dynamically transformed into a Web page embedding rich markup data. This Web page is both a human-friendly documentation and a machine-readable description that makes it possible for humans and machines alike to discover and invoke SPARQL microservices at Web scale, as if they were just another data source. We report on a prototype implementation that is available on-line for test purposes, and that can be effectively discovered using Google's Dataset Search engine.

datasets based on metadata, such as the manifold CKAN-based portals 1 like Datahub2 and the data portals of European states and institutions. Some portals specialize in specific dataset formats or interface technologies. For instance, ProgrammableWeb.com 3registers Web APIs, a loosely defined category of lightweight Web services also referred to as REST-like or Lo-REST [START_REF] Pautasso | Big" Web Services: Making the Right Architectural Decision[END_REF] services, while LODAtlas [START_REF] Pietriga | Browsing Linked Data Catalogs with LODAtlas[END_REF] and SPARQLES [START_REF] Vandenbussche | SPARQLES: Monitoring Public SPARQL Endpoints[END_REF] focus on RDF datasets and SPARQL endpoints respectively.

Even though some of these portals have gained significant popularity due to the large number of datasets that they index, they suffer relentless flaws. Firstly, they are centralized registries with a somehow restricted scope. Consequently, potential data consumers may have to query several portals one by one, accommodating the various query interfaces, to discover suitable datasets. Secondly, in many cases, datasets are manually registered and annotated by dataset producers, thereby raising concerns about outdated metadata or deprecated services. Thirdly, metadata-based search results have a limited relevance. Typically, searching datasets by keywords and data formats is a first step in the discovery process, but a potential consumer needs deeper insight in the data themselves and the technical interfaces available to query the dataset. In this respect, WSDL-based semantic Web services (e.g. OWL-S [START_REF] Burstein | OWL-S: Semantic Markup for Web Services[END_REF] or SAWSDL [START_REF]Semantic Annotations for WSDL and XML Schema[END_REF]) tackled this question with a thorough description of the exchanged messages, yet often failing to describe the actual dataset being queried. Besides, they were better suited to the controlled environment of companies [START_REF] Lo | Semantic Web Services in Corporate Memories[END_REF] than the open environment of the Web. By contrast, the VoID vocabulary [START_REF] Alexander | Describing Linked Datasets with the VoID Vocabulary[END_REF] can help describe RDF datasets with regards to vocabularies, classes and properties used, links to other datasets, etc. But it does not address the description of what properties a resource may typically have nor how the resources relate to each other, which are key criteria in the discovery and selection of datasets.

To spur and enable automatic discovery and consumption of datasets at Web-scale, we believe that a few principles should drive future research and developments.

(1) Metadata-based search is not enough. As we pointed out above, metadata-based search using e.g. keywords, data formats, vocabularies or even classes and properties used in an RDF dataset, is just a first step in the discovery process.

For example, assume a biologist wants to develop a software agent capable of browsing Linked Data and gathering photos related to biological species. The agent may submit several queries to repositories such as LODAtlas looking for datasets whose textual description contains keywords "photo" and "biodiversity", or those whose VoID description (if any) mentions classes representing photographies and biological taxa. Within the matching datasets, however, nothing guarantees that photographic resources do actually depict biological species; photographies may well be scans of academic papers related to the species. Hence, the agent has no choice but to query the dataset in order to get insight into it and find out if it matches the search. This simple example illustrates the lack of in-depth semantic description of datasets, that would consist of the resources (what are the actual properties of photographic and taxonomic resources) along with their mutual relationships. [START_REF] Ben Ellefi | RDF Dataset Profilinga Survey of Features, Methods, Vocabularies and Applications. Semantic Web -Interoperability[END_REF] The discovery of datasets at Web-scale should leverage the power of Web search engines. Major search engines such as Google, Yahoo and Bing crawl and index an unprecedented breadth of information every day. They already harvest the content of specialized open data portals, in particular by taking advantage of the growing use of the Schema.org vocabulary [START_REF] Guha | Schema.Org: Evolution of Structured Data on the Web[END_REF]. Google has recently opened a beta service specifically dedicated to dataset search 4 . Therefore, despite concerns raised by the Web centralization effect of search engines, it is worth studying how we can take advantage of their services to enable the discovery and querying of datasets at Web scale. (3) The description of datasets and their query services should rely on well adopted (de-facto) standards. Enabling the automatic discovery and querying of datasets at Web-scale means that, at some point, a consensus should be reached with respect to technologies and practices. Such a consensus may emerge only if the selected approaches put little constraints on and require little efforts from those in charge of describing datasets, publishing and maintaining query services thereof. This means relying on existing, well-adopted standards or de-facto standards.

In terms of semantic description, existing vocabularies should be leveraged, ranging from mature and widely used W3C standards to de-facto standards such as Schema.org that benefits from a large and growing adoption even though it still lacks terms in many domains. Additionally, selected approaches should enjoy sufficient and appropriate tooling with APIs in various programming languages. Such tools should be relatively simple in the sense that (i) they should not require a long learning curve from developers, and (ii) they should be easy to deploy and maintain. In this respect, the example of WSDL-based semantic Web service frameworks is inspiring: their deployment and operation required significant efforts that only companies with solid IT services were ready to invest [START_REF] Pautasso | Big" Web Services: Making the Right Architectural Decision[END_REF]. But when seeking Web-scale adoption, such perceived complexity would have a counterproductive effect.

In a previous work, we defined the SPARQL Micro-Service architecture [START_REF] Michel | Integration of Web APIs and Linked Data Using SPARQL Micro-Services-Application to Biodiversity Use Cases[END_REF] aimed at querying Web APIs using SPARQL [START_REF] Harris | SPARQL 1.1 Query Language[END_REF], thus bridging the Linked Data and Web API worlds. We suggested that this approach could foster the emergence of an ecosystem of SPARQL services published by independent providers, allowing Linked Data-based applications to glean pieces of data from a wealth of distributed data sources, in a scalable and reliable manner.

In this article, we present further exploratory works aimed at applying the principles set out above, and thereby make SPARQL micro-services effectively discoverable and queryable at Web-scale. We describe and explain our architectural and modeling choices. Let us however underline that alternative choices may be figured out, driven by different incentives or trade-offs. We touch upon these considerations in the last section.

Envisaged use case. Figure 1 outlines the main steps of a typical use case as we see it, along with the main choices that we made. A SPARQL micro-service produces a Web page (step 1) whose primary goal, beyond providing developers with appropriate documentation and a testing interface, is to be processed by Web crawlers. It embeds rich markup data, notably based on Schema.org, to enhance indexing and help search engines yield more accurate results. The Web page is generated dynamically from the service self-description that consists of a SPARQL Service Description (SD) graph [START_REF] Tood | SPARQL 1.1 Service Description[END_REF] and a SHACL shapes graph [START_REF]Shapes Constraint Language (SHACL)[END_REF]. Together, they provide various metadata, a description of the graphs that the service typically spawns, the service inputs and outputs and the way they relate to one another. An application willing to carry out a certain task first queries search engines (step 2) for datasets matching certain keywords. From the search results, it extracts and looks up SPARQL endpoint URLs. SPARQL micro-services return an SD document that links to the shapes graph. In turn, the application fetches the shapes graph that allows verifying whether the service is indeed suited for the task (step 3). Based on the description of the service inputs, the application can submit an appropriate SPARQL query to the micro-service (step 4).

The rest of this article is organized as follows. Section 2 briefly summarizes the concepts of SPARQL micro-services and presents a quick example. Section 3 then presents the way we describe microservices in a machine-readable manner. Section 4 focuses on the way micro-services are made discoverable at Web scale. Related works are discussed in section 5 while the last section brings elements of discussion and suggests future leads.

BACKGROUND

In [START_REF] Michel | SPARQL Micro-Services: Lightweight Integration of Web APIs and Linked Data[END_REF], we described the SPARQL Micro-Service architectural principles. Later on in [START_REF] Michel | Integration of Web APIs and Linked Data Using SPARQL Micro-Services-Application to Biodiversity Use Cases[END_REF], we extended this description and reported on several biodiversity-related use cases. In this section, we briefly summarize these previous works.

The SPARQL Micro-Service architecture addresses the problem of combining Linked Data with data from non-RDF Web APIs. A SPARQL micro-service is a lightweight SPARQL endpoint that provides access to a graph generated at run-time. This graph is shaped by the Web API service being wrapped, the arguments passed to the micro-service and the types of RDF triples it is designed to produce. How the arguments are passed to a SPARQL micro-service, and how the Web API response is transformed into a SPARQL result, are implementation choices.

In accordance with the micro-service architecture principles [START_REF] Newman | Building Microservices[END_REF], a SPARQL micro-service is typically designed to be loosely coupled (it is deployed independently of other services, possibly using lightweight container technologies such as Docker 5 ) and fine-grained: it provides access to a small, resource-centric graph corresponding to a small fragment of the whole dataset served by the Web API.

Interestingly, this architecture can be used to assign dereferenceable URIs to Web API resources that do not have URIs in the first place: a micro-service responds to SPARQL queries by assigning URIs to Web API resources, while other micro-services are designed to dereference these URIs to RDF content. This entails an effective solution to bridge Web APIs, that are designed as closed worlds, with the open world of Linked Open Data.

Implementation. We implemented a lightweight PHP prototype available on GitHub6 under the Apache 2.0 license. The prototype focuses on JSON-based Web APIs, and expects arguments of a micro-service to be passed as parameters of the service URL's query string. Figure 2 illustrates how a SPARQL micro-service S µ evaluates a SPARQL query Q. In step 1, S µ receives query Q and extracts the set Arд w of arguments from the HTTP query string. In step 2, it invokes the Web API with the arguments in Arд w , in addition to any other parameter required by the Web API. In step 3, S µ translates the JSON response into an RDF graph: it carries out a first mapping towards selected vocabularies by applying a JSON-LD profile [START_REF] Sporny | JSON-LD 1.0. A JSON-based Serialization for Linked Data[END_REF] to the response; the resulting graph G is loaded into a local triple store; if mappings are needed that JSON-LD cannot express, S µ runs a SPARQL INSERT query that enriches G with additional triples. Finally, S µ evaluates Q against G and returns the result to the client.

Alternative argument-passing method. In the method described above, the arguments of a SPARQL micro-service are passed as query string parameters rather than RDF terms. One advantage is that it spares creating new terms whenever a Web API-specific argument has no counterpart in existing vocabularies. Nevertheless, a downside is that the semantics of such a SPARQL micro-service differs from that of a standard SPARQL endpoint. Indeed, the SPARQL protocol treats a service URL as a black box, i.e. it does not identify nor interpret URL parameters apart from those specified in the SPARQL protocol itself. By contrast, in a SPARQL micro-service the query string parameters are meaningful arguments that shape the virtual graph being queried. Therefore, since one of our goals in this article is to comply with standards (principle 3), we have recently implemented an alternative method wherein arguments are passed as regular RDF terms of the SPARQL query graph pattern. To illustrate this, we now introduce an example that we shall reuse throughout the rest of this article.

Running example. Let us consider the service of Flickr's Web API that returns a list of photos matching some criteria 7 . We define S µf as a SPARQL micro-service8 that wraps this Flickr service and returns photos of a given biological species. S µf takes as argument the species scientific (taxonomic) name, and searches photos matching this name. It abides by the convention that photos of a species should be tagged with the species scientific name formatted as taxonomy:binomial=<scientific name>9 . S µf expects the scientific name argument to be passed as the object of the dwc:scientificName predicate.

Listing 1 depicts a query, Q 1 , that meets this requirement. It aims at retrieving photos depicting species Delphinus delphis, the common dolphin. When it evaluates Q 1 , S µf first extracts the scientific name argument from the graph pattern (highlighted line) and builds the following Web API invocation URL: Listing 2: Example graph produced by micro-service S µf to evaluate query Q 1 .

it evaluates Q 1 against this graph, yielding the response exemplified below in the SPARQL Query Results JSON format [START_REF] Seaborne | SPARQL 1.1 Query Results JSON Format[END_REF]:

{ "head head head ": { " vars ": [ " title ", " img " ] }, "results results results ": { "bindings bindings bindings ": [ { " title ": { "type type type ": " literal ", "value value value ": " Delphinus delphis 5 (13 -7 -16 San Diego )" }, { " img ": { "type type type ": " uri ", "value value value ": " https :// farm6 . staticflickr . com /5718/ \ 31173091626 _88c410c3f2_z . jpg " } } ] } }

MACHINE-READABLE DESCRIPTION OF SPARQL MICRO-SERVICES

Building on the work presented in section 2, we aim at proposing a mechanism that enables a software agent to discover, select and invoke the SPARQL micro-services that are relevant for a certain task.

In section 1, we pointed out three principles that, we believe, should help pursue this goal: (1) have rich descriptions of data sources that go beyond common metadata, (2) leverage Web search engines to discover data sources, and (3) rely on well-adopted standards. This section presents the modeling choices we made with respect to principle (1), section 4 deals with principle (2) while principle (3) is transversal to both sections. A rich SPARQL micro-service description should span two distinct levels further detailed in this section. The high-level description consists of metadata about the data being queried (keywords, publisher, license, vocabularies, graphs, etc.), as well as metadata about the micro-service itself (supported operations, result formats, etc.). The functional description describes the actions the services carries out: what are the types of resources involved, what are their recommended/expected properties, what are the service arguments and how they relate to the resources.

High-level Description

To describe SPARQL micro-services, we use SPARQL Service Description (SD) [START_REF] Tood | SPARQL 1.1 Service Description[END_REF] which is both a vocabulary to describe SPARQL endpoints and a method requiring compliant endpoints to return an SD document when their URL is looked up.

Listing 3 depicts a snippet of the SD document (in the Turtle syntax) for the example service S µf introduced in section 2. The service is at the same time an instance of the SD Service class and the class of SPARQL micro-services sms:Service (line 17). Common metadata are provided lines 19 to 26, such as a name and description, keywords, supported SPARQL language and result formats. A VoID description can also be embedded here, as exemplified in line 29 (the default dataset is stated to be a void:Dataset) and lines 34 to 36 10 . Additional triples are not depicted here for conciseness, such as the service publisher and an example SPARQL query. Note that many more metadata could be provided, such as common dataset profile features [START_REF] Ben Ellefi | RDF Dataset Profilinga Survey of Features, Methods, Vocabularies and Applications. Semantic Web -Interoperability[END_REF]. Furthermore, in the implementation we demonstrate here, we wrote the SD document manually. Future works could consider dataset profiling techniques to (at least partially) automate this generation.

The SD document is obtained by looking up the service URL. Content negotiation is supported such that a Web browser will obtain an HTML page, whereas a Linked Data application would typically require one of the supported RDF serialization syntaxes. The SD document itself is a named graph of the dataset served by the SPARQL micro-service (line 31). The interested reader may view the full range of metadata by looking up the named graph URI 11 in a Web browser (this will typically return an RDF/XML representation) or by issuing the following command on a standard Linux system: curl --header " Accept : text / turtle " \ http :// sms . i3s . unice . fr / sparql -ms / flickr / getPhotosByTaxon_sd /

Functional Description

There exist various options to represent the functional description of a service. In section 5 we discuss some of them. As far as SPARQL micro-services are concerned, we choose to leverage several vocabularies for this purpose: SHACL [START_REF]Shapes Constraint Language (SHACL)[END_REF], Schema.org and Hydra [START_REF] Lanthaler | Hydra: A Vocabulary for Hypermedia-Driven Web APIs[END_REF]. SHACL Description of the Dataset. SHACL, the Shapes Constraint Language, is designed for the validation of RDF graphs (called data graphs) against a set of conditions expressed in the form of shapes graphs. In our context, instead of using a shapes graph G sh a posteriori to validate the data graph produced by a 10 As an alternative, a VoID description could be made available using the well-known URIs mechanism, at path /.well-known/void. Listing 3: Snippet of the Service Description of SPARQL micro-service S µf .

SPARQL micro-service, we consider G sh as a specification of the graphs that a SPARQL micro-service can generate. The shapes graph is linked to the SD document as follows: the default dataset has a default graph that is validated by the shapes graph (property shacl:shapesGraph lines 30). The shapes graph is itself one of the named graphs of the default dataset (line 32).

A short snippet of the shapes graph corresponding to service S µf is given in Listing 4. The interested reader may check the complete shapes graph on GitHub 12 or by dereferencing its URI 13 . It states that an instance of class dwc:Taxon (lines 4-5) should have 12 Complete shapes graph on GitHub: https://frama.link/we_EQWnC 13 Shapes graph URI: http://sms.i3s.unice.fr/sparql-ms/flickr/getPhotosByTaxon_sd/ ShapesGraph exactly three properties: rdf:type with object dwc:Taxon (lines 9-10), shacl:image whose object should be validated against another shape (lines 12-13) and property dwc:scientificName that should have exactly one literal object (lines [START_REF] Kopecky | hRESTS: An HTML Microformat for Describing RESTful Web Services[END_REF][START_REF] Lanthaler | A Semantic Description Language for RESTful Data Services to Combat Semaphobia[END_REF]. Notice that the graph pattern of query Q 1 (Listing 1) specifically matches these constraints.

Description of the Input Arguments. We now need to characterize the micro-service input arguments, how they are extracted from a SPARQL graph pattern, and how they map to parameters of the Web API wrapped by the micro-service. We define the Web API as the micro-service data source (line 39 of Listing 3). It is typed as a Schema.org WebAPI having one potential action of type SearchAction (lines 40-44). Note that an alternative is currently being discussed within the Schema.org community, that links EntryPoint objects to a WebAPI [START_REF] Ralphson | WADG0001 WebAPI type extension[END_REF]. The search action is also typed as a Hydra IriTemplate whose template string is the Web API invocation URL (lines 46-48). Each mapping (lines 50-58) maps a parameter used in the template string to a term of the SPARQL query by pointing to a specific property using hydra:property. In our example, the scientific name, denoted "{name}" in the template string (line 48), is mapped to property dwc:scientificName (line 57). Upon invocation, the service simply reads the value of property dwc:scientificName in the graph pattern, and substitutes it with "{name}" in the template string.

This solution is simple and concise, but it presents two downsides: (i) hydra:property only names a property but does not put any other constraint such as what is the subject of this property, or how many values are allowed; (ii) there is no explicit relationship between the input argument and the shapes graph. Hence, to specify the input arguments more precisely, an alternative is to map the parameter to a property shape of the shapes graph. In our example, this would be expressed by replacing line 57 with the following:

shacl : sourceShape < ShapesGraph # NamePropertyShape >;
The referenced property shape is defined in Listing 4 (lines [START_REF]Shapes Constraint Language (SHACL)[END_REF][START_REF] Kopecky | hRESTS: An HTML Microformat for Describing RESTful Web Services[END_REF][START_REF] Lanthaler | A Semantic Description Language for RESTful Data Services to Combat Semaphobia[END_REF]. Not only it instructs that the scientific name should be given by property dwc:scientificName, but also that this property should be attached to an instance of the dwc:Taxon class and that there should be only one such property.

Advantages of using SHACL. We believe that using SHACL presents two advantages: (1) SHACL's expressiveness allows denoting complex relationships between resources (e.g. cardinality, predicate paths). Even though this description is schema-based, it is sufficient to enable SPARQL micro-service discovery and selection since, by construction, the shape of generated graphs is know at design time. By contrast, SPARQL federated query engines generally rely on dynamic instancebased statistics because the graphs being queried can hardly be characterized by a static SHACL description. For instance, it would be impossible to define a precise shapes graph of crowd-sourced graphs such as DBpedia.

(2) A SHACL shapes graph is itself an RDF graph. Therefore, a software agent can leverage existing tooling to reason upon it and verify whether the SPARQL micro-service fulfills the agent's goals. As an illustration, we are currently developing a SPARQL microservice federated query engine 14 . Given an input SPARQL query, the engine searches candidate SPARQL micro-services whose inputs 14 Beta version available at https://frama.link/VWG7r8PF. are satisfied by the query. It then selects those whose shapes graphs validate some triple patterns of the query, and finally rewrites the input query into a UNION of SERVICE clauses that invoke SPARQL micro-services. Each step of the processing (selection, matchmaking, query rewriting) is performed using SPARQL queries that involve the SD documents, the shapes graphs and the input query.

Invocation

To process an incoming SPARQL query, a SPARQL micro-service needs to extract the input arguments from the query graph pattern.

For instance, when a client invokes S µf with query Q 1 (Listing 1), S µf must extract the object of property dwc:scientificName (Delphinus delphis) to perform the subsequent invocation of Flickr's Web API. This involves reasoning simultaneously on the query graph pattern, the SD document that describes the arguments mappings, and optionally the shapes graph if the mappings refer to property shapes. Since a SPARQL graph pattern is not represented in RDF, we first translate the incoming query into its SPIN representation [START_REF] Knublauch | SPIN -SPARQL Syntax[END_REF] that we load into the local triple store as a temporary graph. A major advantage of this approach is that extracting the input arguments can be carried out declaratively within a single SPARQL query rather than in custom code. This query is shown in Listing 5. The first member of the UNION clause (lines 4-11) matches the case where arguments are denoted with hydra:property: it retrieves the object of hydra:property (line 8), i.e. dwc:scientificName, and looks for it in the SPARQL query SPIN graph (line 11). By contrast, the second member (lines 15-34) matches the case where arguments are denoted with a property shape.

Once the arguments have been extracted, the rest of the SPARQL query evaluation is performed as illustrated in section 2.

Implementation. To implement this solution, we deployed Corese [START_REF] Corby | The KGRAM Abstract Machine for Knowledge Graph Querying[END_REF], an in-memory triple store, as the SPARQL engine underlying SPARQL micro-services. Corese implements the SPARQL Template Transformation Language (STTL) [START_REF] Corby | STTL: A SPARQL-Based Transformation Language for RDF[END_REF] and comes with a built-in STTL SPARQL-to-SPIN transformation. For greater flexibility, our implementation allows passing arguments with VALUES or FILTER clauses, which entails a substantially more complicated query than the one depicted in Listing 5. In particular, it leverages the LDScript [START_REF] Corby | LDScript: A Linked Data Script Language[END_REF] SPARQL extension to define functions able to parse the nested RDF lists entailed by the VALUES clause 15 .

From a more general perspective, the approach we propose considers the service as a coherent, self-contained, reflexive system where RDF and SPARQL are used internally for the service selfdescription and configuration, at run-time for the query processing, and as the service external interface.

WEB-SCALE DISCOVERY OF SPARQL MICRO-SERVICES

In section 1, we suggested that Web search engines can play a key role in enabling the automatic discovery and querying of data sources at Web-scale. Applied to our context, this means that SPARQL micro-services should be published along with a dedicated Web page to be indexed by search engines. Furthermore, major search engines now recommend the inclusion of markup data in Web pages to enhance indexing and consequently yield more accurate results. Therefore, to spur Web-scale discovery while avoiding redundant work, we propose that SPARQL micro-services dynamically transform their service description into Web pages that embed rich markup data meant for search engines. Following content negotiation principles, the micro-service URL dereferences to this Web page if it is looked up by a Web browser, while it dereferences to the SPARQL SD document when requested with appropriate RDF media types.

To standardize such markup data, Google, Yahoo, Bing and Yandex support the Schema.org community project that has become a de-facto standard. In particular, Google's recently launched Dataset Search service 16 exploits Schema.org's Dataset term 17 as well as equivalent terms from the DCAT W3C recommendation [START_REF] Maali | Data Catalog Vocabulary (DCAT). W3C Recommendation[END_REF]. A Schema.org Dataset consists of a set of distributions represented by means of the DataDownload object that, unfortunately, is not suited to depict API resources such as SPARQL endpoints. Ongoing discussions are held within the Schema.org community regarding how to annotate a Dataset with the interfaces that allow access it 18 . Until a consensus be eventually adopted, a common workaround implemented by the CKAN data portal 19 is to associate to the DataDownload object the encoding format "api/sparql". Although semantically questionable ("api/sparql" is not a standard IANA media type 20 ), this practice is a trade-off between the need for valid semantic description and the need for effective Web-scale discovery means. Furthermore, given the popularity of CKAN for hosting data portals, this practice tends to spread out.

In the context of SPARQL micro-services, we mitigate this issue with a twofold approach. On the one hand, we comply with the DataDownload + "api/sparql" encoding format practice to ensure maximum discoverability. On the other hand, we embed additional DCAT Dataset and Distribution objects conveying similar information in a more semantically formal manner. Both ways are depicted in Listing 6, lines 24-30 and 38-49 respectively.

Results. The combination of standard content negotiation, semantic Web standards and current Linked Data practices fuels a human-friendly documentation and testing interface on one side and a machine-readable Linked Data description on another side. Furthermore, this combined use pushes "RDF in HTML" descriptions to Web crawlers and indexes in such a way that the described services can be effectively discovered and called by both humans and machines as if they were just another data source.

As an illustration, at the time of writing, the example service S µf can be discovered in Google Dataset Search using the keywords "biodiversity" and "photography". Figure 3 shows a snapshot of the result page. Notice that the available download format is appropriately set to SPARQL. Furthermore, adding keyword "sparql" returns the micro-service as the first result in the result page.

Implementation. The Web page generation is performed using the technologies already introduced in section 3.3. An STTL transformation 21 instantiates HTML templates with elements from the SPARQL SD document. The embedded markup data (exemplified in Listing 6) is generated by a SPARQL CONSTRUCT query whose result is passed to a generic built-in STTL transformation that serializes RDF data in JSON-LD. All these transformations are 16 Google Dataset Search: http://g.co/datasetsearch 17 Schema.org Dataset: https://schema.org/Dataset 18 https://github.com/schemaorg/schemaorg/issues/1423. Accessed Jan. 30th 2019. 19 The CKAN project: https://ckan.org/ 20 IANA media types: https://www.iana.org/assignments/media-types/ 21 The whole transformation code is available at: https://frama.link/hBDkM7ep. 1 { 2 " @context ": [ 3 " http :// schema . org ", 4

{ " dcat ": " http :// www . w3 . org / ns / dcat #" , 5

" frmt ": " http :// www . w3 . org / ns / formats /" } 6 ], 7 8 " @type ": "Dataset", 9 " identifier ": 10 " http :// sms . i3s . unice . fr / sparq -ms / flickr / getPhotosByTaxon_sd /" , 11 " name ": " Search for Flickr photos by scientific name ", 12 " description ": "..." , 13 " publisher ": { 14 " @type ": " Organization ", 15

" name ": " Universite Cote d ' Azur , CNRS , Inria , I3S ", 16 }, 17 " keywords ": [ " biodiversity ", " lifesciences ", " photography " ], 18 " isBasedOn ": { 19 " @type ": " CreativeWork ", 20 " @id ": " https :// www . flickr . com / services / api /" , 21

" name ": " Flickr Web API " 22 }, 23 24 "distribution": { 25 " @type ": "DataDownload", independent of any service and domain. The whole process happens at run-time upon look-up of the micro-service URL. A snapshot of the Web page generated by service S µf is displayed in Figure 4, and the reader may access this page by pointing a Web browser at http://sms.i3s.unice.fr/sparql-ms/flickr/getPhotosByTaxon_sd/.

RELATED WORKS

The work presented in this article addresses two fundamental questions that have been studied under many different perspectives: capturing the functionality of Web services on one side, and automating their discovering and consumption by software agents on the other side.

Works about semantic Web services, whether "big" WSDL-based (e.g. OWL-S [START_REF] Burstein | OWL-S: Semantic Markup for Web Services[END_REF], SAWSDL [START_REF]Semantic Annotations for WSDL and XML Schema[END_REF]) or REST-based (e.g. WADL [START_REF] Hadley | Web Application Description Language[END_REF]), have long tackled the question of capturing the functionality of a service through the semantic description of their inputs, outputs and the way they relate to one another. These models, that Clicking on the sms.i3s.unice.fr link opens the micro-service Web page depicted in Figure 4. support automatic discovery, invocation and composition of Web services, usually entail the deployment of complex frameworks requiring advanced skills and tooling. Besides, service discovery is made possible using a centralized repository such as the Universal Description Discovery and Integration (UDDI) registry 22 . As a consequence, they are better suited to the controlled environment of 22 UDDI specification: http://uddi.org/pubs/uddi-v3.0.2-20041019.htm companies [START_REF] Lo | Semantic Web Services in Corporate Memories[END_REF] than the open, loosely constrained environment of the Web that we wish to address. By contrast, Web APIs are quite simple to deploy and interact with. Still, it is hardly possible to discover and invoke them automatically insofar as they commonly rely on proprietary vocabularies described in Web-based documentation with little concern for semantic interoperability. To fulfill this lack, some initiatives seek to enrich existing human-readable documentation of Web APIs with markup data so as to make it machine-processable. They rely on microformats (e.g. hRESTS [START_REF] Kopecky | hRESTS: An HTML Microformat for Describing RESTful Web Services[END_REF]) possibly joined to existing service ontologies (e.g. MicroWSMO [START_REF] Fischer | MicroWSMO v2 -Defining the Second Version of MicroWSMO as a Systematic Approach for Rich Tagging[END_REF]), or RDFa (e.g. SA-REST [START_REF] Gomadam | SA-REST: Semantic Annotation of Web Resources[END_REF]). These methods are however more concerned with describing the service interface (operations, parameter types) than its actual functionality. Indeed, the description of the resources manipulated is delegated to domain ontologies that provide terms for classes and properties, but often put little constraints on how to use them. By contrast, we harness SHACL specifically to address this lack. SHACL can describe rich constraints on what can be stated, thus making it possible to specify in a comprehensive manner how resources relate to each other.

OpenAPI 23 takes the problem the other way round: it equips a Web APIs with a machine-readable documentation, that, in turn, can be compiled into a Web page. This is closer to our approach, yet, this description remains at a syntactic level essentially enabling the automatic generation of server-and clients-side stubs, very similar to what WSDLs enabled for "heavy" Web services.

Linked REST APIs (LRA) [START_REF] Serrano | Linked REST APIs: A Middleware for Semantic REST API Integration[END_REF] is a framework dedicated to the semantic annotation of Web APIs and the automatic specification of SPARQL query execution plans that invoke these Web APIs. The framework relies on a centralized repository that stores the Web APIs descriptions and offers search services. Several key differences with our work can be pointed out. With SPARQL micro-services, we seek to set up a totally distributed architecture wherein independent service providers may publish SPARQL micro-services that can be discovered using regular Web search engines, rather than a centralized repository. Furthermore, LRA describes a Web API by means of a custom vocabulary and relies on a SPARQL graph pattern to serve as a functional description. To spur large adoption, we instead stick to standard vocabularies, and we use SHACL to describe resources as it allows for more expressiveness than a sheer SPARQL graph pattern.

RESTdesc [START_REF] Verborgh | Description and Interaction of RESTful Services for Automatic Discovery and Execution[END_REF] is a semantic description format for hypermedia APIs. It captures the functional description of APIs in Notation3 [START_REF] Berners-Lee | Notation3 (N3): A Readable RDF Syntax[END_REF], a language extending RDF's data model with variables, existential and universal quantifiers, and logical implications. RESTdesc relies on the HTTP mechanisms and RESTful principles for the discovery and invocation of semantically described Web services. Starting from a known URI, an application can follow its nose by resolving links and making sense of Notation3 service descriptions. This is an elegant solution that however requires Notation3 reasoners able to interpret the advanced features of quantification and logical implications. Such reasoners exist but are far less common than SPARQL-based implementations available in many programming languages. Since we seek a solution that can be adopted easily by a large community of independent actors, leveraging more common standards such as regular RDF and SPARQL is probably more promising.

In line with our idea of leveraging Web search engines to discover relevant datasets and query services, SpEnD [START_REF] Yumusak | SpEnD: Linked Data SPARQL Endpoints Discovery Using Search Engines[END_REF] is a metacrawler designed to discover SPARQL endpoints. It first creates a list of keywords commonly found on Web pages advertising SPARQL endpoints, such as the pages of DataHub. It then looks for these keywords on search engines, explores the result Web pages looking for SPARQL endpoint URLs and looks up these URLs in search for VoID or SPARQL SD documents. This kind of approach is clearly what could be implemented to discover SPARQL micro-services at Web scale. We believe that the usage of well-adopted markup data could help enhance search results and, in this respect, dataset-search services such as Google Dataset Search could be more effective than generic Web search engines.

CONCLUSION AND PERSPECTIVES

In this article, we address the problem of enabling automatic discovery and consumption of data sources at Web scale. We suggested that three principles should be considered to pursue this goal: (1) provision rich descriptions of data sources and query services, (2) leverage the power of Web search engines to discover data sources, and (3) rely on simple, well-adopted standards that come with extensive tooling. We applied these principles to the concrete case of SPARQL micro-services that aim at querying Web APIs using SPARQL. The proposed solution considers a SPARQL Service Description (SD) document as the description central point. It links to a SHACL shapes graph describing precisely the resources manipulated by the micro-service. It also connects the resources to the micro-service inputs, thereby coming up with a rich functional description that allows a software agent to decide whether this micro-service can help in carrying out a certain task. To enable accurate discovery using common Web crawlers, the SD document can be dynamically transformed into a Web page embedding rich markup data based on Schema.org's Dataset term and the DCAT vocabulary.

From a general perspective, the combination of standard content negotiation, semantic Web standards and Linked Data practices fuels a human-friendly documentation and machine-readable description that make it possible for humans and machines alike to discover and invoke SPARQL micro-services as if they were just another data source.

We showed that our approach is effective as our example SPARQL micro-service can be successfully discovered using the Google Dataset Search engine (as illustrated in Figure 3). From this point on, a framework such as SpEnD (described in section 6) could be extended to accommodate the invocation of SPARQL micro-services. Service composition-based query answering systems could fetch the shapes graphs of candidate SPARQL micro-services, check the compatibility of their inputs and outputs with respect to the query to process, and finally compute and enact valid compositions. In particular, SPARQL query federation is a specific type of Web service composition wherein any piece of data in the federated graphs may play the role of either an input or an output. Existing federated query engines could be extended so as to reason on the description of SPARQL micro-services and come up with query plans that respect SPARQL micro-services' input requirements.

As pointed out in section 4, denoting a SPARQL endpoint using Schema.org terms is still quite unpractical at the moment. From a more general perspective, describing the multiple interfaces that a client may use to access a dataset is an increasingly pressing need. The Schema.org community is currently thinking this through with discussions revolving around the Dataset, WebAPI and EntryPoint terms. Concomitantly, the DCAT community is working out the next version of the W3C DCAT recommendation [START_REF] Gonzalez Beltran | Data Catalog Vocabulary (DCAT) -revised edition[END_REF] that defines the generic concept of DataService meant to serve dataset distributions. The term is flexible enough to accommodate various types of interfaces, providing notably a contract the interface conforms to and an out-of-band description that may typically be a SPARQL SD document in our context.

In the current state of our work, SHACL graphs are used as a specification of the graphs that a SPARQL micro-service can generate. We can think of two interesting leads for future works in this respect. Firstly, once a shapes graph is published with its own dereferenceable URI, it can be reused by SPARQL micro-services providers, thereby sparing time and making it possible to share common practices. A second lead could be to consider SHACL as a way for a client to request responses in a certain shape. This would amount to some sort of extended content negotiation where a client could express that it would prefer a response not only favoring a vocabulary over another, but also describing resources and their relationships according to a certain shape, as much as possible.

Finally, whether our approach succeeds in reaching principle (3) (rely on well-adopted standards) is debatable and possibly a matter of perspective and community. Some people contend that Semantic Web standards are not likely to be largely adopted by Web developers [START_REF] Lanthaler | A Semantic Description Language for RESTful Data Services to Combat Semaphobia[END_REF] due to the perceived complexity of RDF and SPARQL, as compared to RESTful APIs for instance. Besides, SHACL is a rich language, yet perhaps too rich to gain large adoption. In the end however, we do believe that there will be room for different types of interfaces, suited to different contexts and scenarios. This article primarily intends to propose a research direction, not a ready-to-use solution. And we encourage the interested readers to explore alternative architectural and modeling choices.

Figure 1 :

 1 Figure 1: Envisaged use case spanning the indexing, discovery and invocation of a SPARQL micro-service.

Figure 2 :

 2 Figure 2: SPARQL micro-service processing workflow.

Figure 3 :

 3 Figure 3: Google Dataset Search result page showing the example SPARQL micro-service S µf .Clicking on the sms.i3s.unice.fr link opens the micro-service Web page depicted in Figure4.

Figure 4 :

 4 Figure 4: Web page automatically generated from the description of SPARQL micro-service S µf .

  prefix prefix prefix schema : < http :// schema . org /> prefix prefix prefix dwc :< http :// rs . tdwg . org / dwc / terms /> Listing 1: Query Q 1 can be submitted to SPARQL microservice S µf in order to retrieve photos of species Delphinus delphis.

	SELECT SELECT SELECT ? title ? img WHERE WHERE WHERE {
	? taxon a dwc : Taxon ;
	dwc:scientificName "Delphinus delphis";
	schema : image [
	a schema : Photograph ;
	schema : name ? title ;
	schema : contentUrl ? img .
	].
	}
	[] a dwc : Taxon ;
	dwc : scientificName " Delphinus delphis ";
	schema : image < http :// example . org / ld / flickr / photo /31173091626 >.

< http :// example . org / ld / flickr / photo /31173091626 > a schema : Photograph ; schema : name " Delphinus delphis 5 (13 -7 -16 San Diego )"; schema : contentUrl < https :// farm6 . staticflickr . com /5718/31173091626 _88c410c3f2_z . jpg >; schema : mainEntityOfPage < https :// flickr . com / photos /10770266 @N04 /31173091626 >; schema : fileFormat " image / jpeg "; schema : author [ schema : identifier "10770266 @N04 "; schema : url < https :// flickr . com / photos /10770266 @N04 > ].

  Listing 5: Extraction of input argument predicates and values (variables ?predicate and ?value) from a SPARQL query submitted to a SPARQL micro-service. The default dataset contains the SPARQL query SPIN graph, the shapes graph and the SPARQL SD graph.

	1 SELECT SELECT SELECT DISTINCT DISTINCT DISTINCT ? name ?predicate ?value
	2 WHERE WHERE WHERE {
	3 {
	4	# Predicate given with hydra : property
	5	[] a sd : Service ;
	6	dct : source [ schema : potentialAction [ hydra : mapping [
	7	hydra : variable ? name ;
	8	hydra:property ?predicate;
	9	]]].
	10
	11	[] sp : predicate ?predicate; sp : object ?value.
	12 }
	13 UNION UNION UNION
	14 {
	15	# Predicate given through a property shape
	16	[] a sd : Service ;
	17	dct : source [ schema : potentialAction [
	18	hydra : mapping [
	19	hydra : variable ? name ;
	20	shacl : sourceShape ? propShape ;
	21	]]].
	22
	23	? nodeShape a shacl : NodeShape ; shacl : property ? propShape .
	24	? propShape a shacl : PropertyShape ; shacl:path ?predicate.
	25	OPTIONAL OPTIONAL OPTIONAL {
	26	? nodeShape shacl : property [
	27	shacl : path rdf : type ; shacl : hasValue ? class
	28	]
	29	}
	30
	31	[] sp : subject ? subject ; sp : predicate ?predicate; sp : object ?value.
	32	OPTIONAL OPTIONAL OPTIONAL {
	33	[] sp : subject ? subject ; sp : predicate rdf : type ; sp : object ? class .
	34	}
	35 }
	36 }

https://ckan.org/about/instances/

https://datahub.ckan.io/

https://www.programmableweb.com/

https://www.blog.google/products/search/making-it-easier-discover-datasets/

https://www.docker.com

https://github.com/frmichel/sparql-micro-service/tree/0.3.1/

https :// api . flickr . com / services / rest /?format format format = json &method method method = flickr . photos . search & tags tags tags = taxonomy : binomial = Delphinus + delphis

https://www.flickr.com/services/api/flickr.photos.search.html

The code of this service is available at https://frama.link/kVhhnE-v.

This is a common convention used on Flickr for biodiversity resources, in particular the Encyclopedia of Life group (https://www.flickr.com/groups/806927@N20) and the Biodiversity Heritage Library (https://www.flickr.com/photos/biodivlibrary).

The complete query is available at https://github.com/frmichel/sparql-micro-service/ tree/0.3.1/src/sparqlms/resources/read_input_from_gp.sparql.

https://github.com/OAI/OpenAPI-Specification