- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Fri, 22 Jul 2016 10:18:02 +0000
- To: Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Linda van den Brink <l.vandenbrink@geonovum.nl>
- Cc: "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_2sagMt2B=Mz7jn6MrcU-A4J_z5SWnz4+mwYT+Lsmqrqg@mail.gmail.com>
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 10:18:45 UTC