Geojson-ld, events

[ekansa]

Sorry to be late to the discussion. I've been trying to follow the comments so far. I've got a specific modeling need to represent different periods of occupation at given archaeological sites. Having a single "when" time interval won't work too well, since there are often long (and important) gaps in occupation. I'm playing with a simple event model to deal with this:

     "id": "#geo-1",
     "type": "Feature",
     "geometry": {
           "id": "#geo-geom-1",
           "type": "Point",
                "coordinates": [
                    40.815164,
                    37.831467
                ]
            },
      "properties": {
            "location-type": "discovey-location"
            },
    "oc-gen:has-events": [
        {
            "id": "#event-1",
            "@type": "oc-gen:formation-use-life",
            "where": "#geo-1",
            "when": {
                "id": "#event-when-1",
                "@type": "Interval",
                "start": -3100,
                "stop": -2900
            }
        },
    {
            "id": "#event-2",
            "@type": "oc-gen:formation-use-life",
            "where": "#geo-1",
            "when": {
                "id": "#event-when-2",
                "@type": "Interval",
                "start": -2000,
                "stop": -1300
            }
        }
    ]

Now, reading up on some of the other issues, I don't want to drag this into a morass of edge-case complexity. I'm not suggesting (unless others thing it useful) to have something like "has-events" in something for wide adoption. But, I'm wondering if we can have a simple bounding box ("tbox") like approach similar to the GeoJSON bounding box ("bbox") that can allow me to communicate very general time information to a wider community, while I express my more idiosyncratic modeling needs with something like 'has-events"?

[ekansa]

Sorry for my not so nice JSON. I'm getting used to using Github for pasting in code.

[kgeographer]

A bbox surrounds elements of multi-geometries within a single feature, but GeoJSON-LD does not propose multiInstant or multiInterval, so there isn't a correspondence (for the record I remain in favor of mimicking geometry this way). Given a single Instant or Interval, its bounds are its tBox, right?

Your event model comes close to accommodating the trajectory example discussed and rejected as a motivating case earlier -- a feature with a set (possibly ordered) of spatial/temporal extents. If your "where" was a "geometry" that would do it.

In principle I like the idea of geo features having associated events with (potentially) distinctive geometries, and periods having associated places with (potentially) distinctive "when" assertions. GeoJSON-LD accommodates "event-like features" as @sgillies has called them; Topotime aims to accommodate "feature-like events/periods." I mention this because it seems symmetric.

So I think periods in a Topotime PeriodCollection will have something like your " oc-gen:has-events " -- "topotime:related-place" perhaps. At the moment this is handled within a "relations": [{ }, { }, ...] object list because many user-specified relations besides "where" are important, such as "contains," "caused," and so on.

[sgillies]

I've factored the temporal bounding box issue out into its own: #19.

[sgillies]

@ekansa That seems like a lot of complexity just to avoid duplication of the geometry and the one property. Myself, I'd just duplicate them. I'm pretty certain that the cost of complexity is generally higher than the cost of duplication in developing information systems.

[ekansa]

@sgillies I'm thinking about your comment. It makes sense, except for the organization of what I've got in my backend, where my events seem to keep things simple. Food for thought...