International Federation of Digital Seismograph Networks

Thread: Re: fdsnws-event - add support for event type in query and text format

None
Started: 2016-07-22 05:52:15
Last activity: 2016-08-03 01:14:36
QuakeML, but it is a generic point too for any system or data format that aims to be useful for volcano-seismology. Much of my own work at different observatories has involved taking systems and database schema designed for regional earthquake monitoring and expanding them to support volcano-seismic monitoring needs. But maybe QuakeML isn't meant to support the exchange of volcano-seismic event metadata because many such events are small - which leads to other issues.

On Jul 21, 2016, at 9:32 PM, Jeremy Fee <jmfee<at>usgs.gov> wrote:

Are you asking why those are omitted from the Quakeml spec, or from the USGS event web service?


Thanks,

Jeremy


On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thompson <thompsong<at>mail.usf.edu> wrote:
Slightly off topic perhaps but I am wondering why volcano-seismic event types are omitted? By this I mean some labels that identify events as volcano-tectonic, hybrid, long-period, and rockfall/pyroclastic flow. These are common to most volcano observatories. For example, I classified much of the Montserrat catalog (a 15 year eruption) and there were several tens of thousands of events in each of these categories, and much of the downstream automated and manual analysis relies on these categorizations.

On Jul 21, 2016, at 6:31 PM, Jeremy Fee <jmfee<at>usgs.gov> wrote:

Hello,

The USGS fdsnws-event web service already supports an "eventtype" parameter as an extension, and it is included in our extension output formats csv and geojson:
http://earthquake.usgs.gov/fdsnws/event/1/

I recommend using the actual quakeml values ("earthquake" instead of "Earthquake").


Thanks,

Jeremy


On Thu, Jul 21, 2016 at 11:23 AM, John Clinton <jclinton<at>sed.ethz.ch> wrote:
Dear FDSN WG III,

I would like to propose a change to fdsnws-event. Currently, there is very limited support for event type. This information is given in the quakeML XML output, but it is missing from the text output. Also, it would be very useful to be able to query catalogues by event type.

I know there is a long story about what is the correct nomenclature for event type, but quakeML1.2 supports the following event types as seen in
https://quake.ethz.ch/quakeml/docs/notes?action=AttachFile&do=view&target=quakeml-1.2-classdiag-AI.pdf

I would suggest if eventype is not specified in a query, the default would be ‘Earthquake’ (many of us offering fdsnws-event only support EventType=Earthquake anyway).

Is there any established procedure to manage changing versions of fdsnws? It hasn’t changed since 4/2013.

John



----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/


----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/


----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/

  • We're having similar discussions over more specific landslide event types.

    I suspect the simplest way forward is to use a generic quakeml event type,
    and implement a quakeml extension that allows more flexibility.


    Thanks,

    Jeremy



    On Thu, Jul 21, 2016 at 3:52 PM, Glenn Thompson <thompsong<at>mail.usf.edu>
    wrote:

    QuakeML, but it is a generic point too for any system or data format that
    aims to be useful for volcano-seismology. Much of my own work at different
    observatories has involved taking systems and database schema designed for
    regional earthquake monitoring and expanding them to support
    volcano-seismic monitoring needs. But maybe QuakeML isn't meant to support
    the exchange of volcano-seismic event metadata because many such events are
    small - which leads to other issues.

    On Jul 21, 2016, at 9:32 PM, Jeremy Fee <jmfee<at>usgs.gov> wrote:

    Are you asking why those are omitted from the Quakeml spec, or from the
    USGS event web service?


    Thanks,

    Jeremy


    On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thompson <thompsong<at>mail.usf.edu>
    wrote:

    Slightly off topic perhaps but I am wondering why volcano-seismic event
    types are omitted? By this I mean some labels that identify events as
    volcano-tectonic, hybrid, long-period, and rockfall/pyroclastic flow. These
    are common to most volcano observatories. For example, I classified much of
    the Montserrat catalog (a 15 year eruption) and there were several tens of
    thousands of events in each of these categories, and much of the downstream
    automated and manual analysis relies on these categorizations.

    On Jul 21, 2016, at 6:31 PM, Jeremy Fee <jmfee<at>usgs.gov> wrote:

    Hello,

    The USGS fdsnws-event web service already supports an "eventtype"
    parameter as an extension, and it is included in our extension output
    formats csv and geojson:

    http://earthquake.usgs.gov/fdsnws/event/1/


    I recommend using the actual quakeml values ("earthquake" instead of
    "Earthquake").


    Thanks,

    Jeremy


    On Thu, Jul 21, 2016 at 11:23 AM, John Clinton <jclinton<at>sed.ethz.ch>
    wrote:

    Dear FDSN WG III,

    I would like to propose a change to fdsnws-event. Currently, there is
    very limited support for event type. This information is given in the
    quakeML XML output, but it is missing from the text output. Also, it would
    be very useful to be able to query catalogues by event type.

    I know there is a long story about what is the correct nomenclature for
    event type, but quakeML1.2 supports the following event types as seen in

    https://quake.ethz.ch/quakeml/docs/notes?action=AttachFile&do=view&target=quakeml-1.2-classdiag-AI.pdf

    I would suggest if eventype is not specified in a query, the default
    would be ‘Earthquake’ (many of us offering fdsnws-event only support
    EventType=Earthquake anyway).

    Is there any established procedure to manage changing versions of
    fdsnws? It hasn’t changed since 4/2013.

    John



    ----------------------
    FDSN Working Group III (
    http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

    Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
    Update subscription preferences at http://www.fdsn.org/account/profile/



    ----------------------
    FDSN Working Group III (
    http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

    Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
    Update subscription preferences at http://www.fdsn.org/account/profile/



    ----------------------
    FDSN Working Group III (
    http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

    Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
    Update subscription preferences at http://www.fdsn.org/account/profile/


    • Marcelo Belentani de Bianchi
      2016-07-22 05:08:11
      Dear List,

      In the frame work of changes of the text format, one issue that has been
      affecting us (@USP/Brazil) is the lack of EvaluationMode in the text format.

      Also, ability to filter by eventType could potentially be more explored.
      Today we just filter then out, before serving other events than
      earthquakes because of the lack of such a feature.

      On the other hand, what fields go into the text format could be trick
      discussion and we could end-up with a quite huge list of fields in the
      future. Each DC could have its own needs. Maybe, a more natural approach
      in my view would be if the text-format (as an alternative format of the
      event-ws service) could be configured by the client by a parameter like:

      textfields="EventID,Time,Latitude,Longitude,Depth,Author,EvaluationMode".

      this parameter would have its default value as it is established today,
      but would be extensible to fit everyone needs. Another option would be
      to name this parameter fields="" and would control all secondary formats
      exported by the server.

      best regards,

      Marcelo Bianchi

      On 21-07-2016 19:03, Jeremy Fee wrote:
      We're having similar discussions over more specific landslide event types.

      I suspect the simplest way forward is to use a generic quakeml event
      type, and implement a quakeml extension that allows more flexibility.


      Thanks,

      Jeremy



      On Thu, Jul 21, 2016 at 3:52 PM, Glenn Thompson <thompsong<at>mail.usf.edu
      <thompsong<at>mail.usf.edu>> wrote:

      QuakeML, but it is a generic point too for any system or data format
      that aims to be useful for volcano-seismology. Much of my own work
      at different observatories has involved taking systems and database
      schema designed for regional earthquake monitoring and expanding
      them to support volcano-seismic monitoring needs. But maybe QuakeML
      isn't meant to support the exchange of volcano-seismic event
      metadata because many such events are small - which leads to other
      issues.

      On Jul 21, 2016, at 9:32 PM, Jeremy Fee <jmfee<at>usgs.gov
      <jmfee<at>usgs.gov>> wrote:

      Are you asking why those are omitted from the Quakeml spec, or from
      the USGS event web service?


      Thanks,

      Jeremy


      On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thompson
      <thompsong<at>mail.usf.edu <thompsong<at>mail.usf.edu>> wrote:

      Slightly off topic perhaps but I am wondering why
      volcano-seismic event types are omitted? By this I mean some
      labels that identify events as volcano-tectonic, hybrid,
      long-period, and rockfall/pyroclastic flow. These are common to
      most volcano observatories. For example, I classified much of
      the Montserrat catalog (a 15 year eruption) and there were
      several tens of thousands of events in each of these categories,
      and much of the downstream automated and manual analysis relies
      on these categorizations.

      On Jul 21, 2016, at 6:31 PM, Jeremy Fee <jmfee<at>usgs.gov
      <jmfee<at>usgs.gov>> wrote:

      Hello,

      The USGS fdsnws-event web service already supports an
      "eventtype" parameter as an extension, and it is included in our
      extension output formats csv and geojson:

      http://earthquake.usgs.gov/fdsnws/event/1/


      I recommend using the actual quakeml values ("earthquake"
      instead of "Earthquake").


      Thanks,

      Jeremy


      On Thu, Jul 21, 2016 at 11:23 AM, John Clinton
      <jclinton<at>sed.ethz.ch <jclinton<at>sed.ethz.ch>> wrote:

      Dear FDSN WG III,

      I would like to propose a change to fdsnws-event. Currently,
      there is very limited support for event type. This
      information is given in the quakeML XML output, but it is
      missing from the text output. Also, it would be very useful
      to be able to query catalogues by event type.

      I know there is a long story about what is the correct
      nomenclature for event type, but quakeML1.2 supports the
      following event types as seen in
      https://quake.ethz.ch/quakeml/docs/notes?action=AttachFile&do=view&target=quakeml-1.2-classdiag-AI.pdf

      I would suggest if eventype is not specified in a query, the
      default would be ‘Earthquake’ (many of us offering
      fdsnws-event only support EventType=Earthquake anyway).

      Is there any established procedure to manage changing
      versions of fdsnws? It hasn’t changed since 4/2013.

      John

      --
      Centro de Sismologia ~ http://www.moho.iag.usp.br
      Inst. Astro. Geof. e Cien. Atms. ~ http://www.iag.usp.br/geofisica
      Universidade de São Paulo ~ http://www.usp.br/

      • Dear all,

        Dear all,

        there seem to be two discussions required:
        a) event-types overall (and in QuakeML)
        b) utlizing of event-types in the fdsn-webservices

        While connected, they are in my view distinct / independent…

        A few comments on both, anyway:

        a)
        I would agree that the addition of more specific ‘volcanic events’ (beyond the currently included ‘volcanic eruption’) would make sense - in particular in comparison with the granularity that is available for some other types. (Of course the definitions have a history that reflects the ‘user group’ that came up with them…), and also looking forward to the attempts to enhance interoperability of services…

        QuakeML event types seem to map largely to the IASPEI/CoSOI proposal (from 2012/2013, discussed at the Gothenburg assembly, and (as far as I recall) approved there or shortly after). In that proposal the event type has a hierarchy - i.e. an ‘explosion’ would be _any_ of the various specific explosion types. Is this also clear in QuakeML?

        It would be good if the ‘event type’ definitions would not only exist as part of a data model, but also as a well defined vocabulary (with some explanation what exactly is meant, e.g. making the difference between a landslide and a rockslide (and specifying that a rockfall should be classified as rockslide?) (Maybe they are and I just don’t know it…)

        In order to not become infinite, perhaps introducing an ‘other_specific’ type which can then have a ‘free’ text entry (character-limited to something reasonable…) could work (would probably require that QuakeML EventType gets a hierarchy…) - and once some type establishes itself as a ’standard’, then introduce it to the standard type set?

        the ‘evaluation_mode’ would be useful for event type (agree with Marcelo) - in particular as we see more and more ‘automatic classficiation’ attempts… (I guess initially the thinking was that anything that has an event type specified would be assumed to be ‘manual’ )

        b)
        Seems that query-able event types would indeed be a good thing… (and returning the type :-)

        - Should then the queries also respect hierarchies (return all types of induced events, when queried for ‘anthropogenic event’ / return all types of explosions, when queried for ‘explosion’)? Or would the user have to know & accept that if she wants all explosions, she’d have to query for ‘explosion’ AND all specific explosion types?

        - query default (no event type specified): return everything (only if there is an ‘any’ parameter allowed, in the query I would agree to return ‘only earthquake’ by default, if nothing specified)

        - query exclude should be implemented (return anything that _is-not_ a given type)

        - should simultaneous querying for multiple types be possible? (is that useful?)


        Kind regards,

        Florian









        On 22 Jul 2016, at 3:09 AM, Marcelo Belentani de Bianchi <m.bianchi<at>iag.usp.br> wrote:

        Dear List,

        In the frame work of changes of the text format, one issue that has been
        affecting us (@USP/Brazil) is the lack of EvaluationMode in the text format.

        Also, ability to filter by eventType could potentially be more explored.
        Today we just filter then out, before serving other events than
        earthquakes because of the lack of such a feature.

        On the other hand, what fields go into the text format could be trick
        discussion and we could end-up with a quite huge list of fields in the
        future. Each DC could have its own needs. Maybe, a more natural approach
        in my view would be if the text-format (as an alternative format of the
        event-ws service) could be configured by the client by a parameter like:

        textfields="EventID,Time,Latitude,Longitude,Depth,Author,EvaluationMode".

        this parameter would have its default value as it is established today,
        but would be extensible to fit everyone needs. Another option would be
        to name this parameter fields="" and would control all secondary formats
        exported by the server.

        best regards,

        Marcelo Bianchi

        On 21-07-2016 19:03, Jeremy Fee wrote:
        We're having similar discussions over more specific landslide event types.

        I suspect the simplest way forward is to use a generic quakeml event
        type, and implement a quakeml extension that allows more flexibility.


        Thanks,

        Jeremy



        On Thu, Jul 21, 2016 at 3:52 PM, Glenn Thompson <thompsong<at>mail.usf.edu
        <thompsong<at>mail.usf.edu>> wrote:

        QuakeML, but it is a generic point too for any system or data format
        that aims to be useful for volcano-seismology. Much of my own work
        at different observatories has involved taking systems and database
        schema designed for regional earthquake monitoring and expanding
        them to support volcano-seismic monitoring needs. But maybe QuakeML
        isn't meant to support the exchange of volcano-seismic event
        metadata because many such events are small - which leads to other
        issues.

        On Jul 21, 2016, at 9:32 PM, Jeremy Fee <jmfee<at>usgs.gov
        <jmfee<at>usgs.gov>> wrote:

        Are you asking why those are omitted from the Quakeml spec, or from
        the USGS event web service?


        Thanks,

        Jeremy


        On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thompson
        <thompsong<at>mail.usf.edu <thompsong<at>mail.usf.edu>> wrote:

        Slightly off topic perhaps but I am wondering why
        volcano-seismic event types are omitted? By this I mean some
        labels that identify events as volcano-tectonic, hybrid,
        long-period, and rockfall/pyroclastic flow. These are common to
        most volcano observatories. For example, I classified much of
        the Montserrat catalog (a 15 year eruption) and there were
        several tens of thousands of events in each of these categories,
        and much of the downstream automated and manual analysis relies
        on these categorizations.

        On Jul 21, 2016, at 6:31 PM, Jeremy Fee <jmfee<at>usgs.gov
        <jmfee<at>usgs.gov>> wrote:

        Hello,

        The USGS fdsnws-event web service already supports an
        "eventtype" parameter as an extension, and it is included in our
        extension output formats csv and geojson:

        http://earthquake.usgs.gov/fdsnws/event/1/


        I recommend using the actual quakeml values ("earthquake"
        instead of "Earthquake").


        Thanks,

        Jeremy


        On Thu, Jul 21, 2016 at 11:23 AM, John Clinton
        <jclinton<at>sed.ethz.ch <jclinton<at>sed.ethz.ch>> wrote:

        Dear FDSN WG III,

        I would like to propose a change to fdsnws-event. Currently,
        there is very limited support for event type. This
        information is given in the quakeML XML output, but it is
        missing from the text output. Also, it would be very useful
        to be able to query catalogues by event type.

        I know there is a long story about what is the correct
        nomenclature for event type, but quakeML1.2 supports the
        following event types as seen in
        https://quake.ethz.ch/quakeml/docs/notes?action=AttachFile&do=view&target=quakeml-1.2-classdiag-AI.pdf

        I would suggest if eventype is not specified in a query, the
        default would be ‘Earthquake’ (many of us offering
        fdsnws-event only support EventType=Earthquake anyway).

        Is there any established procedure to manage changing
        versions of fdsnws? It hasn’t changed since 4/2013.

        John

        --
        Centro de Sismologia ~ http://www.moho.iag.usp.br
        Inst. Astro. Geof. e Cien. Atms. ~ http://www.iag.usp.br/geofisica
        Universidade de São Paulo ~ http://www.usp.br/

        ----------------------
        FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

        Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
        Update subscription preferences at http://www.fdsn.org/account/profile/


    • Jeremy Fee wrote on 07/22/2016 12:03 AM:
      I suspect the simplest way forward is to use a generic quakeml event
      type, and implement a quakeml extension that allows more flexibility.

      The extension would then be part of the XML document but unaware QuakeML
      parsers would yield the generic event type. A better way would be to
      raise the issue on the QuakeML mailing list and propose inclusion of
      those additional event types into QuakeML.

      The current list of event types is the result of discussions between
      several European and American institutions heavily involving the USGS.
      It would be good if the USGS could continue to contribute to the
      development of core QuakeML rather than filling gaps by using
      proprietary extensions.

      That said, I would be glad to see the USGS eventtype extension to
      fdsnws-event added to the standard.

      Regards
      Joachim

      • Actually the latest event type list for both QuakeML and ISF has been
        developed in 2012 jointly by the ISC, NEIC and EMSC and discussed at the
        appropriate IASPEI commission - CoSOI. It is attached. I believe it was
        passed on to the QuakeML proprietors for inclusion in the next (at the
        time) version. It is used by the NEIC as far as I know.

        Regards,
        Dmitry

        Dr. Dmitry A. Storchak
        Director
        International Seismological Centre (ISC)
        United Kingdom

        www.isc.ac.uk
        +44 (0)1635 861022

        On 22/07/2016 10:31, Joachim Saul wrote:
        Jeremy Fee wrote on 07/22/2016 12:03 AM:
        I suspect the simplest way forward is to use a generic quakeml event
        type, and implement a quakeml extension that allows more flexibility.
        The extension would then be part of the XML document but unaware QuakeML
        parsers would yield the generic event type. A better way would be to
        raise the issue on the QuakeML mailing list and propose inclusion of
        those additional event types into QuakeML.

        The current list of event types is the result of discussions between
        several European and American institutions heavily involving the USGS.
        It would be good if the USGS could continue to contribute to the
        development of core QuakeML rather than filling gaps by using
        proprietary extensions.

        That said, I would be glad to see the USGS eventtype extension to
        fdsnws-event added to the standard.

        Regards
        Joachim

        ----------------------
        FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

        Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
        Update subscription preferences at http://www.fdsn.org/account/profile/




        Attachments
        • Dear all,

          [ I had tried to send below text earlier today - but apparently it didn’t go through (non-registered sender address used, realized that after Joachim’s & Dmitry's messages came in…). It is somewhat redundant to points raised by Joachim & Dmitry (and Dmitry already now sent the document that I had also wanted to attach, so it’s omitted) …]

          there seem to be two discussions required:
          a) event-types overall (and in QuakeML)
          b) utlizing of event-types in the fdsn-webservices

          While connected, they are in my view distinct / independent…

          A few comments on both, anyway:

          a)
          I would agree that the addition of more specific ‘volcanic events’ (beyond the currently included ‘volcanic eruption’) would make sense - in particular in comparison with the granularity that is available for some other types. (Of course the definitions have a history that reflects the ‘user group’ that came up with them…), and also looking forward to the attempts to enhance interoperability of services…

          QuakeML event types seem to map largely to the IASPEI/CoSOI proposal (from 2012/2013, discussed at the Gothenburg assembly, and (as far as I recall) approved there or shortly after). In that proposal the event type has a hierarchy - i.e. an ‘explosion’ would be _any_ of the various specific explosion types. Is this also clear in QuakeML?

          It would be good if the ‘event type’ definitions would not only exist as part of a data model, but also as a well defined vocabulary (with some explanation what exactly is meant, e.g. making the difference between a landslide and a rockslide (and specifying that a rockfall should be classified as rockslide?) (Maybe they are and I just don’t know it…)

          In order to not become infinite, perhaps introducing an ‘other_specific’ type which can then have a ‘free’ text entry (character-limited to something reasonable…) could work (would probably require that QuakeML EventType gets a hierarchy…) - and once some type establishes itself as a ’standard’, then introduce it to the standard type set?

          the ‘evaluation_mode’ would be useful for event type (agree with Marcelo) - in particular as we see more and more ‘automatic classficiation’ attempts… (I guess initially the thinking was that anything that has an event type specified would be assumed to be ‘manual’ )

          b)
          Seems that query-able event types would indeed be a good thing…

          - Should then the queries also respect hierarchies (return all types of induced events, when queried for ‘anthropogenic event’ / return all types of explosions, when queried for ‘explosion’)? Or would the user have to know & accept that if she wants all explosions, she’d have to query for ‘explosion’ AND all specific explosion types?

          - query default (no event type specified): return everything (only if there is an ‘any’ parameter allowed, in the query I would agree to return ‘only earthquake’ by default, if nothing specified)

          - query exclude should be implemented (return anything that _is-not_ a given type)

          - should simultaneous querying for multiple types be possible? (is that useful?)

          Kind regards,
          Florian

          ----------------------------
          Swiss Seismological Service
          ETH Zurich

          Dr. Florian Haslinger
          NO H65
          Sonneggstr. 5
          CH - 8092 Zürich
          Switzerland

          ph: +41-44-633 4670
          www.seismo.ethz.ch


          On 22 Jul 2016, at 11:41 AM, Dmitry Storchak <dmitry<at>isc.ac.uk> wrote:

          Actually the latest event type list for both QuakeML and ISF has been developed in 2012 jointly by the ISC, NEIC and EMSC and discussed at the appropriate IASPEI commission - CoSOI. It is attached. I believe it was passed on to the QuakeML proprietors for inclusion in the next (at the time) version. It is used by the NEIC as far as I know.

          Regards,
          Dmitry

          Dr. Dmitry A. Storchak
          Director
          International Seismological Centre (ISC)
          United Kingdom

          www.isc.ac.uk
          +44 (0)1635 861022

          On 22/07/2016 10:31, Joachim Saul wrote:
          Jeremy Fee wrote on 07/22/2016 12:03 AM:
          I suspect the simplest way forward is to use a generic quakeml event
          type, and implement a quakeml extension that allows more flexibility.
          The extension would then be part of the XML document but unaware QuakeML
          parsers would yield the generic event type. A better way would be to
          raise the issue on the QuakeML mailing list and propose inclusion of
          those additional event types into QuakeML.

          The current list of event types is the result of discussions between
          several European and American institutions heavily involving the USGS.
          It would be good if the USGS could continue to contribute to the
          development of core QuakeML rather than filling gaps by using
          proprietary extensions.

          That said, I would be glad to see the USGS eventtype extension to
          fdsnws-event added to the standard.

          Regards
          Joachim

          ----------------------
          FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

          Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
          Update subscription preferences at http://www.fdsn.org/account/profile/



          <event_types.pdf>
          ----------------------
          FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

          Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
          Update subscription preferences at http://www.fdsn.org/account/profile/





          • Hi Florian, hi all,

            QuakeML event types seem to map largely to the IASPEI/CoSOI proposal (from
            2012/2013, discussed at the Gothenburg assembly, and (as far as I recall)
            approved there or shortly after).

            This proposal was adopted in QuakeML 1.2 without changes.

            In that proposal the event type has a
            hierarchy - i.e. an ‘explosion’ would be _any_ of the various specific
            explosion types.

            I would rather say: any of the various specific explosion types is an
            explosion (not the other way round)

            Is this also clear in QuakeML?

            In XML Schema, enumerations are flat, thus the hierarchy is not visible.
            Unfortunately, the fact that a hierarchy exists was not pointed out clearly in
            the standard document of QuakeML. There is a reference to the proposal, which
            was not publicly available at that time.

            For the next version of QuakeML, we plan to provide SKOS ontology descriptions
            for all enumerations (for an early example, see the attached file, concept
            scheme http://quakeml.org/vocab/bedt/1.3/EventType). This is a machine-
            readable representation of the hierarchy which can be expanded with additional
            information, e.g., longer descriptions, links to equivalent concepts in other
            vocabularies, etc.


            It would be good if the ‘event type’ definitions would not only exist as
            part of a data model, but also as a well defined vocabulary

            (see paragraph above)

            Best regards,
            Fabian

            --
            -----------------------------------------------------------------------------
            Fabian Euchner phone +41 44 633 7178
            Institute of Geophysics fax +41 44 633 1065
            ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch
            Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
            8092 Zurich (Switzerland)
            -----------------------------------------------------------------------------
            QuakeML http://quakeml.org QuakePy http://quakepy.org
            CSEP http://www.cseptesting.org/centers/eth
            -----------------------------------------------------------------------------

            Attachments