Thread: Re: QuakeML 2.0, RfC started for three new packages

Hello,

1/

Currently there is one thing I would like to see elvolving in QuakeML,
this is how preferred objects are managed. I think "preferred*" tags
should be removed from Event object to be moved to a "preferred" boolean
attribute in the target tag, not sure to be clear so a little example :
<Origin preferred="true">
...
</Origin>

I generally prefer attributes for simple values, and to carry this idea
further most resourceID references could be moved to be attributes of the
parent element; for example triggeringOriginID.

However, whether an origin is preferred seems like it depends on the
context of an event. An origin may be preferred by one contributor when it
is originally contributed, but once other origin's are available it may or
may not remain preferred. Additionally, a significant amount of code has
been written around quakeml 1.2 and this will break backward
compatibility. For these reasons, I prefer to keep the "preferred*" tags
as part of the Event.


It'll make easier to filter a catalog to keep only preferred objects

(for our case, 90% of our usage) with standard XML tools but also with
various database implementations (as long they are based on QuakeML
standard). The only caveat I see so far, I'm not sure you case use
RelaxNG or XSD to be sure there is only one preferred object by tag
types.

Do you have a specific XML tool in mind you are trying to support? We
filter for preferred information as well, but need to parse the entire
document because of how resource identifiers link between elements.

2/

To follow Tobias about a contribution platform, I suggest to experiment
GitHub. The latter is good for code contribution but some people start
to use it for other kind of project, it could fit well to QuakeML needs.
To be able to do a git log on QuakeML specifications repository could be
awesome IMO.
I agree with Philipp, the SSL warning is quite scray for most people :)

I fully support moving to Github, it's an excellent collaborative
environment. That is where we keep our extensions to quakeml:

https://github.com/usgs/eqmessageutils



Thanks,

Jeremy


On Thu, Jul 30, 2015 at 3:52 AM, Fabien Engels <fabien.engels<at>unistra.fr>
wrote:

Hi colleagues,

1/
Currently there is one thing I would like to see elvolving in QuakeML,
this is how preferred objects are managed. I think "preferred*" tags
should be removed from Event object to be moved to a "preferred" boolean
attribute in the target tag, not sure to be clear so a little example :

<Origin preferred="true">
...
</Origin>

It'll make easier to filter a catalog to keep only preferred objects
(for our case, 90% of our usage) with standard XML tools but also with
various database implementations (as long they are based on QuakeML
standard). The only caveat I see so far, I'm not sure you case use
RelaxNG or XSD to be sure there is only one preferred object by tag
types.

2/
To follow Tobias about a contribution platform, I suggest to experiment
GitHub. The latter is good for code contribution but some people start
to use it for other kind of project, it could fit well to QuakeML needs.
To be able to do a git log on QuakeML specifications repository could be
awesome IMO.

I agree with Philipp, the SSL warning is quite scray for most people :)

3/
One more time I follow Tobias point of view, I think we should avoid
overlap and redundancies between QuakeML and StationXML. It's
already difficult to make people adopt a standard :/

As in Strasbourg, we are really happy to see standards defined by the
community and using QuakeML for years, I hope I wasn't too critical :)

Thanks
Fabien


On Tue, Jul 21, 2015 at 10:32:31AM -0400, Philip Crotwell wrote:

Hi

I agree, and would just add that the expired, self-signed ssl certificate
is a further hindrance to outside involvement. Most browsers put up a

scary

warning message when they encounter this, and this is easily enough of a
roadblock to cause people to say it just isn't worth the effort to be
involved.

thanks
Philip

On Tue, Jul 21, 2015 at 6:40 AM, Tobias Megies <
megies<at>geophysik.uni-muenchen.de> wrote:

Hi Fabian, hi Philipp,

good to see that development of QuakeML is still active! However, I

have

some critical comments:

A) I find it extremely hard to keep track of changes introduced in
recent times. You mention bugfixes and clean-up to elements of QuakeML
1.2.. where can I find a list of changes?

B) Is the version control system to keep track of changes publicly
visible somewhere? I would strongly encourage to have some sort of
schema file (probably rather RelaxNG than XSD, see earlier problems

with

validation using the xsd) publicly visible where changes can be
reviewed. Having possible comments spread out over the large amount of
single wiki pages makes it close to impossible to keep track of

comments

by other people and, in my opinion, thus discourages contributions from
other people.
Having some schema definition file at an open source version control /
code hosting site with possibilities for commenting and change requests
is the way to go, I think.

