Modelling provenance in hydrologic science: a case study on stream ﬂ ow forecasting

The web, and more recently the concept and technology of the Semantic Web, has created a wealth of new ideas and innovative tools for data management, integration and computation in an open framework and at a very large scale. One area of particular interest to the science of hydrology is the capture, representation, inference and presentation of provenance information: information that helps to explain how data were computed and how they should be interpreted. This paper is among the ﬁ rst to bring recent developments in the management of provenance developed for e-science and the Semantic Web to the problems of hydrology. Our main result is a formal ontological model for the representation of provenance information driven by a hydrologic case study. Along the way, we support usability, extensibility and reusability for provenance representation, relying on the concept of modelling both domain-independent and domain-speci ﬁ c aspects of provenance. We evaluate our model with respect to its ability to satisfy identi ﬁ ed requirements arising from the case study on stream ﬂ ow forecasting for the South Esk River catchment in Tasmania, Australia.


INTRODUCTION
Hydrology is the study of the occurrence, distribution and movement of water on, in and above the Earth (see http:// www.economicexpert.com/a/Hydrology.htm).Simulating a hydrologic phenomenon can be complex.In addition to the challenges of representing physical dynamics, it may involve coupling multiple models and accessing multiple data sources.For example, water quality management routinely requires the coupling of multiple models to reflect the structure of the water flow through upper catchments, freshwater streams and tidal river estuaries (Taylor et al. ).In a recent major exercise to quantify water availability of the Murray Darling Basin in Australia, a large variety of models were used: climate models, catchment water yield models, operational river system models, groundwater models and water accounting models (CSIRO ).
It is increasingly important to capture the provenance of simulation results developed this way.It is necessary for the purpose of the interpretation of results, especially as quantifying uncertainty in results in such a setting is very difficult.The authority and method by which a result was computed is a proxy for formal quality evaluation and can engender the appropriate level of trust in data.In some cases in Australia, results such as these are used for major, controversial, economic and environmental policy decisions which must be supported, and be seen to be supported, by the best science available.In addition, provenance is important for the application of the basic principles of scientific transparency and scientific knowledge evolution: enabling the capture, reproduction and improvement of best practices.
A recent incubator group of the World Wide Web Consortium (W3C, see http://www.w3.org/2005/Incubator/ prov/) defines provenance as follows: 'Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource.Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility.Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance.'For hydrology and its related disciplines, provenance, as a kind of metadata, can describe the original sources of data, data manipulations such as filtering and interpolation, the sources of models, the flow of data between models, the intermediate data products, the calibration of model parameters, and the purpose, destination, authority and quality estimates for any final data products.
One fundamental issue for provenance is its representation.A representation needs to be rich enough to support both domain-independent and domain-specific retrieval of the captured provenance knowledge.For example, a domain-independent question might ask for all the steps taken in a workflow that produced a named data file.A domain-specific question might ask for all the values of calibration parameters that have been used by any rainfall-runoff model applied over the upper sub-catchments of the Molongolo River during the summer of 2001.Domain-independent questions correspond to a low-level view of provenance tasks that users have at hand; answering such questions requires causal relationships between data products to be captured as provenance.Domain-specific questions, on the other hand, represent a high-level view of provenance tasks; answering such questions requires provenance to be enriched with domain semantics.
In this paper, we contribute to the design of a representation aimed at answering both types of provenance questions.We develop our representation in the context of three guiding principles which are essential to any exercise in provenance capture and representation.These principles are as follows: • A representation should be use case driven • A representation should be usable.One primary goal of a representation is to facilitate the use of provenance.This in turn requires the representation to be able to support querying and, we argue, support reasoning over provenance.The usability of a representation is also reflected in its interoperability with other provenance representations.
• A representation should be extensible.Use cases can never be exhaustive: there are always cases not examined previously.The important thing is to be able to discover generic provenance requirements from the use cases at hand, to meet these requirements, and to make a representation reusable for other possible use cases.A good representation will support extensibility to expand the scope of the domain and artifacts being represented, and also to expand the detail and level of granularity being represented, without forcing loss of access to prior provenance data.Having determined what to represent, we next decide how to represent it.We address this from the following aspects.First, we employ a modular approach to provenance modelling, which decouples domain-independent provenance from domain-specific provenance, and applicationgeneral provenance from use-case-specific provenance.As such, we support extensibility and reusability for provenance representation.Second, we model provenance by extending the widely used Open Provenance Model (OPM) (Moreau et al. ), which promotes interoperability with other provenance representations.Third, we encode provenance in the formal logic-based Web Ontology Language (OWL, http://www.w3.org/TR/owl-features/), which not only enables expressive provenance representation, but also facilitates querying and reasoning over provenance.
Finally we evaluate our provenance representation with respect to the requirements established by the use case.
In summary, the contributions of this paper are as follows: 1.An analysis of provenance requirements for streamflow forecasting.

A representation of provenance information in stream-
flow forecasting with support for usability, extensibility and reusability principles.This is the first time these principles have been comprehensively applied and tested in the context of hydrologic science.
3. An evaluation of the representation with respect to its ability to meet the requirements identified from the use case.
The remainder of this paper is organised as follows.The next section gives a review of related work.The third section introduces the use case.The fourth section discusses provenance requirements for streamflow forecasting.Then we present the provenance model, followed by an evaluation in the sixth section.Finally, we end the paper with our conclusions.

RELATED WORK
Provenance has been studied in a number of domains, e.g.In hydrologic science, the only provenance work we are aware of is by Dozier & Frew (), where a snow mapping example is given.In the example, scientists first compute fractional snow cover maps from daily satellite observations and then filter, smooth and interpolate the maps to provide the best estimate of the daily snow cover.To capture and manage provenance in the mapping process, a software environment, the Earth System Science Server (ES 3 ) (Frew et al. ), is used, where provenance is modelled as a direct graph of processes and their input and output files.

Our work complements Dozier & Frew's work in that we
model not only domain-independent aspects of provenance but also domain-specific aspects, which allows us to support a wider range of provenance inference tasks; also, by building our work on OPM, we facilitate our representation's interoperability with other provenance models.

CASE STUDY: STREAMFLOW FORECASTING
The South Esk River catchment (Figure 1  Figure 2 shows the forecasting process for the South Esk River catchment, which involves the following major steps: • Temporal normalisation: aggregation or extrapolation of data at a specific temporal scale.
• Spatial normalisation: interpolation of data at a specific spatial scale.
• Model calibration: calibration of model parameters using the shuffled complex evolution optimisation method (SCE-UA) (Duan et al. ).
• Model simulation: simulation of streamflow by first run- ning the calibrated model for a certain period (i.e.warmup period), and then using the model states (e.g.soil moisture, groundwater and channel storages) at the end of the warm-up period as the model's initial condition with rainfall forecasts to simulate streamflow.

PROVENANCE REQUIREMENTS
Given a case such as the above, and a streamflow forecast- There is no 'one size fits all' set of quality dimensions.nonuniqueness or nonidentifiability of parameters in the feasible parameter space; and data uncertainty is due to measurement errors (including both systematic and random errors), limited spatial and temporal sampling, or errors introduced by data processing (e.g.spatial interpolation).
To facilitate accuracy assessment, information on these uncertainty sources needs to be provided.With such information, users can then determine, based on their knowledge, which uncertainties should be accounted for, and which can be neglected without affecting forecast accuracy.In general, the following information is of interest: • The hydrologic model used.This includes its version, processes, inputs, outputs, states, (free) parameters, spatial treatment of inputs and parameters (i.e.lumped, distributed or semi-distributed) and routing schemes.• The steps involved, including the methods and con- figurations used, and the agents who performed the steps.Hydrological modelling and forecasting can be considered to comprise four high-level steps: a preprocessing step to prepare data before use in the model, The granularity of information to be provided, in particular the granularity of process and data information, varies from use case to use case.In the case of South Esk streamflow forecasting, information on each individual step is needed.This includes information on both temporal and spatial normalisation steps.Although these two steps could be considered at a coarse level as a single data pre-processing step, information of the method used in each step is important for the assessment of the quality of the data (to be used as model input).Besides the methods, the inputs and outputs of each step need to be considered as well, which can be as simple as a single value, e.g. the temporal scale used by temporal normalisation, or as complex as a large set of values in the form of files, e.g.rainfall data.For the latter case, we treat the dataset as a whole (instead of individual data values) and focus more on common features of data which are typically looked at, e.g. the time period and timestep of a time series, or the location of a data file (this also avoids representing provenance of individual data values, which possibly requires huge provenance storage).
The requirements for the information to be provided are also reflected in the provenance questions that can be asked.
There are two types of provenance question: domainspecific and domain-independent, and the difference between them is whether or not domain semantics are needed to answer questions.A domain-specific question could be: 'Find all data preprocessing steps involved that contribute to the computation of a streamflow forecasting result' and its domain-independent version may be: 'Find all steps involved that contribute to the computation of a result.'Provenance information enriched with domain semantics can be used to answer both types of question.
For the South Esk use case, example provenance questions can be, given a forecasting result: • Q1: what's the lead time of the result and at what tem- poral resolution?
• Q2: which hydrologic model was used?• Q3: who calibrated the model and which calibration method was used?
• Q4: what data were used as model input in the simulation?
• Q5: which preprocessing steps and methods were per- formed for a certain model input?
• Q6: for a gauge involved, when was it last calibrated?

THE PROVENANCE MODEL
From the requirements, we derive a set of key concepts that should be covered by a provenance model.We construct the model with a modular approach by decoupling domainindependent provenance from domain-specific provenance, and application-general provenance from use-case-specific provenance.Such an approach enables part of the model to be able to be reused.Three modules are generated: a basic module for describing the concepts independent of any particular domain, an application module for the concepts common to streamflow forecasting applications and a use case module for the concepts specific to a forecasting case (e.g. the South Esk case), among which the application and use case modules together describe domain-specific provenance.
We represent the model using the Web Ontology Language (OWL).OWL is expressive enough to provide precise description of the provenance information that needs to be represented.Also, it supports querying and reasoning over provenance.The reasoning enables a relatively compact representation (because we can rely on inference to infer data that are not represented), and is also critical for managing the relationships between domainspecific and domain-independent parts of our representation.

Representing domain-independent provenance
Regardless of domain, some concepts are fundamental, underlying provenance requirements of any application.
For example, those describing: • the steps involved and associated methods; • the artifacts used or generated by a step; • the agents which interact with a step or an artifact; • relationships between steps, artifacts and agents, e.g. an artifact was generated by a step.
To represent these concepts, we leverage existing work on provenance modelling.In this paper, we use the Open Provenance Model (OPM) (Moreau et al. ).
Throughout this section, we use the terms in italic type to denote the concepts defined in OPM and the terms in teletype to denote OWL classes (with the first letter in uppercase) or properties (with the first letter in lowercase).
OPM is an abstract model which provides a specification to express provenance information.It defines provenance as a directed graph, whose nodes are: • artifact: immutable piece of state, which may have a phys- ical embodiment in a physical object, or a digital representation in a computer system; • process: action or series of actions performed on or caused by artifacts, and resulting in new artifacts; • agent: contextual entity as a catalyst of a process, enabling, facilitating, controlling or affecting its execution; and whose edges are: used (from a process to an artifact): a causal relationship intended to indicate that the process required the availability of the artifact to be able to complete its execution; wasGeneratedBy (from an artifact to a process): a causal relationship intended to mean that the process was required to initiate its execution for the artifact to have been generated; wasTriggeredBy (from process P 2 to process P 1 ): a causal dependence that indicates that the start of P 1 was required for P 2 to be able to complete; wasDerivedFrom (from artifact A 2 to artifact A 1 ): a causal relationship that indicates that A 1 needs to have been generated for A 2 to be generated; used o wasDerivedFromStar ⊑ usedStar We further extend OPMO to cover the following generic and domain-independent concepts and properties (the resulting ontology is OPMO þ , shown in Figure 3): • Method and useMethod: a method describes how a process was performed, as defined by Process ⊑ ¼ 1 useMethod.Method.
• partOf: an artifact (resp.a process or an agent) can be part of another artifact (resp.process or agent).We define partOf as transitive and specify both its domain and range to be Artifact, or Process, or Agent.
• providedBy: an artifact may be provided by an agent, defined by Artifact ⊑ ∀ providedBy.Agent • Source and hasSource: an artifact may come with source information (e.g.sensor), defined by Artifact ⊑ ∀ hasSource.Source.
These extensions make it possible to represent such information as the method used in a process, the source of an artifact, whether an artifact is part of another artifact,

REQUIREMENTS REVISITED
With the provenance model described above, we satisfy the requirements (in the fourth section) by representing generic provenance concepts and then enhancing them with domain-specific semantics.We now illustrate how the model can be used to address the requirements as exemplified by Q1-Q6 .
The model is instantiated using the data from the South Esk use case.(f) the temporal normalisation step which generated the temporally normalised data, temp_norm_1; (g) the rainfall data provided by BoM and used by the temporal normalisation step, rainfall_original_1; (h) the sensor from which the rainfall data were observed, sensor_1.
Based on the instances serialised as RDF triples (http:// www.w3.org/TR/rdf-primer/), we then use SPARQL (an RDF query language (http://www.w3.org/TR/rdf-sparqlquery/). Queries in SPARQL are expressed in an SQL-like syntax, and answered via triple pattern matching) to query provenance.SPARQL is not aware of the OWL semantics (e.g.
subclass relationships) that are using in our provenance ontology.To handle this, we can either pre-compute inference results with the help of an OWL reasoner (Ma et These three principles serve as our guidelines for deciding what to represent and how to represent it.In following these principles, we start from a use case study.We investigate provenance requirements for streamflow forecasting, including what kind of provenance information to be provided, and at what level of granularity, in order to help users assess the quality of a streamflow forecasting result. physics (Foster et al. ), earth sciences (Frew & Bose ), bioinformatics (Greenwood et al. ) and computer science (Davidson et al. ; Tan ).A comprehensive survey of provenance for scientific data computing is given by Bose & Frew (), which covers lineage-related standards, lineage research and prototypes.Simmhan et al. () describe a taxonomy to categorise provenance systems along provenance usage, subject, representation, storage and dissemination dimensions.The requirements of recording, querying and using provenance in e-science experiments is defined by Miles et al. (), based on an analysis of a range of use cases from several domains.A key component of a provenance system is provenance representation.There are two major representation approaches (Simmhan et al. ): inversion and annotation.The inversion approach relies on inversion functions to find the derivation history of a data product (Woodruff & Stonebraker ; Cui & Widom ).The annotation approach, on the other hand, treats provenance as metadata and pre-computes it.Our work follows the annotation approach.Several provenance annotation models have been proposed in the literature.The Proof Markup language (PML) (da Silva et al. ) focuses on modelling provenance in reasoning systems and covers the concepts for describing conclusions and justifications.Provenir (http:// wiki.knoesis.org/index.php/Provenir_Ontology) is built based on the OBO Relation Ontology (RO) (Smith et al. ) and has been extended for modelling provenance in oceanography (Sahoo et al. ) and biology experiments (Sahoo et al. ; Missier et al. ).OPM, which our work is based on, is currently the most widely used.It results from a community effort to achieve interoperability of workflow systems, and its recent applications include reproducing scientific results (Moreau ), representing scientists' intent (i.e.experimental constraints and goals) (Pignotti et al. ), tracking provenance in distributed systems (Groth & Moreau ) and modelling provenance on the web (Freitas et al. ).Common to PML, Provenir, OPM and some other models is the representation of process and data dependences.The W3C Provenance Working Group (http://www.w3.org/2011/prov/), which involves various communities with interests in the provenance space, is currently defining a language for exchanging provenance information among applications.The importance of semantic provenance for e-science is explicitly pointed out by Sahoo et al. (), who define semantic provenance as 'information created with reference to a formal knowledge model or an ontology that imposes a domain-specific provenance view on scientific data'.Along this line, Zhao et al. () further classify provenance information into three types: simple provenance traces with no domain-specific semantics, semantic provenance and provenance traces that comply with the Linked Data standard (see http://www.w3.org/standards/semanticweb/data).
) (DIPIW ) is located in the northeast and midlands of Tasmania, Australia, and extends over an area of approximately 3,350 km 2 .The catchment rises in the Fingal Tier in the east and is bounded by the Ben Lomond Range and Mt Saddleback to the north.Its major tributaries are the Nile, St Pauls and Break O'Day rivers.Downstream of Longford, the South Esk River receives inflow from the Macquarie and Meander rivers and flows into the Tamar Estuary.The river system (above its confluence with the Macquarie River) is largely unregulated, and has the key characteristics of a natural flow regime, including seasonal distribution and variability in flows, and natural rates of rise and fall in river height.The primary land uses in the catchment are agriculture and forestry.The catchment is covered by 19 rain gauges, 11 streamflow gauges and 10 automatic weather stations (AWS) to collect observations of rainfall, streamflow (or stage) and climate data such as air temperature and wind speed.The gauges and stations are operated by several organisations, including the Bureau of Meteorology (BoM), Hydro Tasmania, Forestry Tasmania, CSIRO and the Department of Primary Industries, Parks, Water and Environment (DPIPWE).To provide near-real-time sensor observations, we have developed a hydrologic sensor web application (http://www.csiro.au/sensorweb/ au.csiro.OgcThinClient/OgcThinClient.
ing result, we are interested to know: what kind of information, if provided, can help users assess the quality of the result?To answer this question, we require a clear understanding of what quality is.There are a number of definitions of quality, and the most frequently adopted one is 'fitness for use' (Juran et al. ).Based on this definition, quality is usually described by a set of quality dimensions which represent desirable characteristics for an information resource.For example, Wang & Strong () describe quality along 15 dimensions including accuracy, interpretability and reputation.
Figure 2 | Streamflow forecasting for the South Esk River catchment.

•
The hydrologic data used and generated.Examples of data are forcing data (e.g.precipitationgenerally regarded as a significant source of uncertainty in hydrologic models (Milly et al. ), potential evaporation), catchment physical characteristics (e.g.area, elevation and channel lengths, slope), observations of model states or fluxes, and model output.For easy interpretation of data, contextual information of data, e.g.forecast leadtime and temporal resolution, may be provided as well.• The sources and providers of hydrologic data.Examples of data sources are rain gauges, weather stations, satellites and NWP models.The quality of data is greatly influenced by their origin.For example, errors in rainfall observations are always associated with gauge type, accuracy and calibration.Data may be quality-checked by providers.Most quality-checked datasets include flags to indicate the accuracy of a particular observation.Flags are used to indicate missing values, automated filtering errors, uncommon situations like ice or hail, and whether data are observed, interpolated or derived using a rating table.

a
model calibration step to estimate model parameter values, a model simulation step to run the model and generate forecasts, and a post-processing step to process forecasts for end use (in this paper, we focus on batch model calibration, i.e. using batch of data for calibration (Moradkhani & Sorooshian )).Depending on use case, each of these steps may consist of a set of substeps.For example, a pre-processing step may have substeps such as bias correction, temporal aggregation and spatial interpolation.A step may use a different method, have a different configuration or be performed by a different agent.For example, the method used for model calibration can be manual or automatic; the calibration period can range from a few years to more than ten years; and the calibration can be performed by people with low or high levels of expertise.
wasControlledBy (from a process to an agent): a causal dependence that indicates that the start and end of the process was controlled by the agent.Besides nodes and edges, there are some other concepts defined in OPM, such as roles and accounts.Roles are used to 'designate an artifact's or agent's function in a process', and accounts to 'represent a description at some level of detail as provided by one or more observers'(Moreau   et al. ).Nodes and edges can belong to accounts; together they represent, from an observer's point of view, 'how 'things', whether digital data, physical objects or immaterial entities, came to be in a given state, with a given set of characteristics, at a given moment'(Moreau et al. ).Suppose a workflow consists of two steps P1 and P2; an execution of the workflow by A transformed data a1 into a2.Then, an account of the execution can include: artifacts a1 and a2, processes P1 and P2 (controlled by agent A), P1 used a1, a2 wasGeneratedBy P2, P2 wasTriggeredBy P1 and a2 wasDerivedFrom a1.OPM also defines a set of one-step (or completion) and multi-step inference rules that can be applied to a provenance graph.An example of one-step inferences is that a wasTriggeredBy relationship can be inferred from the existence of used and wasGeneratedBy relationships.Multi-step inferences are associated with multi-step versions of existing relationships, i.e. used*, wasGeneratedBy*, wasTriggeredBy* and wasDerivedFrom*.They are used to find the causes of an artifact or a process which possibly involve multiple transitions.For example, process P used* artifact a if P used an artifact that was a or was derived from a possibly using multiple steps.OPMO (http://openprovenance.org/model/opmo) is an OWL-based encoding of the latest specification of OPM (i.e.v1.1).It maps OPM nodes and edges to OWL classes.The mapping of edges to classes allows additional edge properties to be expressed, such as time and role information.For example, used relationships are represented in OPMO by class Used, whose instances have and only have Processes as effect and Artifacts as cause, and have at least one Role.OPM inference rules are partly expressed in OPMO: wasDerivedFromStar (corresponding to was-DerivedFrom* in OPM) is defined as a transitive property in OWL, with wasDerivedFrom as its subproperty (note that OPMO defines both WasDerived-From (WDF) and wasDerivedFrom, with the former as an OWL class and the latter as an OWL property); other multi-step relationships are defined based on wasDerivedFrom*, and can be inferred by OWL by means of property chains (as such, we can choose not to instantiate these relationships).For example, usedStar can be inferred from used and was-DerivedFromStar, expressed in Description Logics (DL) (Baader et al. ) as follows (Table 1 shows the DL notations used in ths paper.Please refer to Baader et al. ()for their formal semantic interpretations): figure a step, e.g. the calibration period used by model calibration; they can also be auxiliary output of a step, e.g.skill score reports generated by model simulation.Besides the steps, inputs and outputs, we also model the individuals and organisations involved in streamflow forecasting.We create two classes, Person and
Figure 6 shows part of provenance instance data in N3 format (http://www.w3.org/DesignIssues/Notation3):(a) a forecasting result, streamflow_forecasts_1; (b) the simulation step which generated the forecasting result, simulation_1 (time_period_1 and time_period_2 represent the warm-up period and the simulation period, respectively); (c) the gridded rainfall data used by the simulation step, rainfall_gridded_1; (d) the spatial normalisation step which generated the gridded rainfall data, spatial_norm_1; (e) the temporally normalised rainfall data used by the spatial normalisation step, rainfall_tn_1;

?
Provenance has been studied in a number of domains, such as earth sciences and bioinformatics.One fundamental issue for provenance is its representation.This paper presents a provenance model for representation of provenance information in streamflow forecasting.Driven by a case study, the model has been designed to support usability, extensibility and reusability, by extending the widely used Open Provenance Model (OPM), using the formal logic-based Web Ontology Language (OWL) for encoding, and decoupling domain-independent provenance from domainspecific provenance, and application-general provenance from use-case-specific provenance.Further, the model has been evaluated with respect to its ability to satisfy the requirements as exemplified by a set of provenance questions.Being metadata describing environmental data, the model bears some similarities to existing standards such as OGC Observations and Measurements (O&M) (Cox a, b), Ecological Metadata Language (EML) (EML Project Members ) and Water Markup Language (WaterML) (Zaslavsky et al. ).However, they are designed for different purposes, thus having different scopes and foci.While the model presented is used to represent the derivation history of a forecasting result, including the sources, intermediate data products and the process that led to the result, O&M and similar standards are used for exchanging information describing the collection, analysis and reporting of environmental observations.They may contain similar concepts; however, these concepts typically have different intensions or meanings.For example, the Process concept of the model (as inherited from OPMO) denotes 'action or series of actions performed on or caused by artifacts, and resulting in new artifacts' (Moreau et al. ), while in O&M, the concept denotes the procedure to generate an observation result, which can be a sensor, a human observer or an algorithm applied (Cox a).Their meanings overlap only partially (when the O&M process refers to an action, e.g. an algorithm applied).The model may change over time, due to changes to OPM, or changes to the conceptualisation of provenance requirements in streamflow forecasting (e.g. a better understanding of the requirements).In such a case, we need to manage multiple versions of the model and ensure that provenance instance data that conform to the older versions can still be interpreted correctly.There has been some research work on ontology versioning and evolution (e.g.Noy & Klein ; Noy & Musen ).For our work, we need to find out what are possible changes to the model and their effects on instance data.We leave this to future work.

Table 1
Organisation, as subclasses of opmo:Agent for representing the person or organisation, for example, providing TemporalScale which specifies the timestep for the output time series.We define TemporalScale as a subclass of AuxiliaryData.The same applies for Spa-tialScale and BoundedArea used by a SpatialNorm step, and TimePeriod by Calibration and Simulation.Method can be specified.For example, we can specify the method used by model calibration as follows: For a gauge involved, when was it last calibrated?To answer this query, we need to find all the time series that have GaugeStation as Source.We use wasDeri-vedFromStar to achieve this.