Allow for ordered lists in TimeSeries for contributors and subevents

[ashepherd]

PROBLEM: Sometimes the order of contributors and subevents may be useful for interpreters to accurately present time series information.

For contributors where there's a bag of PIs, students, etc., it might be useful to allow for a schema.org publisher to present an ordered list of contributors for proper display.

For subevents, it might be useful to order the results as most recent first and using @list could help.

See: https://www.w3.org/TR/json-ld11/#lists

contributor: https://github.com/iodepo/odis-arch/blob/6c98ba757a37eda04010862898b2c6fef446498e/book/thematics/events/graphs/timeSeries.json#L48 subevents: https://github.com/iodepo/odis-arch/blob/6c98ba757a37eda04010862898b2c6fef446498e/book/thematics/events/graphs/timeSeries.json#L53

[fils]

Added the above @list and some other edits in a collab editing session with @ashepherd .

Pull request opened for comment and edits.

[fils]

@pbuttigieg in our current events graph the location section

https://github.com/iodepo/odis-arch/blob/201a41a8b9715e34930e3661c7eae503a244f81b/book/thematics/events/graphs/timeSeries.json#L19-L40

Is using schema.org spatial approaches. Not the geosparql approaches like we have been using and document at https://book.oceaninfohub.org/thematics/spatial/README.html.

Do we want to make the decision to recommend geosparql for spatial?

like

  "spatialCoverage": {
    "@type": "Place",
    "geo": {
      "@type": "GeoCoordinates",
      "latitude": 39.3280,
      "longitude": 120.1633
    }
  }

If so I can update our example to include both approaches.

[fcarvalhopacheco]

Hi all,

Just sharing two links that might be useful for creating the parameters for the timeseries group.

R2R-API R2R-Controlled Vocabularies

[pbuttigieg]

@fils @jmckenna

Do we want to make the decision to recommend geosparql for spatial?

Yes, I believe so. That supports WKT too right ? Our GeoNode partners are good with geosparql ?

[fils]

Following up more on this I see I did a rather odd thing with:

https://github.com/iodepo/odis-arch/blob/6718618b86ea77664379abb4ce6af9b93a211d8a/book/thematics/events/graphs/aloha-event.json#L88-L100

There is no reason to have subevent -> Event -> Action -> Event When I could just do subevent -> Event

Not sure why I did that at all?

Unrelated I spoke with @ashepherd today and he was curious if we review the potential use of https://schema.org/recordedIn rather than https://schema.org/subjectOf as used in the following segment

https://github.com/iodepo/odis-arch/blob/6718618b86ea77664379abb4ce6af9b93a211d8a/book/thematics/events/graphs/aloha-event.json#L44-L53

[fils]

For now we will stick with "subjectOf" and but we will collapse the subevent node path above down to Event under subevent.