RE: DWBP SDWBP alignment notes

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]
Sent: Wednesday, July 13, 2016 11:52 PM
To: '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.