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
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.