- From: <Simon.Cox@csiro.au>
- Date: Mon, 20 Feb 2017 02:45:33 +0000
- To: <public-sdw-wg@w3.org>
Also related to ISSUE-126 -----Original Message----- From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] Sent: Tuesday, 24 January, 2017 15:08 To: L.Svensson@dnb.de; public-sdw-wg@w3.org Subject: [ExternalEmail] RE: ISSUE-125: Update datatypes in OWL Time 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 Monday, 20 February 2017 02:46:21 UTC