C) Some of the proposed additions are of "station type" and are
partially already covered in StationXML (albeit probably in a less fine
grained manner in some cases, e.g. only having a simple string field

for

station geology).
Right now (QuakeML 1.2) the only link from any event type information

to

station type information is via WaveformStreamID
(network/station/location/channel code) and the timestamp of the
corresponding element (e.g. Pick). Which is a very minimalistic and

thus

very practicable and simple way of linking event and station

information.

If now QuakeML is to be extended to cover station metadata as well, I
think this will make future handling of event and station metadata much
more complicated for researchers and data centers alike.
Why not work on extending the level of detail for station metadata
directly at StationXML development and rather work on improving the
linking between QuakeML and StationxML via some URI referencing

attributes?

Take e.g. SiteCharacterization and StationCharacterization, why not
propose extensions to the corresponding StationXML elements and link
between QuakeML and StationXML via URIs (or the current way of relying
on SEED ID and timestamp)?


I hope you're not getting me wrong with the partial criticism. It's

just

that QuakeML and StationXML have developed into the generally accepted
standards for event and station metadata, respectively, which in my
opinion is the best thing that has happened in recent years in terms of
international data exchange. I just hope that development on both can
stay/evolve into a community effort, and that development is/will be
well coordinated between the two, for the sake of the whole seismo
community.


best regards,
Tobias


P.S.: I'm CCing the FDSN WG2 mailing list, because I feel that this
equally concerns everybody working with station metadata.


On 07/14/2015 09:02 AM, Fabian Euchner wrote:

Dear colleagues,

at quakeml.org, you can find now information on the new version 2.0,

which is

under development.

Main features of the new proposed version are:

- Bugfix and clean-up version of Basic Event Description (new version

number

1.3)

- Separation of domain-overarching data types into auxiliary schemas

(Common,

ResourceMetadata, etc.)

- Simple Knowledge Organization System (SKOS) description for

vocabularies,

thus introducing semantic relations (hierarchy)

- Additional, peer-reviewed proposals for new packages, carrying

QuakeML

data

modelling paradigms to new topics such as station characterization,

site

characterization, strong motion records, and others.

Please see the Wiki pages at quakeml.org/QuakeML2.0 . There
are several new packages that are collected under the common QuakeML

2.0

umbrella.

Three of the packages, SiteCharacterization,

StationCharacterization, and

StrongMotion, are sufficiently mature, so that we would like to

start a

Request for Comments process for these, We created a RfC section on

the

Wiki

at quakeml.org/QuakeML2.0RFC . Please add your comments there, or

post

them to

the mailing list.

You will note that the online documentation is still quite sparse. We

will

improve that during the next weeks.

Best regards,
Fabian and Philipp

--
Dipl.-Geophys. Tobias Megies

Geophysikalisches Observatorium
Ludwigshöhe 8
82256 Fürstenfeldbruck

Ludwig-Maximilians-Universität
Department für Geo- und Umweltwissenschaften
Sektion Geophysik
Theresienstrasse 41/IV
80333 München

Tel: +49 (0) 89 2180-73981
+49 (0) 89 2180-4326
Mail: tobias.megies<at>geophysik.uni-muenchen.de
_______________________________________________
fdsn-wg2-data mailing list
fdsn-wg2-data<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

_______________________________________________
Quakeml mailing list
Quakeml<at>mailman.scec.org
http://mailman.scec.org/mailman/listinfo/quakeml

--
Fabien Engels
École et Observatoire des Sciences de la Terre
Bureau : +33 368850056
Mobile : +33 612529246

_______________________________________________
Quakeml mailing list
Quakeml<at>mailman.scec.org
http://mailman.scec.org/mailman/listinfo/quakeml

Hello,

1/
Currently there is one thing I would like to see elvolving in QuakeML,
this is how preferred objects are managed. I think "preferred*" tags
should be removed from Event object to be moved to a "preferred" boolean
attribute in the target tag, not sure to be clear so a little example :
<Origin preferred="true">
...
</Origin>


I generally prefer attributes for simple values, and to carry this idea
further most resourceID references could be moved to be attributes of
the parent element; for example triggeringOriginID.

However, whether an origin is preferred seems like it depends on the
context of an event. An origin may be preferred by one contributor when
it is originally contributed, but once other origin's are available it
may or may not remain preferred. Additionally, a significant amount of
code has been written around quakeml 1.2 and this will break backward
compatibility. For these reasons, I prefer to keep the "preferred*"
tags as part of the Event.


