FW: ISSUE-125: Update datatypes in OWL Time

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