Consider a new proposal for relationships

[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 looks like 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.