Re: Further development of the Basic Event Description / event type classification
Jeremy Fee
specification. New attributes and values can be added in a new namespace,
and those attributes can be added to the existing event type element to
provide more specific information where it is known. This provides a
simpler implementation path for many existing users and documents.
Thanks,
Jeremy
On Thu, Aug 4, 2016 at 8:35 AM, Kästli Philipp <kae...@sed.ethz.ch> wrote:
> > On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thompson <thom...@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.
> [...]
>
> > From: fdsn-wg3...@lists.fdsn.org [mailto:fdsn-wg3-products@
> lists.fdsn.org <fdsn-wg3...@lists.fdsn.org>] On Behalf Of Jeremy Fee
> > Sent: Freitag, 22. Juli 2016 00:03
> > To: FDSN Working Group III
> > Subject: Re: [fdsn-wg3-products] fdsnws-event - add support for event
> type in query and text format
>
> > We're having similar discussions over more specific landslide event
> types.
> [...]
>
> Hi,
>
> i am cross-posting this form FDSN-WG3 to the QuakeML mailing list, as the
> FDSN event web service refers to QuakeML Basic Event Description (BED) 1.2
> as response format and thus to the quakeml enumeration of event types.
>
> As Dimitry and Fabian correctly pointed out on the FDSN-WG3 mailing list,
> the current QuakeML BED reflects a draft of the Storchak et al.
> (EMSC-ISC-NEIC coordination, attached) proposal for an Nomenclature of
> Event Types. I am not sure whether it is also a IASPEI standard, as i have
> not found it IASPEI web page (or any other online resource).
>
> Given the technical shortcomings of the QuakeML 1.2 event type enumeration
> (no machine-readable definition of inter-term hierarchy or other
> relations), we proposed to use an SKOS onthology for QuakeML 2.0ff terms. A
> draft implementation, using the QuakeML BED 1.2 terms, has been prepared by
> Fabian and is attached.
>
> For next-generation QuakeML, there are two reasons not only to review the
> representation of the given type list, but also the list itself:
> - as visible from the mail citations above, some communities feel their
> event types badly covered with the current list
> - there are some points worth being discussed in the current list. e.g.:
> a) some terms are represented as mutually exclusive, but are not. e.g.
> accidental explosion vs. chemical explosion. b) some mix cause and
> phenomenon. e.g. rock burst (a seismically recordable event) vs. fluid
> injection (a cause of seismically recordable events). c) having
> “anthropogenic” (cause) as top level classification disallows for telling
> about the nature of these events (e.g., earthquakes vs rockfalls or
> avalanches) while it disallows for events with defined nature (e.g.,
> rockfall, sonic boom,) to flag them as anthropogenic.
>
> So, it may be worth considering, for a next version of QuakeML BED, not
> only to adopt a SKOS representation of the EMSC-ISC-NEIC classification,
> but also to reconsider it content-wise.
>
> For the further modelling of event type (as well as many other
> classifications in QuakeML), we have two options:
>
> 1. introduce an QuakeML inherent ontology, and make it mandatory for the
> event type classification. Thus, users exactly know which classification to
> expect in which version of the QuakeML package. However
> extension/modification is not straight forward, or it requires a new
> version of the format.
> 2. give two fields to define event type: the type term itself, as well as
> the ontology used. While the standard may still recommend the use of one
> specific ontology, users are free to use, for specific purposes, other
> ontologies, and the resulting files still remain fully defined and
> machine-readable. This also allows updating/replacement of an ontology
> without the QuakeML format version to change, and changes in the xml format
> version without mandatory reclassification of event types.
>
> What is your opinion/your preference on this?
>
>
>
> Best regards, Philipp
>
>
>