Hi Chris and all
Now more than a year later I'd like to revive this issue plus another one.
Both are related to my goal to implement a "minimal OGC-API-Features
Server" (formerly called "MiniWFS3").
Question 0: What's the "state of the spec." regarding the requirement
and meaning of "self-link" in a OGC-API-Features Server?
Then, we're struggling how to deal with the /api/ endpoint:
We're testing our minimal server implementation of OGC-API-Features
with ogrinfo as client.
And the maintainer of ogrinfo answered [1]:
> Conformant servers should implement a API page, not necessarily
> under the /api endpoint, but at the endpoint they declare in the landing page.
> See http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#_api_landing_page
I actually can't really follow the spec. about minimal required
"metadata" paths there:
So a server SHALL implement an /api/ response either as "relations
service-desc" or as "service-doc response with an Accept header"?
:Stefan
[1] https://lists.osgeo.org/pipermail/gdal-dev/2019-December/051296.html
Am Sa., 18. Mai 2019 um 22:27 Uhr schrieb Stefan Keller :
>
> 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
