Re: QuakeML 2.0, RfC started for three new packages
Philip Crotwell
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 <
meg...@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...@geophysik.uni-muenchen.de
> _______________________________________________
> fdsn-wg2-data mailing list
> fdsn-w...@iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
>
Tobias Megies
Jeremy Fee
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...@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
> > _______________________________________________
> > Quakeml mailing list
> > Qua...@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
> Qua...@mailman.scec.org
> http://mailman.scec.org/mailman/listinfo/quakeml
>
>
Jeremy Fee
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....@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
> fab...@sed.ethz.ch
> Sonneggstrasse 5
> 8092 Zurich (Switzerland)
>
> -----------------------------------------------------------------------------
> QuakeML http://quakeml.org QuakePy
> http://quakepy.org
> CSEP http://www.cseptesting.org/centers/eth
>
> -----------------------------------------------------------------------------
>
>
Fabien Engels
Hi Jeremy,
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 :)
Philip Crotwell
you push the output files up to github after generating them, you get most
of the benefit.
Philip
Tobias Megies
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
> > > > 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...@geophysik.uni-muenchen.de
> <mailto:tobias...@geophysik.uni-muenchen.de>
> > > _______________________________________________
> > > fdsn-wg2-data mailing list
> > > fdsn-w...@iris.washington.edu
> <mailto:fdsn-w...@iris.washington.edu>
> > > http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
> > >
>
> > _______________________________________________
> > Quakeml mailing list
> > Qua...@mailman.scec.org <mailto:Qua...@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
> Qua...@mailman.scec.org <mailto:Qua...@mailman.scec.org>
> http://mailman.scec.org/mailman/listinfo/quakeml
Fabian Euchner
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
Jeremy Fee
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 <
meg...@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
> >>> --- Fabian Euchner phone +41
> 44
> >>> 633 7178
> >>> Institute of Geophysics fax +41 44
> 633
> >>> 1065
> >>> ETH Zurich, NO F63 e-mail
> >>> fab...@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
cheers,
Tobias
>>> --- Fabian Euchner phone +41 44
>>> 633 7178
>>> Institute of Geophysics fax +41 44 633
>>> 1065
>>> ETH Zurich, NO F63 e-mail
>>> fab...@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
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
> > --- Fabian Euchner phone +41 44
> > 633 7178
> > Institute of Geophysics fax +41 44 633
> > 1065
> > ETH Zurich, NO F63 e-mail
> > fab...@sed.ethz.ch
> > Sonneggstrasse 5
> > 8092 Zurich (Switzerland)
> >
> > --------------------------------------------------------------------------
> > --- QuakeML http://quakeml.org QuakePy
Fabian Euchner
> 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
> 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
--
-----------------------------------------------------------------------------