Identifying ways to go

[marcelobianchi]

From the initial meeting I understood that the main points are:

1. Use Network to start out a discussion.
   1.1 My thoughs here was to use NSC (Network station Channel) object relations. There is not much to do with network alone. But yes we can start with network, but naturally this will chain to station and channel.
2. focus on the FDSN source id more than thinking on the SEED ids.

FDSN:<network>_<station>_<location>_<band>_<source>_<subsource>

3. retain "mostly" compatibility with StationXML.
4. have a linkage system that allows for the document to be expanded.
5. take advantage of what we learn from the use of the format=text from the current services.

Other aspects that we tackle on the first meeting:

• tobias: use of global ids to allow the linkage.
• chad: bring the example of the text format from fdsn, that are very handy, but are tricky when network and stations are compared.

In my view the key to this first task is the outer-scope and the object tree and objects relation more than the translation from station-xml to json. From point 3 it is clear that the station xml should be translated mostly as is (as information). Otherwise would make more sense to fix stationxml first, and later move to json.

Is there other views here? I would be glad to hear!

[crotwell]

I think we will need to have at least the concept of a Station in order to explore how the linkage/identification will work. But for now I think it can just be a placeholder, with only code, start and end times.

I have created a few strawman json examples in the wiki that may be useful for thinking about how to proceed. Not as any kind of recommendation, but just to be able to see what some ideas might look like and to have something concrete to throw darts at. Would be good if people would add comments to them if you have ideas, pro or con.

There is also a bit of python code in strawmen folder that I used to generate these. We can modify or add new ones as we come up with ideas. Or use them on other example stationxml to see what it looks like. For example

curl -o "CO_XD.staxml" "https://service.iris.edu/fdsnws/station/1/query?net=CO,XD&station=GOMA,BIRD&level=station&format=xml&includecomments=true&nodata=404"

./mostBasic.py CO_XD.staxml

And yes, I realize it is WAY to early to be writing code, but I find it hard to resist! :)

[crotwell]

Also, I think item 4 includes a "flattening" of the data structure to avoid the hierarchical nature of the current xml.

[marcelobianchi]

Crotwell thank you for the examples.

This one would add too much complexity since it is probably more general than needed.

So far my favorite is ... because of its simple-flexibility.

A though about ids (as we hit it):

• If we stick to fdsn source id there is no versioning of objects, maybe a global JSON id would be desirable, this would allow to save version of same station_epoch?
• Also, fdsn source id do not differentiate station epoch A from B for the same station (same for channel), again maybe a JSON id would be interesting?
• Something that I used in the past (borrow from git ideas) is to hash the complete information package to generate the ID. Objects with different values of any field would end-up having different ids. This is event nicer since the content can be verified from the id by its hash and, same information in any datacenter would have the same ID for the same object.
• The metadata is a tree when we consider the fdsn sourceids and this is not true for any other ID we use! We can send the tree information as a addition to the data in JSON, as an FDSN metadata relation structure.

[SigProSeismology]

I think we will need to have at least the concept of a Station in order to explore how the linkage/identification will work. But for now I think it can just be a placeholder, with only code, start and end times.

I have created a few strawman json examples in the wiki that may be useful for thinking about how to proceed. Not as any kind of recommendation, but just to be able to see what some ideas might look like and to have something concrete to throw darts at. Would be good if people would add comments to them if you have ideas, pro or con.

There is also a bit of python code in strawmen folder that I used to generate these. We can modify or add new ones as we come up with ideas. Or use them on other example stationxml to see what it looks like. For example

curl -o "CO_XD.staxml" "https://service.iris.edu/fdsnws/station/1/query?net=CO,XD&station=GOMA,BIRD&level=station&format=xml&includecomments=true&nodata=404"

./mostBasic.py CO_XD.staxml

And yes, I realize it is WAY to early to be writing code, but I find it hard to resist! :)

Reviewing your draft code, it seems that it has already addressed the following two points:

1- Designing the schema (the structure) for the network level.
2- Transitional mapping of previously allocated temporary network codes.

[ilpint]

Back to the first @marcelobianchi post:

In my view the key to this first task is the outer-scope and the object tree and objects relation more than the translation from station-xml to json. From point 3 it is clear that the station xml should be translated mostly as is (as information). Otherwise would make more sense to fix stationxml first, and later move to json.

In my opinion what is suggested to do for the JSON format could be made analogously in the StationXML format.
It seems to me that using references to the same document or to external documents saving space and adding readability is applicable to StationXML too.
JSON is however a valuable alternative because of the applications available to manage data: NoSQL databases for all.
I don't deny the usefulness of the task, but I believe there is some non technical issue that makes not possible the approach "fix stationxml first, and later move to json".

Is there other views here? I would be glad to hear!

I would like to start a methodological discussion and I will open a new issue for this.

[crotwell]

Added a new strawman, flat with data, meta that may be part way between Marcelo's favorite and the more complicated jsonapi one. Unsure if more structure is better or worse, but may have some advantages. I like grouping other stuff into a meta object.