It'll make easier to filter a catalog to keep only preferred objects
(for our case, 90% of our usage) with standard XML tools but also with
various database implementations (as long they are based on QuakeML
standard). The only caveat I see so far, I'm not sure you case use
RelaxNG or XSD to be sure there is only one preferred object by tag
types.


Do you have a specific XML tool in mind you are trying to support? We
filter for preferred information as well, but need to parse the entire
document because of how resource identifiers link between elements.


2/
To follow Tobias about a contribution platform, I suggest to experiment
GitHub. The latter is good for code contribution but some people start
to use it for other kind of project, it could fit well to QuakeML needs.
To be able to do a git log on QuakeML specifications repository could be
awesome IMO.
I agree with Philipp, the SSL warning is quite scray for most people :)


I fully support moving to Github, it's an excellent collaborative
environment. That is where we keep our extensions to quakeml:

https://github.com/usgs/eqmessageutils



Thanks,

Jeremy


On Thu, Jul 30, 2015 at 3:52 AM, Fabien Engels <fabien.engels<at>unistra.fr
<fabien.engels<at>unistra.fr>> wrote:

Hi colleagues,

1/
Currently there is one thing I would like to see elvolving in QuakeML,
this is how preferred objects are managed. I think "preferred*" tags
should be removed from Event object to be moved to a "preferred" boolean
attribute in the target tag, not sure to be clear so a little example :

<Origin preferred="true">
...
</Origin>

It'll make easier to filter a catalog to keep only preferred objects
(for our case, 90% of our usage) with standard XML tools but also with
various database implementations (as long they are based on QuakeML
standard). The only caveat I see so far, I'm not sure you case use
RelaxNG or XSD to be sure there is only one preferred object by tag
types.

2/
To follow Tobias about a contribution platform, I suggest to experiment
GitHub. The latter is good for code contribution but some people start
to use it for other kind of project, it could fit well to QuakeML needs.
To be able to do a git log on QuakeML specifications repository could be
awesome IMO.

I agree with Philipp, the SSL warning is quite scray for most people :)

3/
One more time I follow Tobias point of view, I think we should avoid
overlap and redundancies between QuakeML and StationXML. It's
already difficult to make people adopt a standard :/

As in Strasbourg, we are really happy to see standards defined by the
community and using QuakeML for years, I hope I wasn't too critical :)

Thanks
Fabien


On Tue, Jul 21, 2015 at 10:32:31AM -0400, Philip Crotwell wrote:

Hi

I agree, and would just add that the expired, self-signed ssl certificate
is a further hindrance to outside involvement. Most browsers put up a scary
warning message when they encounter this, and this is easily enough of a
roadblock to cause people to say it just isn't worth the effort to be
involved.

thanks
Philip

On Tue, Jul 21, 2015 at 6:40 AM, Tobias Megies <
megies<at>geophysik.uni-muenchen.de

<megies<at>geophysik.uni-muenchen.de>> wrote:

Hi Fabian, hi Philipp,

good to see that development of QuakeML is still active!

However, I have

some critical comments:

A) I find it extremely hard to keep track of changes introduced in
recent times. You mention bugfixes and clean-up to elements of

QuakeML

1.2.. where can I find a list of changes?

B) Is the version control system to keep track of changes publicly
visible somewhere? I would strongly encourage to have some sort of
schema file (probably rather RelaxNG than XSD, see earlier

problems with

validation using the xsd) publicly visible where changes can be
reviewed. Having possible comments spread out over the large

amount of

single wiki pages makes it close to impossible to keep track of

comments

by other people and, in my opinion, thus discourages

contributions from

other people.
Having some schema definition file at an open source version

control /

code hosting site with possibilities for commenting and change

requests

is the way to go, I think.

C) Some of the proposed additions are of "station type" and are
partially already covered in StationXML (albeit probably in a

less fine

grained manner in some cases, e.g. only having a simple string

field for

station geology).
Right now (QuakeML 1.2) the only link from any event type

information to

station type information is via WaveformStreamID
(network/station/location/channel code) and the timestamp of the
corresponding element (e.g. Pick). Which is a very minimalistic

and thus

very practicable and simple way of linking event and station

information.

If now QuakeML is to be extended to cover station metadata as

well, I

think this will make future handling of event and station

metadata much

more complicated for researchers and data centers alike.
Why not work on extending the level of detail for station metadata
directly at StationXML development and rather work on improving the
linking between QuakeML and StationxML via some URI referencing

