= Request for Comments =

----
'''The RFC process for QuakeML version 1.0.1 has ended by 30 November, 2008. Please do not post further comments on this page. Please send your comments to the QuakeML mailing list at quakeml@mailman.scec.org. It is recommended to [[http://mailman.scec.org/mailman/listinfo/quakeml|sign up]] to the mailing list.
'''
----

== QuakeML Basic Event Description, Version 1.0 ==

The Request for Comments for QuakeML ''Basic Event Description'', Version 1.0, has started on December 14, 2007. 

''Note: There is a bugfix release (Version [[attachment:docs/PR/QuakeML-BED-20080225.pdf|1.0.1]]) which replaces the original version [[attachment:docs/PR/QuakeML-BED-20071213.pdf|1.0]]. Please use version [[attachment:docs/PR/QuakeML-BED-20080225.pdf|1.0.1]] for your evaluation.''

If you would like to comment on a particular element, type, or enumeration, please go to the appropriate Wiki page.

||Event, Origin||[[RFC_BED_1.0_ElementEventOrigin]]||
||Magnitude, Amplitude||[[RFC_BED_1.0_ElementMagnitudeAmplitude]]||
||Moment Tensor, Focal Mechanism||[[RFC_BED_1.0_ElementMomentTensorFocalMechanism]]||
||Pick, Arrival||[[RFC_BED_1.0_ElementPickArrival]]||
||Miscellaneous||[[RFC_BED_1.0_ElementMiscellaneous]]||
||Types||[[RFC_BED_1.0_Types]]||
||Enumerations||[[RFC_BED_1.0_Enumerations]]||

If you would like to give a general comment, please add your text at the bottom of the page.
Please also give your name and the submission date.

(Fabian Euchner)

----

''Note: this contribution refers to a pre-RFC discussion on notifiers/wrappers for the QuakeML root element (FabianEuchner).''

The Notifier structure discussed above is similar to what I envisioned (although I haven't seen the history mechanism and it does not seem to be in version 1.0).  The way that things are currently being implemented in the US, updates are done by transmitting a complete new version of an event and all its related magnitudes, moment tensors, picks, amplitudes, etc.  Because the new event has the same authorID and a higher version number or later creation date-time (in !CreationInfo), it is understood that the new version replaces the old version.  This is relatively easy to implement across our 25 or more contributors (running many different software systems).  Selective updates as described above are conceptually possible, but would be nearly impossible to implement without more standardized software.

However, the notifier system would work well for deleting events, origins, magnitudes, moment tensors, etc.:
{{{
<notifier operation="delete" parentID="ev123"></notifier>
}}}
Might delete delete the event with publicID "ev123" (and everything it contains).

It would also work for overriding the default "business rules".  For example, a regional network in the Central US may be authoritative by default for an earthquake in Southern Illinois, but their location may be poor.  The NEIC could then override this with a better location using a "trump":
{{{
<notifier operation="trump" parentID="ev123"></notifier>
}}}
This would force an event with publicID "ev123" to be preferred.  This may seem like a very indirect way of controlling product distribution, but it allows many cooperating networks to update products in parallel on many different distribution subsystems (e.g., web, email, etc.) without time consuming coordination among them.  That is, it can be done in real-time and it is very robust (i.e., if parts of the Internet are down web servers can still display what is available to them).

For our purposes, it would make sense to include some additional information in the notifier such as who issued the notification and when.  The other issue that is not clear to me is how to decide on a standard.  It is easy to say that notification is outside of QuakeML, but it is still important to have a standard way of updating or deleting products previously sent.

Ray Buland, ''2008-02-05'' (transferred from old trac Wiki by FabianEuchner)

----

An alternate way to do the notification, but without the selective update features would be something like:

'''!QuakemlMessage'''

This class serves as a container for the QuakeML root and has the following attributes:
{{{
publicID	string				1	RI	Attribute
creationInfo	CreationInfo			1	- 	-
action		Action				0..*	-	-
}}}
publicID serves as a message ID for tracking purposes.

creationInfo provides information about who sent the message and when.  Note that this may be different than the author of the information contained.

'''Action (complex type)'''

Action is used to specify actions to be taken on elements of this or previous messages and has the following attributes:
{{{
productID	string				1	RI	Element
type		enum(ActionType)                1	-	-
}}}
productID is the publicID of a QuakeML product.

type is the action to be taken:
{{{
	ActionType (enum)
                update
		delete
		trump
}}}

Ray Buland, ''2008-02-05'' (transferred from old trac Wiki by FabianEuchner)

----

The geospatial community have developed a range of geospatial information models based on ISO framework and its General Feature Model and would encourage the QuakeML community to review its models against these. - Chris Body 5th March 2008


----

I strongly agree with Chris… The use of international standards is important and there already exists agreed upon data exchange standards. You should take a look at the [[http://xml.coverpages.org/ni2008-01-31-a.html|OGC]] initiatives… - Héryk Julien 6th March 2008

----

    *  Why 2 schemas ?

The main argument for having 2 schemas is the possibility to report non-associated picks/arrivals/amplitudes in RT data as a difference with catalog data.
However, in our case, even catalog data can contain only non-associated picks, so we need the possibility to report them.
We think, in order to avoid confusion and parallel developpements, we should only use one schema. The RT schema should answer everyone's needs.

Gilles Mazet-Roux ; EMSC
17/03/2008

----

I think that the problem is within the namespace definition.
Have a look at this link

http://www.xfront.com/ZeroOneOrManyNamespaces.html

Maybe the use of a "Heterogeneous Namespace Design" where the two xsd have a different default namespace could help.
Actually I would like to know if an instance document of QuakeML belongs to the the RT or the BED schema just looking at the namespace of the document. And I dont think that it is possible now, unless you use the xsi namespace to specify those information into your instance document, as described here

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JAXPDOM8.html

The difference in the two approaches is basically the following: force quakeML producers in being responsible in using xsi properly, or providing a proper namespace for each schema.

Alessandro Spinuso ; KNMI-ORFEUS
26/03/2008
----
----