Re: DWBP SDWBP alignment notes

Andrea. Thanks for the additions. I keep forgetting what DQV can do for us!
Are you seeing any adoption in the wild yet?

BR, Jeremy

On Tue, 19 Jul 2016 at 14:51 Jeremy Tandy <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> 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 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.
>>>>
>>>