-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal for flatter GeoJSON-LD Time #13
Comments
I take it a "Open-ended interval with a fuzzy start and end" would have earliest, start, end and latest terms? I'm all for simplicity, and it seems simplest that "when" be handled similarly to "where." And that a "when" object corresponding to "geometry" mimic its structure insofar as possible. For that reason, I don't favor its removal in a flattening. The concept of a 'standard GeoJSON-LD "when object"' and potentially other, more elaborate alternatives seems intuitive: easy to imagine 'are your GeoJSON-LD "when"s vanilla, PeriodO, or Topotime?' Not thrilled with a day referred to as an Instant, since it doesn't correspond well to the most common understandings of that word. But it works as an instruction to a rendering engine, much as "type': "Point" does. A city isn't a point but GeoJSON allows us to direct its rendering as one. A day (or month or year) isn't an Instant, but we're saying render it as one. Following that line of reasoning, I favor including the types MultiInstants and MultiIntervals. We're starting to conflate geo features and events here (which is both great and potentially confusing), as what geo features exist for an instant except events? I want to represent the intermittent existence of the geo-feature "State of Georgia." I grant that geo-reincarnation is not that common outside of admininistrative boundaries, but it is a case and suggests a more complete correspondence with geometry:
After all this, feeling more than ever collections of temporal things (like the PeriodCollection in Topotime) will be a useful alternative perspective on things that have both spatial and temporal extension. Perhaps such a standard can be merged with that for FeatureCollection (GeoJSON) down the road, but more likely to remain a distinctive perspective on spatial-temporal phenomena. |
I really can't get behind Multi- temporal types. From years of designing and critiquing formats for the web, it's clear that usability goes down as the amount of modeling goes up. Modeling a domain exquisitely and modeling it sufficiently are always at odds. GeoJSON has always chosen to be just sufficient, and that's been the key to its success. I suspect that anything more complicated than simple instants and intervals isn't going to take off and that as long as we can show the evolution of Georgia in timelines and maps using just simple instants and intervals, we should. I'm certain we can. |
+1 |
@p3dr0 Can you explain what you mean by having a problem with the types? The fuzziness could be moved to another profile certainly. By profile, I mean a different context for Feature Collections. But too many layers of profiles becomes a burden for adoption and usability. |
by types I mean the "type" element of "when" as defined in time.md "when" : {
"datetime": "2014-04-24",
"type": "Instant"
} I think that we are adding an unnecessary complexity layer with this model I prefer the flat model defined in time-flat.md but only defining a "instant", "start" or "stop" element that is a date-time format (YYYY-MM-DDThh:mm:ss.SSS[+-]hh:mm ) following these rules :
I don't think we have to the "fuzziness" to a another profile as you are able to define it with the existing parameters. |
I see. Start, stop, and instant could describe a fuzzy instant, I agree, but I don't see how they could describe a fuzzy interval. I think that the flat version works really well with JSON-LD because we can write JSON like this:
And the |
I'd prefer to use the nouns for all time objects (instant, start, stop) instead of mixing it with formats/types (e.g. datetime), is this ok for you? Regarding time fuzziness, is this an explicit requirement ? Going that road will lead us to the data quality and validity issues that, while very interesting, should not be considered at this stage. |
@p3dr0 You've persuaded me that "instant" is a better word than "datetime". I'm also willing to split fuzzy time out for now. It's very useful for historical web mappers who have to deal with uncertainty, but I'd be uncomfortable with developers using the fuzzy parameters to indicate precision. So, I'll update time-flat.md and work on making the case to @adoyle :) The flat approach really requires JSON-LD, I think, whereas the other one does not. I'm happy with a JSON-LD requirement and I've guaranteed several times that there will never be a GeoJSON 2.0 ;) |
Once things are flattened, what role to the following context entries have?
If I understand this correctly, these things will never appear in a GeoJSON-LD object so they don't need to be mentioned in the @context section. |
@jyutzler what @sgillies is proposing is that we use the tokens "Interval" and "Instant" on the json-ld @type array |
Show of handsCan you please indicate support for the flatter form by giving flatter gist a star? If you prefer the deeper form, please give deeper gist a star instead. |
@p3dr0 got it thanks. Now to figure out if I can align a moving features effort with this proposal... |
So since our
The above happily passes the JSON-LD Playground's parser. |
@jyutzler More like in 926a4bb, I think. Also, I'm reversing myself on the "datetime" to "instant" switch. Although it's really the URI (http://www.w3.org/2006/time#inXSDDateTime) that's the important thing, having an "instant" and an "Instant" is going to confuse people. |
I don't think we're there yet. How about this:
|
@kgeographer please take a look at #15 and see if this works for you. |
@jyutzler I'm overseas, very intermittent contact and bandwidth for a couple of days, followed by jet lag and catching up with 'real' work stuff no doubt. I'll do my best to ponder and respond soon. Off the top, appears 'official' GeoJSON-LD spec is moving on w/o accommodating my admittedly troublesome use cases for fuzzy history. I will principally focus on the collections of periods (temporal things) that is Topotime and be grateful time is making any appearance in GeoJSON-LD collections of features. Topotime development has definitely benefited from this discussion. |
@sfsheath pointed out something important at #9 (comment): with no "when" object, there's no good way to annotate the temporal information. Where would you put provenance and precision? We'd lose the ability to express more precisely what "when" means in our data. Something like
where you say that "when" in your data means the "lifetime" of a feature (I'm pulling this property out of thin air) wouldn't be possible except by annotation of the Feature object. @adoyle Is this related to your misgivings about flatter JSON? |
@sgillies You can test this for yourself in the playground. The following interprets properly.
If you delete the The thing that I need to confirm is that a JSON-LD parser can determine, let's say, the |
I had the impression no "when" was a done deal. I've expressed support for it multiple times and continue to! ------------------Karl Grossner, Digital Humanities Research DeveloperStanford University LibrariesStanford,CA USwww.kgeographer.org ----- Sean Gillies notifications@github.com wrote:
|
Closing after the show of hands (see #9). |
The time representation from #9 (see examples in time.md) can be flattened significantly with little loss of information. See time-flat.md for examples.
Good? Bad?
The text was updated successfully, but these errors were encountered: