- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Fri, 22 Jul 2016 11:45:16 +0000
- To: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Cc: Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Linda van den Brink <l.vandenbrink@geonovum.nl>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, Byron Cochrane <bcochrane@linz.govt.nz>, "Little, Chris" <chris.little@metoffice.gov.uk>
- Message-ID: <CADtUq_2isQJm6xAHixKsAYDHgu3HKT5Qv+SS-Z_qSJBzfRcViA@mail.gmail.com>
If we mention it in both places would that be enough? Jeremy On Fri, 22 Jul 2016 at 12:43, Joshua Lieberman <jlieberman@tumblingwalls.com> wrote: > 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:45:58 UTC