- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Tue, 19 Jul 2016 16:53:13 +0200
- To: Jeremy Tandy <jeremy.tandy@gmail.com>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Cc: "Little, Chris" <chris.little@metoffice.gov.uk>, Byron Cochrane <bcochrane@linz.govt.nz>
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