Use of Date and Time in POIs

[cperey]

During the April 21 POI SWG meeting, we discussed the requirement to have a valid date & time in (or as part of) the POI.

here's a bit of the discussion:

• Valid date and time of what? Feels that having time may be too restrictive
  • valid date and time of POI creation? access? expiration?
  • if it is required, the filed may not be filled (null response)
• is Time a data type?
• what about time intervals?
  • shop hours?
  • existence of something (in the past or future?)?
• should we specify how to express time (as a normative reference to the standard for such purposes?)?
• what about an object that is moving (a food truck, a bus, a train, etc) but is itself a POI (when stopped and when in motion)?

Since none of the use cases to date have captured requirements about time, we agreed that Kyoungsook Kim would provide into the repository a use case from Moving Features to have an example we can generate requirements about.

If I have neglected to include anything, do not hesitate to reply to this issue. Thanks!

[timoruohomaki]

With observations this was covered quite well I guess. In SensorThings, the observation can have the following:

• phenomenonTime as TM_Object
• resultTime as TM_Instant (= timestamp)
• validTime as TM_Period[0..1] (Interesting though that there is no attribute to define in what way the observation is valid - in PoI case it could be opening hours, opening hours of ticket office, doors opening time etc so there could be many). All times defined as ISO 8601 time string or time interval string

Important anyway to keep separate cases where the PoI starts to behave like a sensor and instead cover the temporal needs of the PoI itself

[cperey]

Thank you for sharing your suggestions.

@Chuck Are/do these need to be captured in the POI model?

If they are, then they also need to listed as Normative References.

On Apr 25, 2022, at 11:43 AM, Timo Ruohomaki @.***> wrote:

With observations this was covered quite well I guess. In SensorThings, the observation can have the following:

phenomenonTime as TM_Object resultTime as TM_Instant (= timestamp) validTime as TM_Period[0..1] (Interesting thought that there is no attribute to define in what way the observation is valid - in PoI case it could be opening hours, opening hours of ticket office, doors opening time etc...). All times defined as ISO 8601 time string or time interval string Important anyway to keep separate cases where the PoI starts to behave like a sensor and instead cover the temporal needs of the PoI itself

— Reply to this email directly, view it on GitHub https://github.com/opengeospatial/poi/issues/56#issuecomment-1108336044, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHJKJ7MSN3Y4YJ7UWEUEFDVGZSMRANCNFSM5T7JZSVQ. You are receiving this because you authored the thread.

[timoruohomaki]

I can add this to my use case, it is actually relevant to the construction site case as well.

[dr-shorthair]

Interesting to see you re-using properties from O&M in other applications.

When we were developing O&M we recognised that there are many potentially useful times associated with observations, particularly the 'forecast' kind of observations. The three that were actually included (result, phenomenon, validity) were merely the three most commonly used. In other applications you will probably have other priorities ...

[timoruohomaki]

I don't know how strong the link to O&M actually is, main point anyway is that ISO8601 defines both time and interval and there can be more than one ways what the validity means.

[cperey]

I think the key question can be stated as “does a POI have a Date and Time?” If the answer is yes, then how is it handled?

On Apr 25, 2022, at 2:05 PM, Simon Cox @.***> wrote:

Interesting to see you re-using properties from O&M in other applications.

When we were developing O&M we recognised that there are many potentially useful times associated with observations, particularly the 'forecast' kind of observations. The three that were actually included (result, phenomenon, validity) were merely the three most commonly used. In other applications you will probably have other priorities ...

— Reply to this email directly, view it on GitHub https://github.com/opengeospatial/poi/issues/56#issuecomment-1108484772, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHJKJ2MSIONWA3KFVIXCCDVG2DB7ANCNFSM5T7JZSVQ. You are receiving this because you authored the thread.

[timoruohomaki]

They do, but have to be careful with the scope: PoI can always be associated with an observation or event in order to cover the more complex definitions of time and stay in use case of opening hours. The repeating/recurring intervals can be defined as a string in ISO8601 (or RFC5545), but the implementation is a bit tricky.

The basic use case in opening hours that the PoI is open for public Monday to Friday 9am to 5pm and then Saturdays 9am to 2pm and then there are exceptions on public holidays or other reasons

[cperey]

Open hours is only one requirement for time.

In my opinion, date and time of last update by the publisher is also important (perhaps not a requirement) for services to be able to convey the “freshness” of POIs.

Another use of date and time of POI will be to associated it with:

• anything that moves (discussed during April 21 meeting) or
• anything that has a history or a forecast (e.g., "this is the location of a former or future stationary object - building, utility pole, archeological source/site, etc")

On Apr 25, 2022, at 3:23 PM, Timo Ruohomaki @.***> wrote:

