- From: Svensson, Lars <L.Svensson@dnb.de>
- Date: Tue, 24 Jan 2017 15:09:22 +0000
- To: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Simon, Thanks for the updated draft. On Tuesday, January 24, 2017 5:08 AM, Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] wrote: > 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. Indeed it does! > See http://w3c.github.io/sdw/time/#topology Figure 1, and the documentation in > Classes and Properties. Looks good to me, so +1 from me for publishing as FPWD. [...] Best, Lars > > -----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 15:10:12 UTC