-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Background: @sgillies stated that "moving features and feature succession/events should be different efforts." In response, I set up this issue to discuss the concept directly.
As I get more familiar with JSON-LD itself, I think it becomes easier, not harder, to support the gamut of temporal types including MultiInstant and MultiInterval. For example, the following works as a MultiInstant:
{
"@context": {
"Feature": "http://example.com/vocab#Feature",
"Point": "http://example.com/vocab#Point",
"coordinates": "http://example.com/vocab#coordinates",
"geometry": "http://example.com/vocab#geometry",
"id": "http://example.com/vocab#id",
"datetime": "http://www.w3.org/2001/XMLSchema#dateTime",
"MultiInstant": {
"@id": "http://example.com/vocab#MultiInstant",
"@container":"@list",
"@type":"http://www.w3.org/2001/XMLSchema#dateTime"
},
"properties": "http://example.com/vocab#properties",
"type": "http://example.com/vocab#type"
},
"@type": ["Feature", "MultiInstant"],
"geometry": {
"type": "Point",
"coordinates": [
0.0,
0.0
]
},
"MultiInstant": ["2014-04-24", "2014-04-25", "2014-04-26", "2014-04-27"],
"type": "Feature",
"properties": {}
}
This parses correctly in the JSON-LD Playground. A similar approach could be used for MultiInterval. What I can't evaluate is the cost of support for these elements compared to the cost of earliest, latest, start, and stop. It seems to me that the thing for a client to do is evaluate the @type entries - if it supports the type then great; if not it is simply ignored. It looks like an easy way to do core/extensions.
This is what I'm looking for personally because I don't care about Interval but I do care about MultiInstant.