They do, but have to be careful with the scope: PoI can always be associated with an observation or event in order to cover the more complex definitions of time and stay in use case of opening hours. The repeating/recurring intervals can be defined as a string in ISO8601 (or RFC5545), but the implementation is a bit tricky.

The basic use case in opening hours that the PoI is open for public Monday to Friday 9am to 5pm and then Saturdays 9am to 2pm and then there are exceptions on public holidays or other reasons

— Reply to this email directly, view it on GitHub https://github.com/opengeospatial/poi/issues/56#issuecomment-1108567742, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHJKJ3NDI6MPVA2IHVHFHTVG2MFFANCNFSM5T7JZSVQ. You are receiving this because you authored the thread.

[timoruohomaki]

True, in those cases it's not only about time but also the pair of time and location so that the PoI could have a history (and future?) of locations. The potential overlap with the Moving Features is also something to keep in mind since oftentimes when PoI is not rich enough as a model, can always move towards Features.

[chris-little]

@cperey Apologies for only just seeing this.

1. It seems to me that you need to keep a clear distinction between coordinates and attributes. A shop may have attributes of open and closing dates and times which are separate from the POI.
2. Also, coming from a 4D world, I view a POI not fully specified unless there is a time coordinate!
3. Using the same notation (ISO8601) for both categories of times does not help distinguishing them.
4. I prefer a hardline approach and claim that anything in ISO8601 notation (or various restrictive profiles such as IETF RFC 3339) is not really a coordinate like the spatial coordinates, but a calendar entity, which is a temporal reference system (and a cultural construct), analogous to post codes and addresses being spatial reference systems , but not coordinates. Other people, including ISO experts, have spent great effort over many years to establish datetime in ISO8601 notation as a "coordinate". I am not offereing any advice as to which side of that fault line you should aim! It depends on the use cases and preponderance of existing legacy systems. HTH, Chris

[cmheazel]

We need to keep a clear delineation between the POI and the Feature(s) it describes. That means that:

1) the spatial geometry of the POI is a subset of the spatial geometry of the associated Feature(s). 2) the temporal geometry of the POI is independent of the temporal geometry of the associated Feature(s).

The first assertion is obvious. The second less so.

A temporal geometry is a coordinate instance or interval which defines the temporal extent of the POI. The period of time during which this POI is valid. It is a property of the POI instance. It tells you nothing about the associated Features(s).

The associated Features(s) may not be contemporary with the POI. A POI may describe a Feature that existed in the past, will exist in the future, or may never exist at all.

A simple use case - while using your in-car navigation system, you touch the screen and accidentally create a POI for a random location. Rather than have these POIs accumulate, the navigation system deletes them if they are not used within two minutes. So the temporal extent of this POI is from the instance of creation to the instance of deletion (2 minutes).

I'll add the temporal extend as a mandatory property of the POI class.

[howardtrickey]

What if the temporal extent of the POI is "unknown"? Is that a valid value for a temporal extent of a POI? For most of the POIs in my use cases, the temporal extent is indeed unknown (although a subset of the temporal extent may be known).

On Wed, Apr 27, 2022 at 3:56 PM Chuck Heazel @.***> wrote:

We need to keep a clear delineation between the POI and the Feature(s) it describes. That means that:

1. the spatial geometry of the POI is a subset of the spatial geometry of the associated Feature(s).
2. the temporal geometry of the POI is independent of the temporal geometry of the associated Feature(s).

The first assertion is obvious. The second less so.

A temporal geometry is a coordinate instance or interval which defines the temporal extent of the POI. The period of time during which this POI is valid. It is a property of the POI instance. It tells you nothing about the associated Features(s).

The associated Features(s) may not be contemporary with the POI. A POI may describe a Feature that existed in the past, will exist in the future, or may never exist at all.

A simple use case - while using your in-car navigation system, you touch the screen and accidentally create a POI for a random location. Rather than have these POIs accumulate, the navigation system deletes them if they are not used within two minutes. So the temporal extent of this POI is from the instance of creation to the instance of deletion (2 minutes).

I'll add the temporal extend as a mandatory property of the POI class.

— Reply to this email directly, view it on GitHub https://github.com/opengeospatial/poi/issues/56#issuecomment-1111420639, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXMNEVHJDRNDY36LWD4POKTVHGLVDANCNFSM5T7JZSVQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[cmheazel]

I took the liberty of re-using the "AbstractFeatureWithLIfespan" class from CityGML 3.0. I believe it addresses your concerns. I will double check as we fill in the details. Due to the long history of CityGML implementation, I would be surprised if it does not.

[cperey]

This topic discussed on April 28 in POI SWG meeting. Keep open until validating finished (next week or when Chuck updates the model)

