Re: DWBP SDWBP alignment notes

By far the greatest proportion of CRS's are projected. Some of these pertain to a locale, such as US State Plane but the larger number are regional with varying faithfulness to the geoid away from their medians, such as UTM. This peculiarly a geospatial issue, as are cumulative projection errors, so there is a data quality aspect, but I'm not sure that either locale or data quality covers the issue completely.

Josh

Joshua Lieberman, Ph.D.
Principal, Tumbling Walls Consultancy
Tel/Direct: +1 617-431-6431
jlieberman@tumblingwalls.com

> On Jul 22, 2016, at 06:18, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
> 
> Hi all. Looks like we have consensus emerging :-) ... I'm happy to see CRS as locale info given what you've said. Jeremy
>> On Fri, 22 Jul 2016 at 11:09, Andrea Perego <andrea.perego@jrc.ec.europa.eu> wrote:
>> On 22/07/2016 11:45, Linda van den Brink wrote:
>> > Responding to the comments on SDWBP 8…
>> >
>> >> SDWBP 8 is about when to use a specific CRS rather than rely on the ubiquitous EPSG 3857 / WGS 84; which is a data quality issue. I don't see > how this is a locale issue?
>> >
>> > Intuitively, and probably this is because I don’t have a spatial
>> > background originally, I do see it as a locale issue. These specific CRS
>> > exist to provide a coordinate system for a specific region of the world
>> > (often a specific country). Someone from France is never going to use
>> > the Dutch coordinate system and vice versa. It’s region-specific, like a
>> > language, thus I’m thinking ‘locale’.
>> 
>> I think the notion of 'locale' is a good approximation, and it is
>> domain-independent enough to make non-geo experts have a (partial)
>> understanding of what a CRS is.
>> 
>> > And yes, you could see it as a data quality thing as well, because these
>> > specific CRS exist for high accuracy spatial data, but that is something
>> > only spatial people know.
>> 
>> +1. This can be seen as conformance of data with a "standard" - in this
>> case, a (spatial or temporal) reference system. This is how you can
>> model it with DQV. And this is how it is modelled in GeoDCAT-AP.
>> 
>> Andrea
>> 
>> 
>> > *Van:*Byron Cochrane [mailto:bcochrane@linz.govt.nz]
>> > *Verzonden:* woensdag 20 juli 2016 13:53
>> > *Aan:* 'Jeremy Tandy'; 'Little, Chris'; 'public-sdw-wg@w3.org'
>> > *Onderwerp:* RE: DWBP SDWBP alignment notes
>> >
>> >
>> >
>> > …and reply to 30
>> >
>> >
>> >
>> > *From:*Jeremy Tandy [mailto:jeremy.tandy@gmail.com]
>> > *Sent:* Wednesday, 20 July 2016 1:51 a.m.
>> > *To:* Little, Chris; Byron Cochrane; public-sdw-wg@w3.org
>> > <mailto:public-sdw-wg@w3.org>
>> > *Subject:* Re: DWBP SDWBP alignment notes
>> >
>> >
>> >
>> > I forgot SDWBP 29 and 30 ...
>> >
>> >
>> >
>> > SDWBP 29. Agreed.
>> >
>> >
>> >
>> > SDWBP 30. I recall Bill Roberts saying that being able to use the API to
>> > search was important. I think that DWBP 23 covers the broad issue of
>> > APIs, but we should (at least) use a search API as an example?
>> >
>> > So a spatial specific search API to cite for within a dataset would be
>> > useful.  At the dataset level we have some spatial search api tools
>> > (GeoSPARQL, CSW).  Not so sure about a bp to cite for inside a spatial
>> > api.  Good idea, though
>> >
>> >
>> >
>> > OK, That's me done for now.
>> >
>> >
>> >
>> > On Tue, 19 Jul 2016 at 14:45 Jeremy Tandy <jeremy.tandy@gmail.com
>> > <mailto:jeremy.tandy@gmail.com>> wrote:
>> >
>> >     Responding now to Byron.
>> >
>> >
>> >
>> >     Thanks for the assessment. Comments below...
>> >
>> >
>> >
>> >     SDWBP 3 is about converting dataset-scoped identifiers to URLs. I
>> >     don't see how this relates to vocabularies (topic of DWBP 15).
>> >     Please can you elaborate?
>> >
>> >
>> >
>> >     SDWBP 8 is about when to use a specific CRS rather than rely on the
>> >     ubiquitous EPSG 3857 / WGS 84; which is a data quality issue. I
>> >     don't see how this is a locale issue?
>> >
>> >
>> >
>> >     SDWBP 9. Agreed. Are you aware of any 'vocabularies' that can be
>> >     used to describe relative positions? (other than GML)
>> >
>> >
>> >
>> >     ... same question applies to SDWBP 10; what are the vocabularies for
>> >     representing positional inaccuracy?
>> >
>> >
>> >
>> >     SDWBP 13 is trying to say "if you know about a [spatial]
>> >     relationship with another resource (and you care enough to write it
>> >     down) then write it down; don't rely on spatial correlation" ...
>> >     which is why I aligned it with SDWBP 23. The discussion on which
>> >     spatial vocabulary to use to express those relationships was SDWBP
>> >     12 'use spatial semantics for spatial things'.
>> >
>> >
>> >
>> >     SDWBP 14-18. Agree; we need to make sure that folks interested in
>> >     environmental data (observations) are adequately covered. My hope
>> >     was that the SSN work would provide sufficient examples. Also, it's
>> >     difficult for us to define "best practice" for these cases that will
>> >     refer to the _brand new_ SSN redux (!). Our BPs need to be based on
>> >     evidence of real world application.
>> >
>> >
>> >
>> >     SDWBP 19-22. I like your idea of giving a primacy to "linking data"
>> >     ... BP: "do linked data" (!)
>> >
>> >
>> >
>> >     SDWBP 24-25 ... I can see your point about overlap with DWBP 1-7.
>> >     When writing SDWBP 24 I was trying to emphasise that the Links (that
>> >     we'd earlier recommended creating) can be used to find / discover
>> >     data; so more about maximising value of Linked Data than talking
>> >     about particular types of metadata. SDWBP 25 is about allowing
>> >     search engines to see inside the dataset. I'd taken DWBP 1-7 as
>> >     focusing on the dataset-level metadata rather than the individual
>> >     entities described by the dataset. Looking again at DWBP 1, I see
>> >     that that is not necessarily the case. Given that, it would make
>> >     sense to extend DWBP 1; e.g. using schema.org <http://schema.org>
>> >     and hypercat as examples?
>> >
>> >
>> >
>> >     SDWBP 26; agree that this is coverage in DWBP 2
>> >
>> >
>> >
>> >     SDWBP 27. This is similar to providing subsets; but the emphasis was
>> >     to get get data owners to publish their data how ever they could. If
>> >     they could only afford to do bulk publication, then that's good. If
>> >     they can provide a rich API, even better. Either way, I think we
>> >     cover the nuances of this elsewhere.
>> >
>> >
>> >
>> >     SDWBP 28. Agree that this isn't spatial specific. I think the DWBP
>> >     folks did a great job of covering the bases with DWBP 23 'make data
>> >     available through an API' that I thought we might have to. Likewise,
>> >     SDWBP 29 aligns well with DWBP 25 'Provide complete documentation
>> >     for your API'.
>> >
>> >
>> >
>> >     On Tue, 19 Jul 2016 at 13:52 Jeremy Tandy <jeremy.tandy@gmail.com
>> >     <mailto:jeremy.tandy@gmail.com>> wrote:
>> >
>> >         Hi Chris.
>> >
>> >
>> >
>> >         Thanks for taking the time to look at this.
>> >
>> >
>> >
>> >         Responding to (some of) your points about
>> >         "expansion/restriction/explanation/examples/prescription of DWBP
>> >         best practices probably needed"...
>> >
>> >
>> >
>> >         DWBP 1 and DWBP 2. I think that generally, when we think about
>> >         dataset metadata (e.g. for discovery) as defined by, say, DCAT
>> >         or ISO 19115 I think that this fits in DWBP 2 "Provide
>> >         descriptive metadata". Looking at ISO 19115-1, this does include
>> >         CRS (as 'referenceSystemInfo';  type 'MD_ReferenceSystem').
>> >         Don't know if this is in GeoDCAT-AP. That said, we also need to
>> >         cover use of CRS / SRS in the data itself. I think that's
>> >         covered in DWBP 15 (reuse vocabularies). We might look at
>> >         including that as part of the 'data quality' information (DWBP
>> >         7) which says "Data quality might seriously affect the
>> >         suitability of data for specific applications" ... which is also
>> >         applicable to CRS.
>> >
>> >
>> >
>> >         DWBP 4. You make a good point; this practice enables someone to
>> >         conveniently query or explore the dataset. Is this inherently
>> >         spatial? As of now, I'm not sure where in our set of examples I
>> >         could add this. Thoughts appreciated.
>> >
>> >
>> >
>> >         DWBP 11. We talk about "use URIs as identifiers within
>> >         datasets"; these are for the things described in datasets (e.g.
>> >         spatial things, geometries etc.) so that they can be referenced
>> >         from _outside_ the dataset. This should resolve your
>> >         intra-dataset concern.
>> >
>> >
>> >
>> >         DWBP 14. providing different resolutions / matrix tile sets
>> >         (etc.) fits better with DWBP 18 'provide subsets of large
>> >         datasets'. I see a reduced resolution dataset as a "subset".
>> >
>> >
>> >
>> >         DWBP 28. I think this is a different use of the word "coverage".
>> >         What this is referring to is trying to make sure that the
>> >         "dataset" includes all the reference material that is required
>> >         to interpret the data when you take it offline for archive. This
>> >         isn't a spatial thing.
>> >
>> >
>> >
>> >         Thanks again for the input.
>> >
>> >
>> >
>> >         Jeremy
>> >
>> >
>> >
>> >         On Thu, 14 Jul 2016 at 10:53 Little, Chris
>> >         <chris.little@metoffice.gov.uk
>> >         <mailto:chris.little@metoffice.gov.uk>> wrote:
>> >
>> >             Jeremy, Linda,
>> >
>> >
>> >
>> >             To add to Byron’s useful comments here is my take on what
>> >             DWBPs can be left untouched/unqualified and which may need
>> >             more prescriptive additions. I have left in the current
>> >             numbering as these are direct links to the current Candidate
>> >             Recommendation document. I have tried to be strict – we
>> >             could easily have meaningful comments on each of the 35 BPs.
>> >
>> >
>> >
>> >             I think that there is a significant amount of work to do
>> >             this properly.
>> >
>> >
>> >
>> >             A.      BPs to leave as is, as just point to BP in DWBP section:
>> >
>> >             Best Practice 3
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#LocaleParametersMetadata>:
>> >             Provide locale parameters metadata
>> >
>> >             Best Practice 5
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DataLicense>:
>> >             Provide data license information
>> >
>> >             Best Practice 6
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DataProvenance>:
>> >             Provide data provenance information
>> >
>> >             Best Practice 8
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#VersioningInfo>:
>> >             Provide a version indicator
>> >
>> >             Best Practice 9
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#VersionHistory>:
>> >             Provide version history
>> >
>> >             Best Practice 10
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#UniqueIdentifiers>:
>> >             Use persistent URIs as identifiers of datasets
>> >
>> >             Best Practice 12
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#VersionIdentifiers>:
>> >             Assign URIs to dataset versions and series
>> >
>> >             Best Practice 16
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ChooseRightFormalizationLevel>:
>> >             Choose the right [vocabulary/semantic] formalization level:
>> >             this already has an example of supplying coordinates of bus
>> >             stops as well as times and route numbers of buses
>> >
>> >             Best Practice 19
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#Conneg>:
>> >             Use content negotiation for serving data available in
>> >             multiple formats
>> >
>> >             Best Practice 20
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#AccessRealTime>:
>> >             Provide real-time access
>> >
>> >             Best Practice 21
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#AccessUptoDate>:
>> >             Provide data up to date
>> >
>> >             Best Practice 22
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DataUnavailabilityReference>:
>> >             Provide an explanation for data that is not available
>> >
>> >             Best Practice 23
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#useanAPI>:
>> >             Make data available through an API: Unless there are some
>> >             specific ones to recommend
>> >
>> >             Best Practice 24
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#APIHttpVerbs>:
>> >             Use Web Standards as the foundation of APIs
>> >
>> >             Best Practice 25
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#documentYourAPI>:
>> >             Provide complete documentation for your API
>> >
>> >             Best Practice 26
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#avoidBreakingChangesAPI>:
>> >             Avoid Breaking Changes to Your API
>> >
>> >             Best Practice 27
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ResourceStatus>:
>> >             Preserve identifiers
>> >
>> >             Best Practice 29
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#GatherFeedback>:
>> >             Gather feedback from data consumers
>> >
>> >             Best Practice 30
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#FeedbackInformation>:
>> >             Make feedback available
>> >
>> >             Best Practice 31
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#EnrichData>:
>> >             Enrich data by generating new data
>> >
>> >             Best Practice 32
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ProvideComplementaryPresentations>:
>> >             Provide Complementary Presentations
>> >
>> >             Best Practice 33
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ProvideFeedbackToPublisher>:
>> >             Provide Feedback to the Original Publisher
>> >
>> >             Best Practice 34
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#FollowLicensingTerms>:
>> >             Follow Licensing Terms
>> >
>> >             Best Practice 35
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#CiteOriginalPublication>:
>> >             Cite the Original Publication
>> >
>> >
>> >
>> >             B.      Additional
>> >             expansion/restriction/explanation/examples/prescription
>> >             probably needed
>> >
>> >             Best Practice 1
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ProvideMetadata>:
>> >             Provide metadata: Some preferences like geo extensions to
>> >             dcterms, or ISO19115
>> >
>> >             Best Practice 2
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DescriptiveMetadata>:
>> >             Provide descriptive metadata:Does this include CRSs?
>> >
>> >             Best Practice 4
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#StructuralMetadata>:
>> >             Provide structural metadata: Does this include map layer
>> >             model? Tiling matrix sets? 3D City geometry?
>> >
>> >             Best Practice 7
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#DataQuality>:
>> >             Provide data quality information:Suggest that this includes
>> >             CRSs and expected accuracy and precision?
>> >
>> >             Best Practice 11
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#identifiersWithinDatasets>:
>> >             Use persistent URIs as identifiers within datasets: Not sure
>> >             about this – many intra-dataset URIs may involve coordinates
>> >             that may need special URI handling?
>> >
>> >             Best Practice 13
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#MachineReadableStandardizedFormat>:
>> >             Use machine-readable standardized data formats: Suggest some?
>> >
>> >             Best Practice 14
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#MultipleFormats>:
>> >             Provide data in multiple formats: Suggest that this might
>> >             cover different resolutions/matrix tile sets?
>> >
>> >             Best Practice 15
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ReuseVocabularies>:
>> >             Reuse vocabularies, preferably standardized ones:Are there
>> >             any to suggest?
>> >
>> >             Best Practice 17
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#BulkAccess>:
>> >             Provide bulk download:Suggest some examples of where this
>> >             could be useful, as opposed to incremental updating
>> >
>> >             Best Practice 18
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#ProvideSubsets>:
>> >             Provide Subsets for Large Datasets: Suggest tiling, both of
>> >             maps and data like 3DCity.
>> >
>> >             Best Practice 28
>> >             <http://w3c.github.io/dwbp/publishing-snapshots/CR-dwbp-20160706/#EvaluateCoverage>:
>> >             Assess dataset coverage:Is this just a bounding box?
>> >             Completeness of tile sets? Certificate of Quality? OWS Context?
>> >
>> >
>> >
>> >             HTH, Chris
>> >
>> >             *From:*Byron Cochrane [mailto:bcochrane@linz.govt.nz
>> >             <mailto:bcochrane@linz.govt.nz>]
>> >             *Sent:* Wednesday, July 13, 2016 11:52 PM
>> >             *To:* 'public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>';
>> >             'Jeremy Tandy'
>> >             *Subject:* DWBP SDWBP allignment notes
>> >
>> >
>> >
>> >             Hi Jeremy,
>> >
>> >
>> >
>> >             Here are the notes I made reviewing the two BP docs as
>> >             promised.  I have not had time time adjust much to the
>> >             feedback last night.  My approach was to review your BP
>> >             Consolidation Proposal notes and add comments.  Mostly, I
>> >             generally agreed with your existing comments so you can
>> >             assume general agreement with those BPs not commented on
>> >             here.  Notes are still very rough and need further thought,
>> >             but provide me a starting point. Not sure all these notes
>> >             agree with each other yet!
>> >
>> >
>> >
>> >             SDWBP 3 - This would more naturally fit in reuse of existing
>> >             vocabularies discussion (DWBP 15?).  Important point is when
>> >             to make spatial relationships explicit or leave implicit
>> >
>> >
>> >
>> >             SDWBP 8 - I am inclined to think DWBP 3 is the correct place
>> >             to talk about this.  Can recommend WGS 84 as default, but
>> >             not convinced that this is just a “data quality” issue
>> >
>> >
>> >
>> >             SDWBP 9 - Same as 3. Belongs in DWBP 15
>> >
>> >
>> >
>> >             SDWBP 13 - Seems very similar to 3 and 9 but not sure 23 is
>> >             the place for this.
>> >
>> >
>> >
>> >             SDWBP 14-18 - All of Sensors and Observations section.  Need
>> >             to think how to handle this.  Do we lose something valuable
>> >             that is not covered by SSN if we take this out?
>> >
>> >
>> >
>> >             SDWBP 19-22 - Isn’t linked data an implicit goal of this and
>> >             a specific need for DWBP? Or if these are needed for
>> >             peculiarities of spatial, should these specifically link to
>> >             related “BP for Publishing Linked Data” topics?
>> >
>> >
>> >
>> >             SDWBP 24-26 - This section should align with DWBP 1-7 - the
>> >             various forms of metadata BC 24 - Do not see how this
>> >             differs from 3,9,13,23 BC 25 - Crawability of data is not a
>> >             specific concern of spatial. Ideally if needed it should be
>> >             in DWBP, but this is not possible.  I have some strong
>> >             disagreements with the perceived value of crawliblity when
>> >             applied to data, but can leave that aside for the time being.
>> >
>> >
>> >
>> >             SDWBP 26 - already covered in DWBP 2 ”spatial coverage”.
>> >             For API guidance look to alignment with DWBP 25
>> >
>> >
>> >
>> >             SDWBP 27 -  Isn’t this the same as providing subsets DWBP
>> >             11? Also, APIs are covered in DWBP 23 -26.  Not sure what is
>> >             that geo specific here
>> >
>> >
>> >
>> >             SDWBP 28 - Most of this section is not Geo specific.  Some
>> >             out of date info here.  WFS section needs a serious update
>> >             to be with the times.  As of OGC Testbed 11, WFS has a
>> >             restful interface and has always been able to carry payloads
>> >             other than GML.  APIs are well covered generally in DWBP
>> >             23-26. Should align geo specific concerns with these
>> >
>> >
>> >
>> >             SDWBP 29 - The examples section of “GetCapabilities” is
>> >             useful. Topic is otherwise covered in DWBP API section.
>> >             There has been much discussion in other venues about the
>> >             need for a landing page that contains GetCapabilities info.
>> >
>> >
>> >
>> >             SDWBP 30 - Again little specific to geo.  Should be covered
>> >             in DWBP?
>> >
>> >
>> >
>> >             As I said these are rough notes.  I hope to work more on
>> >             these tomorrow and may begin to experiment with alignment
>> >             with DWBP by topic (rather than number as suggested by
>> >             Phil).  Already seeing issue there such as in metadata
>> >             section where spatial metadata generally covers many of the
>> >             first few best practices.  So a one to one alignment may be
>> >             difficult without a great deal of repetition.
>> >
>> >
>> >
>> >             Cheers,
>> >
>> >
>> >
>> >             *Byron Cochrane
>> >             **SDI Technical Leader*
>> >
>> >             *New Zealand Geospatial Office*
>> >
>> >
>> >
>> >             *E**  bcochrane@linz.govt.nz
>> >             <mailto:bcochrane@linz.govt.nz>| **DDI** **04 460
>> >             0576| **M** **021 794 501*
>> >
>> >
>> >
>> >             *Wellington Office, Level 7, Radio New Zealand House, 155
>> >             The Terrace
>> >             PO Box 5501, Wellington 6145, New Zealand | **T**04 460
>> >             0110   **
>> >             **W  www.linz.govt.nz <http://www.linz.govt.nz/> |
>> >             data.linz.govt.nz <http://www.data.linz.govt.nz/> *
>> >
>> >
>> >
>> >
>> >
>> >             ------------------------------------------------------------------------
>> >
>> >             This message contains information, which may be in
>> >             confidence and may be subject to legal privilege. If you are
>> >             not the intended recipient, you must not peruse, use,
>> >             disseminate, distribute or copy this message. If you have
>> >             received this message in error, please notify us immediately
>> >             (Phone 0800 665 463 or info@linz.govt.nz
>> >             <mailto:info@linz.govt.nz>) and destroy the original
>> >             message. LINZ accepts no responsibility for changes to this
>> >             email, or for any attachments, after its transmission from
>> >             LINZ. Thank You.
>> >
>> 
>> --
>> Andrea Perego, Ph.D.
>> Scientific / Technical Project Officer
>> European Commission DG JRC
>> Directorate B - Growth and Innovation
>> Unit B6 - Digital Economy
>> Via E. Fermi, 2749 - TP 262
>> 21027 Ispra VA, Italy
>> 
>> https://ec.europa.eu/jrc/

Received on Friday, 22 July 2016 11:41:50 UTC