International Federation of Digital Seismograph Networks

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

None
Started: July 21, 2015, 12:40 p.m.
Last activity: Aug. 5, 2015, 4:46 p.m.
Tobias Megies
July 21, 2015, 12:40 p.m.
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

  • Philip Crotwell
    July 21, 2015, 10:32 a.m.
    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


    • Fabien Engels
      July 30, 2015, 11:52 a.m.
      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

      Attachments
      • Jeremy Fee
        July 30, 2015, 10:58 a.m.
        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



        • Fabien Engels
          July 31, 2015, 9:59 a.m.
          On Thu, Jul 30, 2015 at 10:58:57AM -0600, Fee, Jeremy wrote:

          Hi Jeremy,

          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.


          A lot of libraries use Xpath to access elements (Python LXML,
          Javascript, Java, etc). With the current model, there is no way to
          select a preferred object using Xpath, while if you have an attribute
          "preferred", you can simply write :

          origin[@preferred=true]

          Pretty simple and avoid to loop and break or build a dict to get what we
          want :)


          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



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

          Attachments
        • Tobias Megies
          July 31, 2015, 1:59 p.m.
          I agree with Jeremy's last statement. The information of what currently
          is "preferred" has to stay with event. How would you e.g. update when a
          preferred origin changes?
          Remember that these elements don't even have to be in the same file, and
          you would have to chase down any origin that might be connected to the
          event and make sure that preferred flags are removed before adding your
          flag to a different origin.. this is clearly asking for trouble and
          inconsistencies / multiple preferred objects at the same time.
          So I also against such a change.

          cheers,
          Tobias


          On 07/30/2015 06:58 PM, Fee, Jeremy wrote:
          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


          --
          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

      • Fabian Euchner
        Aug. 4, 2015, 5:01 p.m.
        Hi Fabien,

        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.

        by moving "preferred" attributes from event to origin, you would change its
        meaning:

        by having them on event,

        - you make sure that there is only one preferred origin, or magnitude, with
        event. And you say over what these objects are preferred: over alternative
        origins (or magnitudes) *of this event* (it is the event's preferred origin)

        - If preference was an attribute of an origin (which, in BED-RT, does not even
        need to be associated to an event), it becomes just a synonym of "good"
        origin/magnitude, and as multiple of those may be linked to an event,
        interpretation is difficult (e.g.: preferred magnitude "of an event"? "of the
        given type, for this event"? or what?

        Regards,

        Philipp (Kästli) and 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
        -----------------------------------------------------------------------------


  • Fabian Euchner
    July 31, 2015, 2:52 p.m.
    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
    -----------------------------------------------------------------------------

    • Jeremy Fee
      July 31, 2015, 9:16 a.m.
      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

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



      • Philip Crotwell
        July 31, 2015, 11:43 a.m.
        I agree. And even using your tool locally to generate the schema files, if
        you push the output files up to github after generating them, you get most
        of the benefit.

        Philip


        On Fri, Jul 31, 2015 at 11:16 AM, Fee, Jeremy <jmfee<at>usgs.gov> wrote:

        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

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




      • Fabian Euchner
        Aug. 4, 2015, 4:47 p.m.
        Hi Jeremy, hi all,

        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

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

        --
        -----------------------------------------------------------------------------
        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
        -----------------------------------------------------------------------------

        • Tobias Megies
          Aug. 4, 2015, 4:25 p.m.
          Hi Fabian, hi all,


          On 08/04/2015 10:47 AM, Fabian Euchner wrote:
          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.

          I agree that the github wiki is not a good place for discussions.
          However, I don't think that any wiki can ever be a good place to track
          discussions/comments..

          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,

          Well, right now, one has to create an account for quakeml.org. A github
          account on the other hand is useful for many other
          repositories/activities, plus some of us already have one (in fact
          anybody who replied to the QuakeML 2.0 RFC so far already has one). Of
          course any other good social coding platform would be OK for me as well.

          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.

          I agree that the mailing list has to be a place where people can comment
          on whatever concern, easily by email.
          But that's no argument against a good social coding site, I think. Right
          now it's parallel between wiki and mailing list. Could also be parallel
          between a social coding site and 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.

          I don't know much about the commercial Enterprise Architect software you
          are using and I understand that it likely uses proprietary binary
          formats to store the project/data (which can not yield useful diffs). So
          I understand that pull requests won't work well (although diffs on the
          artifacts could still be used to make proposed changes clearer). But
          still I think it's much better to track comments / change proposals via
          the issue tracker, which groups comments by topic and one can easily see
          what comments are new -- or even just whether there was any activity at
          all (as opposed to roaming a wiki).

          I agree with Jeremy and Philip (Crotwell), though, that it would be
          extremely useful to track at least the generated artifacts. As most
          likely nobody outside the core QuakeML dev group has access to the
          master development state (in binary, proprietary formats), and although
          I can see your point that the xsd or any other schema might be only a
          subordinate representation of your data model, having a possibility to
          see diffs on e.g. xsd artifacts is probably the only viable way to make
          development transparent for other people in order to track what's going on.


          I understand that for QuakeML you are focusing on other representations
          than xml. Please keep in mind though that this is the representation
          that is most important for a lot of other people, including distribution
          of event information from data centers to users and for users to quickly
          store these data locally (without the database overhead).

          Please don't get me wrong, right now QuakeML is really useful for the
          whole community. I just would like to see it stay that way also in
          further versions, which could be best insured with a transparent
          development.


          cheers,
          Tobias




          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

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


          --
          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

          • Jeremy Fee
            Aug. 4, 2015, 2:32 p.m.
            Hi,

            I agree a github wiki would be difficult for tracking a discussion, but I
            think github issues would work well. They can also be referenced by
            related issues or commits changing source files, letting users look back at
            both the reasons for a change and how it affected the schema.


            Thanks,

            Jeremy


            On Tue, Aug 4, 2015 at 2:25 PM, Tobias Megies <
            megies<at>geophysik.uni-muenchen.de> wrote:

            Hi Fabian, hi all,


            On 08/04/2015 10:47 AM, Fabian Euchner wrote:
            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.

            I agree that the github wiki is not a good place for discussions.
            However, I don't think that any wiki can ever be a good place to track
            discussions/comments..

            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,

            Well, right now, one has to create an account for quakeml.org. A github
            account on the other hand is useful for many other
            repositories/activities, plus some of us already have one (in fact
            anybody who replied to the QuakeML 2.0 RFC so far already has one). Of
            course any other good social coding platform would be OK for me as well.

            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.

            I agree that the mailing list has to be a place where people can comment
            on whatever concern, easily by email.
            But that's no argument against a good social coding site, I think. Right
            now it's parallel between wiki and mailing list. Could also be parallel
            between a social coding site and 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.

            I don't know much about the commercial Enterprise Architect software you
            are using and I understand that it likely uses proprietary binary
            formats to store the project/data (which can not yield useful diffs). So
            I understand that pull requests won't work well (although diffs on the
            artifacts could still be used to make proposed changes clearer). But
            still I think it's much better to track comments / change proposals via
            the issue tracker, which groups comments by topic and one can easily see
            what comments are new -- or even just whether there was any activity at
            all (as opposed to roaming a wiki).

            I agree with Jeremy and Philip (Crotwell), though, that it would be
            extremely useful to track at least the generated artifacts. As most
            likely nobody outside the core QuakeML dev group has access to the
            master development state (in binary, proprietary formats), and although
            I can see your point that the xsd or any other schema might be only a
            subordinate representation of your data model, having a possibility to
            see diffs on e.g. xsd artifacts is probably the only viable way to make
            development transparent for other people in order to track what's going on.


            I understand that for QuakeML you are focusing on other representations
            than xml. Please keep in mind though that this is the representation
            that is most important for a lot of other people, including distribution
            of event information from data centers to users and for users to quickly
            store these data locally (without the database overhead).

            Please don't get me wrong, right now QuakeML is really useful for the
            whole community. I just would like to see it stay that way also in
            further versions, which could be best insured with a transparent
            development.


            cheers,
            Tobias




            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


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


            --
            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


          • Fabian Euchner
            Aug. 5, 2015, 4:46 p.m.
            Hi Tobias, hi all,

            I agree that the github wiki is not a good place for discussions.
            However, I don't think that any wiki can ever be a good place to track
            discussions/comments..

            I think wikis do a great job just for that. Would you prefer an issue tracker
            like the one of github? They are good for software development, where you have
            very specific bug reports, or feature requests. I would not use them for
            discussions of more general type. (that's probably why github also has a wiki
            component...)

            Any suggestions for another good collaborative tool are welcome!


            Well, right now, one has to create an account for quakeml.org.

            Yes, but we are self-hosted grass-roots project and not a dubious commercial
            company from Silicon Valley...

            A github
            account on the other hand is useful for many other
            repositories/activities, plus some of us already have one (in fact
            anybody who replied to the QuakeML 2.0 RFC so far already has one).

            In my opinion, github can be a convenience add-on, but not a requirement for
            participation in active development.


            Of
            course any other good social coding platform would be OK for me as well.

            We have a self-hosted gitlab instance here at SED. Maybe that would be an
            option. It provides very similar features compared to github. However, I would
            have to investigate how easy it is to move the pages we already created on the
            current wiki. It was quite some work to get all these cross-references right.


            But that's no argument against a good social coding site, I think. Right
            now it's parallel between wiki and mailing list.

            I agree that this duplication is a bit annoying. But I think QuakeML
            development needs to be more "moderated" than modern code development on
            github. Meaning that the QuakeML editors (currently Philipp K. and myself)
            have to keep Wiki and mailing list in balance. This worked for QuakeML
            development so far and I hope it will continue to work.

            I don't know much about the commercial Enterprise Architect software you
            are using and I understand that it likely uses proprietary binary
            formats to store the project/data (which can not yield useful diffs).

            It's not binary, it is XML, but a total mess, mixing model, diagram
            formatting, etc.

            But
            still I think it's much better to track comments / change proposals via
            the issue tracker, which groups comments by topic and one can easily see
            what comments are new

            As said above, I have some doubts whether the issue tracker would be a great
            help here.

            -- or even just whether there was any activity at
            all (as opposed to roaming a wiki).

            Well, you can see that quite clearly on the "RecentChanges" page on the wiki.

            http://quakeml.org/RecentChanges

            Cheers,
            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
            -----------------------------------------------------------------------------