[cmheazel]

The temporal attributes in AbstractFeatureWithLifespan are of type DateTime. This type is typically encoded in accordance with ISO 8601. 8601 does not allow you to indicate that a time is anything other than a specific date and a time. However, since these attributes are not required, an unknown date/time can be simply omitted from the POI.

Elsewhere we use the CI_Date class. CI_Date includes a DateType attribute. If DateType = "unavailable", then the value of the "date" attribute should be ignored. An unknown date/time is unavailable.

[howardtrickey]

To me the key question is: is there just one Date and Time or Interval that is so important that it deserves to be a fundamental required property of a POI? If so, what is the meaning of that one Date and Time or Interval?

There are a lot of date/times/intervals that can be associated with a POI:

• creation date/time [Note that very often this will not be known, or not known precisely]
• destruction/closing/ending date/time [Similarly, may not be known or known precisely]
• "open" hours: in general, these can be different for every day of the week or every day of the year (to specify holidays etc) or even every day of the POI's existence, and for each day, in general it will be a sequence of labeled time intervals where each label says what service(s) are available during that time interval

For my use cases, "open" hours is by far the most important of these, but you can see it is much more complicated than just a single time interval.

On Mon, Apr 25, 2022 at 9:00 AM Christine Perey @.***> wrote:

I think the key question can be stated as “does a POI have a Date and Time?” If the answer is yes, then how is it handled?

On Apr 25, 2022, at 2:05 PM, Simon Cox @.***> wrote:

Interesting to see you re-using properties from O&M in other applications.

When we were developing O&M we recognised that there are many potentially useful times associated with observations, particularly the 'forecast' kind of observations. The three that were actually included (result, phenomenon, validity) were merely the three most commonly used. In other applications you will probably have other priorities ...

— Reply to this email directly, view it on GitHub < https://github.com/opengeospatial/poi/issues/56#issuecomment-1108484772>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABHJKJ2MSIONWA3KFVIXCCDVG2DB7ANCNFSM5T7JZSVQ . You are receiving this because you authored the thread.

— Reply to this email directly, view it on GitHub https://github.com/opengeospatial/poi/issues/56#issuecomment-1108538064, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXMNEVFKXS7SQHCGU3MY3C3VG2JPNANCNFSM5T7JZSVQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ronaldtse]

Thank you @cperey for reaching out!

I don't know what exactly I can contribute here except answer questions about 8601 and my personal view on the topic...

As many have pointed out above, there are several uses of date-time in POIs:

• to qualify information validity (potentially be a list of time intervals, recurring or not)
• to record state changes, e.g. physical creation, destruction (can be realized as associated calendar events)
• to indicate associated events, e.g. things happening (can be realized as associated calendar events)
  • the open/closing hours can be realized using calendar events

The few basic things that ISO 8601 describe are (@chris-little 's slide at the Temporal DWG last time should be shared):

• time as time scale units (the unit has a fixed duration)
• time as time intervals (custom duration)
• time as instants (no duration)
• time as specified units on a construct (calendar)

I know @cmheazel is thinking about moving features too. To keep track of motion of the POI would need to encode its motion using frame(s) of reference, which would affect the temporal dimension experienced by the POI subject. Is this a potential use case for POI??

[ronaldtse]

@cmheazel could you elaborate on what this meant?

8601 does not allow you to indicate that a time is anything other than a specific date and a time.

[dr-shorthair]

8601 also supports intervals, and even a limited form of repeating intervals (no gaps though AFAICT).

https://en.wikipedia.org/wiki/ISO_8601#Time_intervals

[cmheazel]

Issue #94 addresses part of this issue. The rest has been addressed by updates to the conceptual model. Recommend to close.

[geofizzydrink]

request Chris Little to review and recommend whether or not to close issue

[chris-little]

I think the discussion above has captured a wide range of issues associated with the temporal aspects of POIs.

I am not sure that any conclusion has been reached, other than that there is a very basic temporal extent associated with the POI coordinate(s), as mentioned by @cmheazel . Whether only a simple instant or extent is allowed, or whether periodic intervals (as mentioned by @dr-shorthair) or other multiple times are allowed perhaps should be determined by POI's approach to spatial coordinates. Are lists of positions, or ranges of locations, allowed, or only a single (x, y, z) position?

Why not stick with the simplest case: one position or extent, and one time instant or extent, for the coordinates, and all the other times are feature attributes? Then generalise as use cases and demands arise.

Over to @cperey for the closing decision! ;-)

(I apologise for not recently having read POI, so my remarks may be unhelpful)

[cperey]

Thank you, @chris-little !

Your proposal to be discussed further here, if possible, and decision agreed to in our next SWG meeting Aug 10.