W3C home > Mailing lists > Public > public-sdw-wg@w3.org > August 2015

RE: ISSUE 14: temporal reasoning and relations

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Mon, 10 Aug 2015 13:07:07 +0000
To: Kerry Taylor <Kerry.Taylor@acm.org>, "<Simon.Cox@csiro.au>" <Simon.Cox@csiro.au>
Cc: "<karlg@stanford.edu>" <karlg@stanford.edu>, "<frans.knibbe@geodan.nl>" <frans.knibbe@geodan.nl>, "<public-sdw-wg@w3.org>" <public-sdw-wg@w3.org>
Message-ID: <24637769D123E644A105A0AF0E1F92EF010D0B7E0F@dnbf-ex1.AD.DDB.DE>
Kerry,

On Monday, August 10, 2015 2:38 PM, Kerry Taylor wrote:

>    I am going to put ISSUE-14 on the agenda for this week. I agree that it is well
> within our scope to change OWL-Time as we see fit, although because  it has
> a large user base we should aim for backwards compatibility.   Dealing with
> "fuzzy time" seems necessary and is driven by several use cases.
> 
>    But for now, we are just aiming to clarify the requirement as described by
> Frans at the bottom of this thread.
> 
>    Karl, Simon, Chris why dont you nominate yourselves  for a " technical talk "
> on the wiki and we will give these ideas some air time! simon, you did a short
> one at the F2F, but repeating  in this context would not hurt.
> 
>    Lars, I do hope you can come!

I'll do my best but I cannot promise anything. I'm travelling this week and if things work well, I _should_ be in my hotel at 1 PM UTC on Wednesday, but only if all parts of the journey work seamlessly...

My main point in my use case is really about the representation about uncertain time (much better term, thanks Karl!). If OWL has been updated to accept more xsd date/time types than xsd:dateTime and xsd:dateTimeStamp (e. g. xsd:date or xsd:gYear) so that I could stay within OWL DL even if I cannot supply millisecond precision, at least one of my issues would be solved.

Thanks,

Lars 
> 
> On 10 Aug 2015, at 10:04 am, <Simon.Cox@csiro.au> wrote:
> ➢  OWL-Time was published in 2006 and seems fixed.
>    I already proposed a small extension to allow for non-Gregorian calendars,
> with the essential requirement that it preserves the existing encoding [1].
>    I would suggest that we look at these other concerns with a similar goal in
> mind – to protect existing users of OWL-Time, but where possible to also
> accommodate the richer requirements.
> 
>    Simon
> 
> From: Karl Grossner [mailto:karlg@stanford.edu]
> Sent: Sunday, 9 August 2015 1:21 AM
> To: Kerry Taylor <Kerry.Taylor@acm.org>; Frans Knibbe
> <frans.knibbe@geodan.nl>
> Cc: SDW WG Public List <public-sdw-wg@w3.org>; Lars Svensson
> <L.Svensson@dnb.de>
> Subject: Re: ISSUE 14: temporal reasoning and relations
> 
> Frans, Kerry -
> 
> OWL-time restricts the range of the hasBeginning and hasEnd properties to
> Instant. If that range were extended to include Interval, a great many of the
> temporal expressions we call “fuzzy” (a misnomer, uncertain is better) could
> be encoded that can’t be now, including:
> • “[circa | early | mid | late]  [month | year | century]”
> The 4-part pattern (earliestStart, latestStart, earliestEnd, latestEnd) is as old
> as the hills elsewhere and intuitive - one sees it in timelines, from 18th
> century hand drawn ones of Priestley [1] to MIT’s Simile Timeline.
> 
> As noted, other kinds of uncertainty are handled by Allen’s relations: before,
> during, after, etc. I would say they don’t articulate actual relations well
> enough, but they do a basic job [2].
> 
> OWL-Time was published in 2006 and seems fixed. I agree it should be
> extended. I guess I’m not clear on how the expression of the requirement in
> this group’s work will impact that standard. In the meantime, ad hoc data
> formats (like the Topotime extension to GeoJSON, or PeriodO) are
> tackling  the requirement, coupled with software to interpret data expressed
> in the new model(s).
> 
> A more fundamental issue is that representation requirements for places
> and temporal entities are symmetrical: places have essential temporal
> attributes and occurrences have essential spatial attributes. Events are
> geospatial phenomena; historical periods are aggregations of geospatial
> phenomena. But I digress…
> 
> Cheers
> Karl
> 
> [1] http://math.yorku.ca/SCS/Gallery/images/priestley.gif

