New Title

[cportele]

WFS has been the first group within OGC to work on a revision of an OGC Web Services standard as a Web API with OpenAPI support. By now, several other groups in OGC are working on similar revisions, too.

The Closing Plenary of the February 2019 OGC TC Meeting has discussed the naming of these revisions. The current proposal is to change the names and move towards the following pattern: "OGC API - {ResourceType}".

That is, "Web Feature Service" would become "OGC API - Features". There was no formal motion yet, but there were no concerns raised by members during the discussion, only supportive comments.

For now, I have created this issue so that we can keep track of the title discussion and to collect comments.

[akuckartz]

"Web Feature Service" is better than "OGC API - Feature":

• Well known established name
• Web Service is more specific and more precise than API
• No need for organisation name in specification name (compare with names of W3C Recommendations)

[ayiemba]

I feel "OGC {ResourceType} API" makes more sense. However, I wouldn't have an issue with whatever name it's called as long as there is support for OpenAPI.

[timoruohomaki]

Was there any discussion on short forms or acronyms? Will "OGC API - Features" still also be a "WFS"?

[jvanulde]

I'm with @akuckartz regarding the organization name. How about "Geo API" for features, "Map API" for maps and "Catalogue API" for catalogue etc.? Note that the concept of "features" is not widely understood, hence the "spatial things" proposal. I suppose we could prefix with "Open" (e.g. Open Geo API) if warranted (e.g. collision with ©, ®, ™).

[ogcscotts]

We have three goals in the naming: (1) to form a consistent pattern that matches the style of WS, (2) allow WS to exist concurrently as those standards are not likely to disappear from implementations any time soon, and (3) ensure that the standard names indicate the geospatial context. We also have to watch for confusion with OS Geo and the Opengeo Suite.

[lieberjosh]

OGC API for Features would become OAF. A bad implementation would be a clumsy OAF. Perhaps "OGC Feature API" would be better, OFA for short, giving OMA, OCA, and OPA ( a greek form of processing). Catalog is still iffy. Perhaps "OGC Registry API" -> ORA. Add Common Query Language and you have ORACQL. —Josh

…

On Mar 5, 2019, at 12:00 PM, Scott Simmons ***@***.***> wrote: We have three goals in the naming: (1) to form a consistent pattern that matches the style of WS, (2) allow WS to exist concurrently as those standards are not likely to disappear from implementations any time soon, and (3) ensure that the standard names indicate the geospatial context. We also have to watch for confusion with OS Geo and the Opengeo Suite. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#189 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AExWhiC8-ME74OJXZgcmRCX1VGLARhL7ks5vTqLLgaJpZM4bcq2B>.

[ogcscotts]

clever!

…

On Mar 5, 2019, at 10:59 AM, Josh Lieberman ***@***.***> wrote: OGC API for Features would become OAF. A bad implementation would be a clumsy OAF. Perhaps "OGC Feature API" would be better, OFA for short, giving OMA, OCA, and OPA ( a greek form of processing). Catalog is still iffy. Perhaps "OGC Registry API" -> ORA. Add Common Query Language and you have ORACQL. —Josh > On Mar 5, 2019, at 12:00 PM, Scott Simmons ***@***.***> wrote: > > We have three goals in the naming: (1) to form a consistent pattern that matches the style of WS, (2) allow WS to exist concurrently as those standards are not likely to disappear from implementations any time soon, and (3) ensure that the standard names indicate the geospatial context. We also have to watch for confusion with OS Geo and the Opengeo Suite. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub <#189 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AExWhiC8-ME74OJXZgcmRCX1VGLARhL7ks5vTqLLgaJpZM4bcq2B>. > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#189 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKD9qkgB4mKijCyXSNtoQH9TX-UhysTaks5vTrCOgaJpZM4bcq2B>.

[pvretano]

@lieberjosh As the only Greek currently engaged in this discussion, I fully support OPA! ;)

[lvdbrink]

Like @jvanulde I would prefer to avoid the term "Feature" as it can (and does) cause confusion when engaging with a wider audience, as discussed in the Spatial Data on the Web Best Practices.

Maybe Spatial data API?

[nmtoken]

Just as an aside, and probably spotted before, but... Spatial Data on the Web Best Practices <https://www.w3.org/TR/sdw-bp/#spatial-things-features-and-geometry> EXAMPLE 2: Eddystone Lighthouse geometry (encoded as GeoJSON [RFC7946]) { “geometry”: { “type”: “Point”, “coordinates”: [50.184, -4.268] } } That's wrong, GeoJSON is long lat so coordinates should be -4.268, 50.184 (just off the south coast of the UK) James

…

-----Original Message----- From: Linda van den Brink <notifications@github.com> Sent: 19 March 2019 14:08 To: opengeospatial/WFS_FES <WFS_FES@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [opengeospatial/WFS_FES] New Title (#189) Like @jvanulde <https://github.com/jvanulde> I would prefer to avoid the term "Feature" as it can (and does) cause confusion when engaging with a wider audience, as discussed in the Spatial Data on the Web Best Practices <https://www.w3.org/TR/sdw-bp/#spatial-things-features-and-geometry> . Maybe Spatial data API? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#189 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnU2wDFsMqHsu-kM3Gl2zXEu1X-vW3fks5vYO88gaJpZM4bcq2B> . <https://github.com/notifications/beacon/ABnU24mVcb6pyq-Bcf7y8l0WzQbDZZYXks5vYO88gaJpZM4bcq2B.gif> This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UK Research and Innovation does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UK Research and Innovation business are solely those of the author and do not represent the views of UK Research and Innovation.