attributes?

Take e.g. SiteCharacterization and StationCharacterization, why not
propose extensions to the corresponding StationXML elements and link
between QuakeML and StationXML via URIs (or the current way of

relying

on SEED ID and timestamp)?


I hope you're not getting me wrong with the partial criticism.

It's just

that QuakeML and StationXML have developed into the generally

accepted

standards for event and station metadata, respectively, which in my
opinion is the best thing that has happened in recent years in

terms of

international data exchange. I just hope that development on

both can

stay/evolve into a community effort, and that development is/will be
well coordinated between the two, for the sake of the whole seismo
community.


best regards,
Tobias


P.S.: I'm CCing the FDSN WG2 mailing list, because I feel that this
equally concerns everybody working with station metadata.


On 07/14/2015 09:02 AM, Fabian Euchner wrote:

Dear colleagues,

at quakeml.org http://quakeml.org, you can find now

information on the new version 2.0,

which is

under development.

Main features of the new proposed version are:

- Bugfix and clean-up version of Basic Event Description (new version

number

1.3)

- Separation of domain-overarching data types into auxiliary schemas

(Common,

ResourceMetadata, etc.)

- Simple Knowledge Organization System (SKOS) description for

vocabularies,

thus introducing semantic relations (hierarchy)

- Additional, peer-reviewed proposals for new packages, carrying QuakeML

data

modelling paradigms to new topics such as station characterization, site
characterization, strong motion records, and others.

Please see the Wiki pages at quakeml.org/QuakeML2.0

http://quakeml.org/QuakeML2.0 . There

are several new packages that are collected under the common QuakeML 2.0
umbrella.

Three of the packages, SiteCharacterization, StationCharacterization, and
StrongMotion, are sufficiently mature, so that we would like to start a
Request for Comments process for these, We created a RfC section on the

Wiki

at quakeml.org/QuakeML2.0RFC

http://quakeml.org/QuakeML2.0RFC . Please add your comments there,
or post

them to

the mailing list.

You will note that the online documentation is still quite sparse. We

will

improve that during the next weeks.

Best regards,
Fabian and Philipp

--
Dipl.-Geophys. Tobias Megies

Geophysikalisches Observatorium
Ludwigshöhe 8
82256 Fürstenfeldbruck

Ludwig-Maximilians-Universität
Department für Geo- und Umweltwissenschaften
Sektion Geophysik
Theresienstrasse 41/IV
80333 München

Tel: +49 (0) 89 2180-73981
+49 (0) 89 2180-4326
Mail: tobias.megies<at>geophysik.uni-muenchen.de

<tobias.megies<at>geophysik.uni-muenchen.de>

_______________________________________________
fdsn-wg2-data mailing list
fdsn-wg2-data<at>iris.washington.edu

<fdsn-wg2-data<at>iris.washington.edu>

http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

_______________________________________________
Quakeml mailing list
Quakeml<at>mailman.scec.org <Quakeml<at>mailman.scec.org>
http://mailman.scec.org/mailman/listinfo/quakeml

--
Fabien Engels
École et Observatoire des Sciences de la Terre
Bureau : +33 368850056
Mobile : +33 612529246

_______________________________________________
Quakeml mailing list
Quakeml<at>mailman.scec.org <Quakeml<at>mailman.scec.org>
http://mailman.scec.org/mailman/listinfo/quakeml





_______________________________________________
fdsn-wg2-data mailing list
fdsn-wg2-data<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

I agree that it would be nice to have the schemas on github, and benefit from
the fine-grained versioning, history, and diff mechanisms. Also the comments
per code line could be useful.

I would like, however, to keep discussion on the existing QuakeML wiki, and
not mix it with the github wiki.

Furthermore, I'm not sure whether it's a good
idea to use the github issue tracker. It would require people who want to
contribute to sign up for a github account,

and to become familiar with the
complexity of github (which could be somewhat scaring for people who are not
that familiar with coding and code hosting platforms). I would prefer to have
issues still reported on the mailing list.

Furthermore, it is pretty obvious that we cannot use the "pull request"
mechanism (which is the killer feature of github) in a useful way.

Any other opinions on this?

Best regards,
Fabian