> [2] For example, “before” could be intervalBefore, intervalStarts, or
> intervalOverlaps. A really nice treatment of this is in Freksa, C. (1992).
> Temporal reasoning based on semi-intervals. Artificial Intelligence, 54: 199-
> 227
> 
> On 8/8/15, 7:32 AM, "Kerry Taylor" <Kerry.Taylor@acm.org> wrote:
> 
> Frans,
> This requirement is asking for temporal relations which, as you suggest, are
> already in OWL-time (Allen's). I think that it is perfectly reasonable to  leave
> that in as a requirement for our work even so. There were several relevant
> use cases.
> 
> The "xsd formats" part of the requirement came specifically from use case
> http://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Publishing_Cult

> ural_Heritage_Data_.28Best_Practice.2C_Time.2C_Coverage.29
> submitted by Lars, where he said that the xsd time formats available in OWL
> are insufficient.  I suspect, however, that OWL-time addresses, or should
> address, that need, so perhaps the "( xsd formats)" part of the requirement
> can just be  dropped.  Almost certainly I was the one who wrote it, rather
> cryptically.
> 
> 
> 
> Having said that, there is indeed a (fresh and separate) requirement that I
> think should replace that cryptic comment. OWL was updated in 2012 to
> adopt the updated 2012 xsd datatypes, but owl-time remains pre-2012.
> Xsd:datetimeStamp, at least, should be handled in OWL-time ( as OWL
> does).  A requirement like "conform to the 2012 update of OWL datatypes"
> would do, and could apply to both owl-time and also ssn.
> 
> 
> 
> On the fuzzy time requirement, I wonder whether the intervals that can be
> represented in owl-time are good enough? Just wondering -- this is not a
> requirements question.
> 
> 
> 
> @Lars, will you be able to come to the meeting this week?
> 
> Kerry
> 
> 
> On 7 Aug 2015, at 11:33 pm, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
> Hello Karl,
> 
> Should the OWL time ontology make it possible to work with vague or fuzzy
> time, which already is a requirement, do you think there is a need for an
> additional requirement?
> 
> I am fully convinced that time is important and that in many cases time can
> not be encoded in ISO 8601. But the main issue in this discussion is getting
> the requirement (if there is one) straight. At least the editors of the UCR
> document are not clear on what is meant by the proposed requirement. Do
> you see a clear requirement and could you explain it? Perhaps there is
> something useful in Topotime that is not in OWL Time and is not coveredr by
> the requirements currently in the UCR document?
> 
> Regards,
> Frans
> 
> 2015-08-04 17:56 GMT+02:00 Karl Grossner <karlg@stanford.edu>:
> Hello,
> 
> Don't know whether or how this may be useful in the business of SDW; I've
> been largely absent from the group due to timing of meetings:
> 
> Use Case 4.17 states, "There is no framework available to describe fuzzy
> temporal information." There are, however two nascent efforts that will
> accommodate 'fuzziness' in varying degree: the Periods, Organized project
> [1] and Topotime [2]. In both cases, timespans can be described not only by
> pairs of instants, but also by pairs of intervals. This pattern has appeared
> elsewhere (e.g. in the SIMILE Timeline software). Additionally, Topotime
> includes operators like before (<), after (>), and about (~), and differentiates
> 'some time/duration within' and 'throughout.' It is currently in active (re-
> )development as a GeoJSON extension [3].
> 
> All phenomena occurring at a location have temporal attributes of co-equal
> importance (which isn't to say we always know them, or care, or that people
> aren't prone to using spatial snapshots). But general models of natural
> phenomena should permit representing their most important characteristics,
> including the 'where' and 'when' of them. What motivates Topotime is that in
> historical data we are very frequently representing entities with shapes and
> positions that change over time, and for which spatial-temporal extents are
> uncertain in various ways.
> 
> Happy to discuss further - in or out of this thread :^)
> 
> Karl
> 
> [1] http://perio.do

> [2] http://dh.stanford.edu/topotime

> [3] https://github.com/kgeographer/topotime

> 
> 
> --
> Karl Grossner, PhD
> Center for Interdisciplinary Digital Research
> Stanford University Libraries
> http://kgeographer.org

> ________________________________________
> From: Frans Knibbe <frans.knibbe@geodan.nl>
> Sent: Tuesday, August 04, 2015 6:33 AM
> To: SDW WG Public List
> Subject: ISSUE 14: temporal reasoning and relations
> 
> Hello,
> 
> The oldest remaining issue with the UCR document is ISSUE-14: Not clear
> Time req. - temporal reasoning and relations (xsd formats). Until now the
> issue had no related e-mail thread. This message changes that. I hope we can
> all think about this issue and work towards resolving it - hopefully in next
> week's meeting.
> 
> My personal understanding is that this issue could be intended to lead to
> addition of a new requirement that is the temporal equivalent of the spatial
> operators requirement. Especially when considering inexact dates and times
> I think it would be good to have operators like 'before', 'after', 'during' at
> one's disposal. But when looking at the Time Ontology I see such concepts
> are already there. I understand them to be only usable with exact dates and
> times, but there already is a requirement for temporal vagueness. Could this
> mean there is no reason to add another requirement?
> 
> Regards,
> Frans
> 
> 
> --
> Frans Knibbe
> Geodan
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
> 
> T +31 (0)20 - 5711 347
> E frans.knibbe@geodan.nl
> www.geodan.nl
> disclaimer
> 
> 
> 
> 
> 
> --
> Frans Knibbe
> Geodan
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
> 
> T +31 (0)20 - 5711 347
> E frans.knibbe@geodan.nl
> www.geodan.nl
> disclaimer
> 
Received on Monday, 10 August 2015 13:07:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:17 UTC