Re: [Hydro.dwg] [EXTERNAL] Re: json waterml2 / timeseriesml?

it should be trivial to define waterml as a profile of timeseriesml schema
- this is why we have been developing the building blocks tooling to
support transparent extensibility.:-)

we just define the waterML property set to require waterml extensions and
the core timeseries

allOf:
 - $ref: {timeseriesML schema}
- properties:
   waterml_prop1:
     .{scheme def}

anf then all examples will be tested against both, and the JSON-LD
context will be transitively inherited from timeseries (and sosa
underlying that!)

also SHACL rules for logical consistency get inherited


Rob Atkinson
*Senior Research Engineer * | Open Geospatial Consortium (OGC)
Mobile: +61 419 202973
ratkinson@ogc.org | ogc.org | @opengeospatial



Sign up for OGC News
<https://ogc.us4.list-manage.com/subscribe?u=704e02f81107a6caab1568067&id=4e4528fd9d>


On Fri, Jun 14, 2024 at 4:27 AM Kathi Schleidt <kathi@datacove.eu> wrote:

> Hi all,
>
> adding Paul Hershberg as Mr. TSML as a lot of this discussion is circling
> around TSML.
>
> There is an activity underway to update TSML to 2.0, taking the recent
> updates on both OMS and Coverage models into account, should be linked to
> whatever goes down here
>
> :)
>
> Kathi
> On 13.06.2024 20:10, Grellet Sylvain via Hydro.dwg wrote:
>
> Ø  *that includes key waterml2 domain details that are not included in
> TimeseriesML as an informative annex. *
>
> I’d rather keep those extra WaterML2.0 domain details handled in the
> HydroDWG (thus WaterML2.0 line) unless
>
> -          they are very generic (not so waterish afte rall)
>
> -          we just have 1 or 2 of them (to avoir proliferation of specs
> as well)
>
>
>
> If we end-up with having no need for creating water specific Class & al.
> what we could do would rather be turn WaterML2.0 Part 1 – TimeSeries into a
> Best Practice document explaining how to use TSML for quantitative water
> data.
>
> That’s exactly the road the Water Quality IE will suggest : everything
> covered in OMS, no need for extra-formal specs rather document how to use
> it for Water Quality Data to ease the uptake.
>
>
>
> Sylvain
>
>
>
> *De :* Blodgett, David L <dblodgett@usgs.gov> <dblodgett@usgs.gov>
> *Envoyé :* jeudi 13 juin 2024 19:34
> *À :* Rob Atkinson <ratkinson@ogc.org> <ratkinson@ogc.org>; Kyle Onda
> <konda@lincolninst.edu> <konda@lincolninst.edu>
> *Cc :* Grellet Sylvain <S.Grellet@brgm.fr> <S.Grellet@brgm.fr>;
> Hydro.dwg@lists.ogc.org; Schaaf, Hylke van der
> <hylke.vanderschaaf@iosb.fraunhofer.de>
> <hylke.vanderschaaf@iosb.fraunhofer.de>; SDW WG (public-sdw-wg@w3.org)
> <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>; Simon Cox <scox@ogc.org>
> <scox@ogc.org>
> *Objet :* RE: [EXTERNAL] Re: [Hydro.dwg] json waterml2 / timeseriesml?
>
>
>
> Thanks for the dialogue on this. Turns out similar questions are floating
> around in a few places.
>
>
>
> Whatever we come up with should be portable between custom APIs, OGC-API
> EDR (Position and Locations), STA, and the forthcoming OGC-API CONSYS part
> 2.
>
>
>
> I _*think*_ that we should probably pursue a basic (focus on ease of use
> and adoptability in preference to edge case support) json-schema for
> timeseriesML that includes key waterml2 domain details that are not
> included in TimeseriesML as an informative annex.
>
>
>
> Dave
>
>
>
> *From:* Rob Atkinson <ratkinson@ogc.org>
> *Sent:* Thursday, June 13, 2024 11:20 AM
> *To:* Kyle Onda <konda@lincolninst.edu>
> *Cc:* Grellet Sylvain <S.Grellet@brgm.fr>; Blodgett, David L <
> dblodgett@usgs.gov>; Hydro.dwg@lists.ogc.org; Schaaf, Hylke van der <
> hylke.vanderschaaf@iosb.fraunhofer.de>; SDW WG (public-sdw-wg@w3.org) <
> public-sdw-wg@w3.org>; Simon Cox <scox@ogc.org>
> *Subject:* [EXTERNAL] Re: [Hydro.dwg] json waterml2 / timeseriesml?
>
>
>
>
>
> * This email has been received from outside of DOI - Use caution before
> clicking on links, opening attachments, or responding.  *
>
>
>
> +1 for not proliferating.
>
>
>
> The way we could address this is add TimeseriesML/WaterML examples to the
> existing APIs and test using the Building Blocks.
>
>
>
> Note Building Blocks can also perform and test transformations (of
> examples - its about testing specifications).
>
>
>
> They also support cross-compiling across OpenAPI versions - noting
> ConnectedSystems has decided to aim for OAS 3.1 but other OGC APIs are at
> OAS 3.0 - we are solving this by a transpilation function to allow common
> elements to be shared on different versions - its far better to aim at
> current versions of JSON-schema than OAS 3.0 which has hacked a very old
> version...
>
>
>
> so not proliferating requires a degree of sophistication in how components
> are designed for reusability.  This is where the OGC COSI team is able to
> support, but we need the domain experts identifying requirements and
> developing realistic test cases, implementations and ultimately testing at
> scale with deployments.
>
>
> *Rob Atkinson*
>
> *Senior Research Engineer ** | Open Geospatial Consortium (OGC)*
>
> Mobile: +61 419 202973
>
> ratkinson@ogc.org | ogc.org
> <https://urldefense.com/v3/__http:/ogc.org/__;!!KbSiYrE!n_chQWkG0m5feRnrxoXQRdM9EoZUKCQVeFw_yGqLl2ZRoYBQ8jX8VScy0BP3hdcuRbh4jP3lzCtN4zPGKoCz$>
> | @opengeospatial
>
>
>
>
> *Sign up for OGC News*
> <https://urldefense.com/v3/__https:/ogc.us4.list-manage.com/subscribe?u=704e02f81107a6caab1568067&id=4e4528fd9d__;!!KbSiYrE!n_chQWkG0m5feRnrxoXQRdM9EoZUKCQVeFw_yGqLl2ZRoYBQ8jX8VScy0BP3hdcuRbh4jP3lzCtN44JNtwgN$>
>
>
>
>
>
> On Fri, Jun 14, 2024 at 1:44 AM Kyle Onda <konda@lincolninst.edu> wrote:
>
> I think a waterml2 JSON encoding, which could be an output format for
> hydro-relevant STA or EDR (or any other extant and future API specs)
> endpoints makes more sense than a new API.
>
>
>
>
>
> [image: A blue and green logo Description automatically generated]
>
> *Kyle Onda, PhD*
>
> Director, Internet of Water
>
> Center for Geospatial Solutions
> <https://urldefense.com/v3/__http:/www.cgsearth.org/__;!!KbSiYrE!n_chQWkG0m5feRnrxoXQRdM9EoZUKCQVeFw_yGqLl2ZRoYBQ8jX8VScy0BP3hdcuRbh4jP3lzCtN4yNr8Y9I$>
>
> Lincoln Institute of Land Policy
>
> 303 550 4432
>
> Location: Chapel Hill, NC
>
> Pronouns: he/him
>
>
>
> *Please note our business hours are Monday through Thursday, 8 am to 6 pm
> ET. With some exceptions, emails sent on Fridays will be addressed the
> following week.*
>
>
>
>
>
> *From: *Hydro.dwg <hydro.dwg-bounces+konda=lincolninst.edu@lists.ogc.org>
> on behalf of Grellet Sylvain via Hydro.dwg <hydro.dwg@lists.ogc.org>
> *Date: *Thursday, June 13, 2024 at 11:41 AM
> *To: *Rob Atkinson <ratkinson@ogc.org>, Blodgett, David L <
> dblodgett@usgs.gov>
> *Cc: *Hydro.dwg@lists.ogc.org <hydro.dwg@lists.ogc.org>, Schaaf, Hylke
> van der <hylke.vanderschaaf@iosb.fraunhofer.de>, SDW WG (
> public-sdw-wg@w3.org) <public-sdw-wg@w3.org>, Simon Cox <scox@ogc.org>
> *Subject: *Re: [Hydro.dwg] json waterml2 / timeseriesml?
>
> Does a Timeseries API also make sense - or does STA or EDR cover all
> requirements?
>
> I’ll let Hylke & Kathi complement but the way I see it is the following
>
> ST API 2.0 is OMS compliant
>
> My guts feeling is that TSML will end up 90% (or more) OMS compliant
>
> There is a high chance ST API covers (dunno for EDR)
>
> If the above is correct : I would suggest trying to reduce the entropy for
> the external world and not add yet another API. Otherwise for those not
> following all our internal OGC groups discussion, what the API to implement
> will be more and more complex.
>
>
>
> My 2 €
>
> Sylvain
>
>
>
>
>
> *De :* Rob Atkinson <ratkinson@ogc.org>
> *Envoyé :* jeudi 13 juin 2024 17:30
> *À :* Blodgett, David L <dblodgett@usgs.gov>
> *Cc :* Hydro.dwg@lists.ogc.org; Simon Cox <scox@ogc.org>; SDW WG (
> public-sdw-wg@w3.org) <public-sdw-wg@w3.org>
> *Objet :* Re: [Hydro.dwg] json waterml2 / timeseriesml?
>
>
>
> There is a functional OGC Building Block for the Observations and
> Measurements model as Features here:
>
>
>
> https://github.com/opengeospatial/ogcapi-sosa
> <https://urldefense.com/v3/__https:/github.com/opengeospatial/ogcapi-sosa__;!!KbSiYrE!m10Fc0eL5fJQIQ6s8LmFxL6rrLEQCDf3UEaCq3k510Xw6QJcJI4QtQ8XqLBN9QrTU66zxOeJMW4zK_GorA$>
>
>
>
> This is being co-developed with the SSN/SOSA update to match the new OMS
> specification.
>
>
>
> can spin up customised profiles of these easily - e.g.
>
>
>
>
> https://ogcincubator.github.io/bblocks-examples/bblock/ogc.bbr.examples.observation.vectorObservationFeature
> <https://urldefense.com/v3/__https:/ogcincubator.github.io/bblocks-examples/bblock/ogc.bbr.examples.observation.vectorObservationFeature__;!!KbSiYrE!m10Fc0eL5fJQIQ6s8LmFxL6rrLEQCDf3UEaCq3k510Xw6QJcJI4QtQ8XqLBN9QrTU66zxOeJMW5FeQQS9w$>
>
>
>
>
>
> there are also experiments and activities to explore how common we can
> make domain models with different APIs for different packaging of
> observations, including OGC API EDR, SensorThingsAPI and
> ConnectedSystemsAPI.
>
>
>
> So I think there may be a number of alternative encodings required,
> depending on which API to serve them, but some commonalities we can factor
> out as BuildingBlocks.
>
>
>
> Does a Timeseries API also make sense - or does STA or EDR cover all
> requirements?
>
>
> *Rob Atkinson*
>
> *Senior Research Engineer ** | Open Geospatial Consortium (OGC)*
>
> Mobile: +61 419 202973
>
> ratkinson@ogc.org | ogc.org
> <https://urldefense.com/v3/__http:/ogc.org/__;!!KbSiYrE!m10Fc0eL5fJQIQ6s8LmFxL6rrLEQCDf3UEaCq3k510Xw6QJcJI4QtQ8XqLBN9QrTU66zxOeJMW5K_TD6Ew$>
> | @opengeospatial
>
>
>
>
>
> *Sign up for OGC News*
> <https://urldefense.com/v3/__https:/ogc.us4.list-manage.com/subscribe?u=704e02f81107a6caab1568067&id=4e4528fd9d__;!!KbSiYrE!m10Fc0eL5fJQIQ6s8LmFxL6rrLEQCDf3UEaCq3k510Xw6QJcJI4QtQ8XqLBN9QrTU66zxOeJMW6eGMtr4Q$>
>
>
>
>
>
> On Fri, Jun 14, 2024 at 12:36 AM Blodgett, David L via Hydro.dwg <
> hydro.dwg@lists.ogc.org> wrote:
>
> Hi All –
>
>
>
> In conversation today, the topic of a json encoding of WaterML2 or
> TimeseriesML came up. Is anyone aware of progress on such a thing? Seems
> like someone must have done something like that even as an ad-hoc
> experiment. Is there a world where we could establish a json encoding for
> hydrologic timeseries data?
>
>
>
> Thanks.
>
>
>
> Dave
>
> _______________________________________________
> You may visit our Privacy Policy at http://www.opengeospatial.org/privacy
> <https://urldefense.com/v3/__http:/www.opengeospatial.org/privacy__;!!KbSiYrE!m10Fc0eL5fJQIQ6s8LmFxL6rrLEQCDf3UEaCq3k510Xw6QJcJI4QtQ8XqLBN9QrTU66zxOeJMW6TU6Ow1g$>
> .
> Hydro.dwg mailing list
> Hydro.dwg@lists.ogc.org
> You may also unsubscribe or manage your OGC public list subscriptions at
>  https://lists.ogc.org/mailman/listinfo/hydro.dwg
> <https://urldefense.com/v3/__https:/lists.ogc.org/mailman/listinfo/hydro.dwg__;!!KbSiYrE!m10Fc0eL5fJQIQ6s8LmFxL6rrLEQCDf3UEaCq3k510Xw6QJcJI4QtQ8XqLBN9QrTU66zxOeJMW6Vdj2VfQ$>
>
>
> _______________________________________________
> You may visit our Privacy Policy at http://www.opengeospatial.org/privacy.
> Hydro.dwg mailing listHydro.dwg@lists.ogc.org
> You may also unsubscribe or manage your OGC public list subscriptions at
>  https://lists.ogc.org/mailman/listinfo/hydro.dwg
>
> --
>
> *Katharina Schleidt*
>
> CEO, Data Modeler, Data Networking Expert
>
>
>
> *DataCove e.U.*,
> Robert Hamerlingg. 1/14,
> 1150 Vienna, Austria
>
> Tel:
>
> Mobile:
>
> Skype:
>
> E-Mail:
>
> Web:
>
> +43 (1) 89 234 26
>
> +43 (650) 89 234 26
>
> Kathi Schleidt
>
> Kathi@DataCove.eu
>
> www.DataCove.eu
>
>
>
>
>
>
>
>
>
> *FAIR information cube*,
> Horizon EU project,
> https://doi.org/10.3030/101059238
>
> E-mail:
>
> Web:
>
> fairicube@nilu.no
>
> www.fairicube.eu
>
>
>
> In the twenty-first century censorship works by flooding people with
> irrelevant information.
>
>                 -- Homo Deus, Yuval Noah Harari
>
> Do what you can, when you can, because you can
>
>                 -- Anonymous, paraphrasing Theodore Roosevelt
>
>
>
> Please note that the fact that you have received this email implies that
> your mail address is stored on my system's address book. If this bothers
> you, please get in touch, and I will delete your information.
>
>
>