- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Fri, 22 Jul 2016 12:09:02 +0200
- To: Linda van den Brink <l.vandenbrink@geonovum.nl>
- Cc: "'Jeremy Tandy'" <jeremy.tandy@gmail.com>, "'public-sdw-wg@w3.org'" <public-sdw-wg@w3.org>, Byron Cochrane <bcochrane@linz.govt.nz>, "'Little, Chris'" <chris.little@metoffice.gov.uk>
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:09:46 UTC