Github can version binary files and would provide a useful history for all
the generated artifacts. It also provides a wiki, issue tracking, and
hosted pages for other static content ( https://pages.github.com/ ). Even
without being able to merge separate contributions to the enterprise
architect file(s), this seems like the way to go.


Thanks,

Jeremy



On Fri, Jul 31, 2015 at 6:52 AM, Fabian Euchner <fabian.euchner<at>sed.ethz.ch>
wrote:

Hi Tobias, hi all,

first of all, sorry for the long silence from the QuakeML team at ETH.
There
were some technical difficulties with the mailing list which resulted in
some
of the subscribers (including ourselves at ETH) not receiving the list
mails.
We hope that now, after the move to a new list server, everybody receives
all
list postings.

A) I find it extremely hard to keep track of changes introduced in
recent times. You mention bugfixes and clean-up to elements of QuakeML
1.2.. where can I find a list of changes?

At the moment we don't have such a list. I agree that it's difficult to
see
the differences and we will work on a solution. A simple "diff" on the
XSDs is
somewhat misleading because a lot of stuff from the old XSD has been moved
to
the new BasicEventDescriptionTypes package.

B) Is the version control system to keep track of changes publicly
visible somewhere? I would strongly encourage to have some sort of
schema file (probably rather RelaxNG than XSD, see earlier problems with
validation using the xsd)

RelaxNG: we are working on this, will be created by our automatic schema
creator soon.

publicly visible where changes can be
reviewed. Having possible comments spread out over the large amount of
single wiki pages makes it close to impossible to keep track of comments
by other people and, in my opinion, thus discourages contributions from
other people.

I agree that the presentation is not clearly arranged at the moment, but
this
is difficult to do given the amount of information we have now in all of
the
packages. Ideas for a better presentation are very welcome!

Having some schema definition file at an open source version control /
code hosting site with possibilities for commenting and change requests
is the way to go, I think.

There have been several suggestions to use github for managing the
schemas.
Personally, I like github a lot. It's a great tool and I use it in some of
the
projects I'm working on. However, we cannot integrate it in the workflow
we
use at the moment at ETH for schema management. This is because the
"master"
resources we are editing are not the XSD files. We use Enterprise
Architect, a
UML modelling tool, and the files we are working on are XML serialisations
of
the UML class diagrams per package. Unfortunately, these files cannot be
edited collaboratively in a merge model. We have them in Subversion, but
have
to use locking mode and exclusive editing. I think there is no way around
this, I'm not aware that Enterprise Architect would support a merge model.

The reason why we use the UML class diagram as the "master" model is that
we
run an automatic schema generator on these files that creates XSD, RelaxNG
(upcoming, has to be fixed), SQL schema, SKOS, and Python class stubs, and
by
editing only the "master" we can ensure that there are no contradictions
(caused by typos, sloppy editing, forgotten elements, etc.) in all of the
other representations of the data model. And we save a lot of work using
this
approach. Imagine all the XSDs, RelaxNGs, etc. would be edited separately
by
hand... this would be close to impossible.

C) Some of the proposed additions are of "station type" and are
partially already covered in StationXML (albeit probably in a less fine
grained manner in some cases, e.g. only having a simple string field for
station geology).
Right now (QuakeML 1.2) the only link from any event type information to
station type information is via WaveformStreamID
(network/station/location/channel code) and the timestamp of the
corresponding element (e.g. Pick). Which is a very minimalistic and thus
very practicable and simple way of linking event and station
information.
If now QuakeML is to be extended to cover station metadata as well, I
think this will make future handling of event and station metadata much
more complicated for researchers and data centers alike.
Why not work on extending the level of detail for station metadata
directly at StationXML development and rather work on improving the
linking between QuakeML and StationxML via some URI referencing

attributes?

Take e.g. SiteCharacterization and StationCharacterization, why not
propose extensions to the corresponding StationXML elements and link
between QuakeML and StationXML via URIs (or the current way of relying
on SEED ID and timestamp)?

The QuakeML approach for this would be to have something like StationXML
in a
separate package (QuakeML-Inventory or similar), and use the
ResourceReferences of QuakeML to link between objects.

Best regards,
Fabian

--

--------------------------------------------------------------------------
--- Fabian Euchner phone +41 44
633 7178
Institute of Geophysics fax +41 44 633
1065
ETH Zurich, NO F63 e-mail
fabian<at>sed.ethz.ch
Sonneggstrasse 5
8092 Zurich (Switzerland)

--------------------------------------------------------------------------
--- QuakeML http://quakeml.org QuakePy
http://quakepy.org
CSEP http://www.cseptesting.org/centers/eth

--------------------------------------------------------------------------
---