<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Nan, hope you are doing well.<div class=""><br class=""></div><div class="">This problem is hard for all sorts of artifacts, and the answers I've seen in community projects have all required implementing some kind of provenance chain for all the data. As your problem statement illustrates, the problem often extends beyond pure duplication, to all kinds of derived, partial, and versioned instances of the original data.</div><div class=""><br class=""></div><div class="">So when there is a pipeline generating the results, the solution has to include that the pipeline self-documents the provenance of the new data set–the processes that produce it. I know MBARI's Shore Side Data System did (likely still does) that, and the original OOI CI system was designed to do that. Within the last decade, the existince of ontologies like PROV and PAV, and of more advanced metadata standards, allow for declaring the exact relationship of a derivative artifact to its parent artifacts. (The relationship definitions can be seen in the ontologies, and can be augmented if needed to reflect a particular relationship that you need.) I am pretty sure the ISO standards (19115 in particular) do have the ability to specify provenance relations to the input artifacts. With any of these systems, you also have to have an unambiguous way to identify every existing data set in the system, which I expect OceanSITES does.</div><div class=""><br class=""></div><div class="">Of course, while it is relatively straightforward to modify one workflow or system to start adding the appropriate provenance metadata to each data set, OceanSITES is dealing with an entire data ecosystem. I can't recall what existing data and metadata standards you are already using—hopefully they are extensible to add these new relations, if they don't have them already—but there is the social and UI work to get everyone submitting data to document its relation properly, and then any software using the system has to be "smart enough" to understand the relations in the metadata, and not display for user or use in computations 2 data points from the same data collection.</div><div class=""><br class=""></div><div class="">It would be an advancement if there were a universal standard for incorporating provenance relation declarations within netCDF, for example, but I'm pretty sure there are a few communities already doing that, I just don't know for sure who's still doing it. Sorry I can't be more helpful.</div><div class=""><br class=""></div><div class="">John</div><div class=""><br class=""></div><div class="">(shameless promotion: If you need to model or prototype your metadata structure for provenance metadata, and/or create a UI for users to enter descriptive metadata into a computable text file (JSON-LD or RDF) that follows a well-defined specification, CEDAR at <a href="http://metadatacenter.org" class="">metadatacenter.org</a> may be worth a look. There's already one example of a <a href="https://openview.metadatacenter.org/templates/https://repo.metadatacenter.org/templates/dd6231ef-5890-48cb-9621-04c5b5577c1e" class="">Generic Dataset Metadata Template</a> that I helped create, we were a bit agnostic about choosing a particular provenance approach though, and it's still in progress. Details on request.)</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 21, 2021, at 6:27 AM, Nan Galbraith via Esip-documentation <<a href="mailto:esip-documentation@lists.esipfed.org" class="">esip-documentation@lists.esipfed.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""> Hi all - <br class=""><br class="">The OceanSITES data management team is hoping to solve a problem <br class="">with identifying duplicate or secondary instances of data sets on our <br class="">servers. We work with in situ observational data sets, which are often <br class="">used by modelers and remote sensing systems. If these users unknowingly <br class="">access duplicate copies of data, it may skew their results by inaccurately<br class="">weighting these data points.<br class=""><br class="">We originally tried to ensure that we had only one copy of any given <br class="">data point on our server, but that hasn't proved to be practical. Certain <br class="">kinds of computed data sets, like PCO2 and surface fluxes, are more <br class="">useful to end users if the files contain copies of the component observed<br class="">data variables used in their calculations. These copies may start out at a<br class="">different rate from the originals, being gridded or averaged to match the<br class="">time base of the related data, or, over time, the original data may change <br class="">slightly, as calibrations, algorithms, or clock adjustments are updated.<br class=""><br class="">My question to the documentation cluster is whether you know of<br class="">any community standards that identify a given data variable as the<br class="">authoritative or 'original' copy. I haven't encountered any kind of<br class="">standard for this, but I may not be looking in the right places. I feel<br class="">that there may be a solution related to DOIs, but ... it wouldn't be<br class="">meaningful unless our data users knew about it, and were prepared<br class="">to use it, and if we acquired a DOI for each observed variable in a<br class="">data set.<br class=""><br class="">Any ideas on this would be very welcomed; we try, whenever possible, to <br class="">adopt existing standards instead of inventing our own one-off solutions.<br class=""><br class="">Thanks in advance - <br class="">Nan Galbraith<br class=""><br class=""><br class="">-- <br class="">*******************************************************<br class="">* Nan Galbraith Information Systems Specialist *<br class="">* Upper Ocean Processes Group Mail Stop 29 *<br class="">* Woods Hole Oceanographic Institution *<br class="">* Woods Hole, MA 02543 (508) 289-2444 *<br class="">*******************************************************<br class="">_______________________________________________<br class="">Esip-documentation mailing list<br class=""><a href="mailto:Esip-documentation@lists.esipfed.org" class="">Esip-documentation@lists.esipfed.org</a><br class="">https://lists.esipfed.org/mailman/listinfo/esip-documentation<br class=""><br class=""></div></div></blockquote></div><br class=""><div class="">
<div>----------------------</div><div>John Graybeal</div><div>Administrator—ESIP Community Ontology Repository</div><div><a href="mailto:jbgraybeal@sonic.net" class="">jbgraybeal@sonic.net</a></div><div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>