- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Tue, 19 Jul 2016 17:01:42 +0200
- To: Jeremy Tandy <jeremy.tandy@gmail.com>
- Cc: "Little, Chris" <chris.little@metoffice.gov.uk>, Byron Cochrane <bcochrane@linz.govt.nz>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, Phil Archer <phila@w3.org>
Hi, Jeremy. On 19/07/2016 15:59, Jeremy Tandy wrote: > Andrea. Thanks for the additions. I keep forgetting what DQV can do for > us! Are you seeing any adoption in the wild yet? There are some implementations under-way, which are listed here: https://www.w3.org/2013/dwbp/wiki/List_of_DQV_implementations But this is all what I know (sorry). Andrea > BR, Jeremy > > On Tue, 19 Jul 2016 at 14:51 Jeremy Tandy <jeremy.tandy@gmail.com > <mailto:jeremy.tandy@gmail.com>> wrote: > > 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? > > 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/> > **http://www.linz.govt.nz/sites/default/files/images/email-signature-v2.png*____ > > __ __ > > __ __ > > ------------------------------------------------------------------------ > > 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 Tuesday, 19 July 2016 15:02:37 UTC