Thread: Re: Further development of the Basic Event Description / event type classification

I think the best option is an extension to the existing Quakeml 1.2
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 <kaestli<at>sed.ethz.ch> wrote:

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.
[...]

From: fdsn-wg3-products<at>lists.fdsn.org [mailto:fdsn-wg3-products@

lists.fdsn.org <fdsn-wg3-products<at>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