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?

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