Re: DWBP SDWBP alignment notes

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 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> 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>
> 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]
>> *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 <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/>  **[image:
>> 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) 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.
>>
>