Skip to content

Consider a new proposal for relationships #7

@marcelobianchi

Description

@marcelobianchi

Examining both cases proposed by @crotwell given at:

  1. https://github.com/FDSN/JSON-metadata/wiki/Strawmen-Relationship#generic-relationships-with-type-included
  2. https://github.com/FDSN/JSON-metadata/wiki/Strawmen-Relationship#type-specific-station-with-type-implied-by-field

For me 1. is too verbose, and of course can create larger documents. Option 2. creates a "station" attribute to "Network" that ressample as the current tree.

How about mixing both:

{
  "@context": {
    "name": "http://fdsn.org"
  },
  "meta": {
    "source": "IRIS-DMC",
    "sender": "IRIS-DMC",
    "module": "IRIS WEB SERVICE: fdsnws-station | version: 1.1.52",
    "moduleUri": "https://service.iris.edu/fdsnws/station/1/query?net=CO,XD&level=station&format=xml&includecomments=true&nodata=404",
    "created": "2025-10-07T18:34:27.8731"
  },
  "data": [
    {
      "@type": "network",
      "@id": "FDSN:CO@1987-01-01T00:00:00.0000/3",
      "data": {
        "sourceid": "FDSN:CO",
        "restrictedStatus": "open",
        "startDate": "1987-01-01T00:00:00.0000",
        "description": "South Carolina Seismic Network (SCSN)",
        "identifier": {
          "type": "DOI",
          "id": "10.7914/SN/CO"
        }
      },
      "meta": {
        "pubVersion": "3",
        "otherNS": "stuff here",
        "totalNumberStations": "19",
        "selectedNumberStations": "19"
      },
      "relationships" : {
        {
          "@type": "station",
          "@ids": [
            "FDSN:CO_ADSC@2012-10-08T00:00:00.0000/4",
            "FDSN:CO_BARN@2021-12-31T00:00:00.0000/4",
            "FDSN:CO_BELLE@2025-01-17T00:00:00.0000/4",
            "FDSN:CO_BIRD@2010-08-25T00:00:00.0000/4",
            "FDSN:CO_C1SC@2012-10-08T19:00:00.0000/4",
            "FDSN:CO_C2SC@2012-10-08T00:00:00.0000/4",
            "FDSN:CO_CASEE@2009-12-07T00:00:00.0000/4",
            "FDSN:CO_CSB@2009-04-13T00:00:00.0000/4",
            "FDSN:CO_HAW@2010-03-11T00:00:00.0000/4",
            "FDSN:CO_HODGE@2010-03-25T00:00:00.0000/4",
            "FDSN:CO_JKYD@2022-10-18T00:00:00.0000/4",
            "FDSN:CO_JSC@2009-04-13T00:00:00.0000/4",
            "FDSN:CO_MONT@2021-11-04T00:00:00.0000/4",
            "FDSN:CO_PARR@2023-11-28T00:00:00.0000/4",
            "FDSN:CO_PAULI@2011-04-26T00:00:00.0000/4",
            "FDSN:CO_RGR@2009-04-13T00:00:00.0000/4",
            "FDSN:CO_SUMMV@2015-04-21T00:00:00.0000/4",
            "FDSN:CO_TEEBA@2018-04-25T00:00:00.0000/4",
            "FDSN:CO_TRSC@2012-10-08T00:00:00.0000/4"
          ]
        }
      }
      _...  (another network) ..._ 
  ]
}

A final comment, is that the last example show, using a top-level element to send relation ships does not make sense to me. Any service, serving the JSON object could sent it value-less (or dataless, i.e. removing the data object), and the standard object would ressample the top-level object proposed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions