Extension of OWL-Time for temporal aggregates

[dr-shorthair]

Moving discussion of this topic from #1139 - so far:

@ashepherd commented yesterday Hey folks, there's a group of data repositories interested in publishing a temporal extent that expresses a seasonal coverage across multiple years. Rather, they want to express that data was collected in an aggregate of multiple intervals.

The use case for an extension to OWL-Time for this case is driven by search precision and recall. For example if the data were collected in June, July and August across the years 2012 to 2015, a temporal interval extending from 2012 to 2015 would hit as a match for a search looking for data between January 2013 and May 2013 which would be wrong in this case.

In discussions with @dr-shorthair , he recommended a small extension of one class and one property:

time:TemporalAggregate rdf:subClassOf time:TemporalEntity .

time:hasMember a owl:ObjectProperty;
                rdfs:domain time:TemporalAggregate ;
                rdfs:range time:TemporalEntity . 

With this aggregate class, we can express a collection of Temporal entities that explicitly describes the collection activity.

Thoughts?

@dr-shorthair commented yesterday • @ashepherd I'm inclined to make this a separate note to [the one in #1139] - rather different scope. Wouldn't want one to hold up the other and get conversations too tangled. OTOH we could start by rolling them together and split them only if necessary.

@kjano commented 20 hours ago Hi Adam,

Just one brief comment. The solution below would not preserve the order of the aggregates directly (e.g., compared to a list).

Best, Jano …

@ashepherd commented 17 hours ago Hi Jano, I haven’t used OWL-Time extensively. Do you a see a situation where the order would be useful to explicitly state so as not to rely on sorting the date/time values themselves?

Cheers, Adam …

@elf-pavlik commented 8 hours ago @ashepherd I'm inclined to make this a separate note to the one on this issue - rather different scope. Wouldn't want one to hold up the other and get conversations too tangled.

👍 while [#1139] just fills in some missing relations which don't imply time:ProperInterval, mentioned time:TemporalAggregate sounds like a new feature which can have independent note and process of working on it

[dr-shorthair]

@kjano : ordering is already handled by the existing interval* relations. I think the philosophy of OWL-Time is to handle ordering explicitly rather than implicitly (e.g. using a list).

The gap here is that there is no structure for aggregates of temporal entities. I caught @ashepherd trying to use time:intervalContains for aggregation (it is designed to support ordering, which is a different thing). That highlighted the gap, which this proposal is aimed to fill in a very basic way.

[dr-shorthair]

See example in the draft spec. The topological relations between the parts are explicit, using time:intervalAfter.

[dr-shorthair]

Proposal to progress #1173