- From: <Simon.Cox@csiro.au>
- Date: Tue, 24 Jan 2017 04:07:50 +0000
- To: <L.Svensson@dnb.de>, <public-sdw-wg@w3.org>
OK - I've implemented this, though it does rather bloat the Instant class. Little gain in semantics, but does add convenience for implementers I guess. See http://w3c.github.io/sdw/time/#topology Figure 1, and the documentation in Classes and Properties. OWL-Time actually has a lot of this - alternative ways of expressing the same things. There is probably a case for general super-classes TemporalDuration and TemporalPosition, under which Duration/DurationDescription and TImePosition/DateTimePosition are just implementation views dressed up as sub-classes ... -----Original Message----- From: Svensson, Lars [mailto:L.Svensson@dnb.de] Sent: Tuesday, 24 January, 2017 04:05 To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-sdw-wg@w3.org Subject: RE: ISSUE-125: Update datatypes in OWL Time Simon, On Monday, January 23, 2017 2:10 AM, Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] wrote: > I propose to resolve this issue by > (i) Cloning the property time:inXSDDateTime as > time:inXSDDateTimeStamp, using the new datatype that was built-in to > OWL2 > (ii) Deprecating time:inXSDDateTime in order to > encourage people to be careful about timezones, while protecting the legacy. > > OK? I'm fine with those changes and also propose that we add at least time:inXSDDate and preferably time:inXSDgYear and time:inXSDgYearMonth, too, so that those-of-us-that-don't-have-data-with-second-precision can have an easy way to express our temporal information. Best, Lars
Received on Tuesday, 24 January 2017 04:08:45 UTC