Re: DWBP SDWBP alignment notes

On 19/07/2016 15:45, Jeremy Tandy wrote:
>
> [snip]
>
> 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'.

I think the SDW-relevant point here is how to provide API documentation 
that can be consumed (also) by non-geo-specific users and applications. 
We may provide some guidance here.

In particular, I see 2 possible use cases (but there may be more):

1. One of the most frustrating experiences of non-geo users is when they 
click on a "download" link from a data catalogue, and they land on a 
GetCapabilities XML document. They typically have no clue of what this 
is about, and usually catalogues don't provide a hint about what you're 
going to land on and how you can use it. Byron already mentions 
discussions on "a landing page that contains GetCapabilities info": this 
would give at least people an idea of what they're looking at.

2. The next bit is about making GetCapabilities understandable also by 
non-geo applications. This does not necessarily require representing the 
full capabilities in other API description languages. It could be enough 
to indicate (a) that this is not a "file" but an API, (b) the type of 
service / API (WMS, WFS, etc.), and, possibly, (c) basic queries (which 
relates to SDWBP 30).


Just to give an example about point (2), in relation to metadata:

There's some work under-way in DCAT-AP to find a way to model 
"service-base data access" - i.e., dataset distributions pointing to a 
service / API (not necessarily geospatial). The current proposal is 
described here:

https://joinup.ec.europa.eu/node/152004

Briefly, the idea is to use an OpenSearch description document linked 
from (or embedded in) metadata records. For geo-services, this can be 
generated at runtime from the GetCapabilities with an XSLT 
transformation (and the same can be done to generate an HTML 
presentation), which also means that it's a feature that can be 
supported on top of an OGC service, without affecting the underline 
infrastructure. What you need is just to use a "standard" 
GetCapabilities -> OpenSearch transformation (but, AFAIK, this is not 
available).


Andrea


> 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/>
>         **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 14:54:14 UTC