Re: DWBP SDWBP alignment notes

Hi, Jeremy.

My comments inline.

On 19/07/2016 14:52, Jeremy Tandy 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.

The current approach used in GeoDCAT-AP for specifying reference systems 
is outlined here:

https://lists.w3.org/Archives/Public/public-sdw-wg/2016May/0072.html

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

+1 from me. The DWBP Data Quality Vocabulary (DQV) may offer a way to 
model this.

On a different note, DQV already includes examples on how to specify 
data precision and accuracy, as well as spatial resolution. The relevant 
section:

https://www.w3.org/TR/vocab-dqv/#ExpressDatasetAccuracyPrecision

I contributed the examples on spatial resolution [1], but they're 
focussed on the "metadata" use case. So, I wonder whether the DQV 
approach is fit also for other SDW scenarios.

Andrea

----
[1]https://lists.w3.org/Archives/Public/public-sdw-comments/2016Mar/0007.html


>
> 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/>
>     **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.____
>

-- 
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/

Received on Tuesday, 19 July 2016 13:28:22 UTC