The forthcoming OGC API Hackathon should help clarify much of these discussions.
Agree with Chris' endpoint patterns. I would probably update the CSW
endpoints like:
/collections/search
/search
To be continued -- stay tuned!
..Tom
On Sat, May 18, 2019 at 4:27 PM Stefan Keller wrote:
>
> Dear Chris (dear all)
>
> Thanks, Chris, again for your detailed answer and explanation.
>
> We've implemented a tiny WFS3 server in Go and I'm just stumbled over
> the response requiring a “self-link” (rel=“self” which includes the
> collectionId).
> Is that really mandatory - and what's it used for?
>
> (Tell me where to move with this discussion if this list isn't the right
> place).
>
> :Stefan
>
>
> Am Fr., 3. Mai 2019 um 16:41 Uhr schrieb Chris Holmes :
> >
> > Hey Stefan, I composed a pretty long message on my view on ideal
> > relationship between STAC and CSW, I'll paste it in below. The main
> > conceptual thing to me is that most CSW's have been about 'layer' level
> > search, and image / 'asset' level search is actually different. In OGC
> > history the 'ebrim profile' of CSW actually did the image / asset level
> > search well. But in my opinion they are different enough that we shouldn't
> > group them all in one thing. An asset level catalog could/should be
> > equivalent to a 'data cube', and so should slot at the 'layer' level.
> >
> > As for schema.org, we've made attempts to align with it, but at the level
> > where STAC is transformed into HTML output. See
> > https://github.com/radiantearth/stac-spec/blob/dev/catalog-spec/catalog-best-practices.md#stac-on-the-web
> > for info on how we think about HTML & STAC, and in particular the
> > sub-section on schema.org, etc.
> >
> > The in depth view I wrote on csw and stac is:
> >
> >
> > The ideal relationship between CSW, WFS and STAC is that WFS _is_ the api
> > that all three use. STAC and CSW should just be specialized content - they
> > use the same API response, but the JSON responses must comply with
> > particular JSON Schemas. With STAC the core is id, geometry, datetime,
> > links and assets -
> > https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md#item-fields
> > Any WFS Item that meets the STAC Schema could be considered part of STAC.
> > STAC also includes an ecosystem of more particular types that build on that
> > base. So the Electro-Optical extension has more fields that comply to a
> > schema that can be added and queried. The goal is to encourage more bottom
> > up communities of interest. But any of those can be queried from the STAC
> > endpoint. That's the vision at least, and we're trying to align with WFS to
> > do it, but there's more work needed, which I'll detail below.
> >
> > Then to me CSW should be a set of fields that describe a collection of
> > data. So it'd have like title, license, keywords, spatial and temporal
> > extents, etc. Could theoretically just use the same fields that CSW 3.0
> > defined, and make those a JSON content type. Define the schema, and then a
> > 'CSW 4.0' would just be a WFS 3 that serves up that content. WFS 3 still
> > hasn't quite specified its query language afaik, so maybe CSW4 requires a
> > particular richer query language. But it should be the same query language
> > that is at least an option for WFS. Thus any WFS client could naively query
> > a catalog, requesting the fields it needs and getting the response. A CSW 4
> > client would be an extension to the WFS one that perhaps takes advantage of
> > some more expectations. It could be possible that you would add like
> > 'harvesting' extensions for CSW 4, but those should be generic WFS API
> > mechanisms. So a CSW is a WFS endpoint that meets a set schema definition -
> > whatever flavor of dublin core works best - plus it may also specify some
> > required WFS API extensions that should be used.
> >
> > I do think there is an opportunity to combine WFS and CSW even more, by
> > aligning the schema of CSW with the response in the
> > /collection/{collectionId} endpoint in WFS. Like the way it defines
> > extents, title, etc. should be the same as the CSW JSON response. Ideally
> > CSW defines additional fields that are useful for defining a dataset, and
> > then the WFS /collection/{collectionId} endpoint can use those same fields.
> > This would make it so every WFS is 'harvestable' by a CSW. And then any WFS
> > could supply a special /collections/csw endpoint, that exposes the metadata
> > of all the other collections that are in that WFS.
> >
> > So basically CSW should be the summary of dataset / collection level
> > metadata, available through the WFS API. And then STAC is 'asset' level
> > metadata - references to other types of geographic files that can be
> > downloaded. So one could easily see a service that implements all three:
> >
> > /collections/buildings/ (a standard WFS layer - a set of vectors)
> > /collections/landsat/ (a STAC (and EO
