RE: Please review OWL-Time document

Simon, Lars,

My simple take on the difference between xsd:dateTime and xsd:dateTimeStamp is that dateTime, with appropriate calendar specification and algorithms, can be used to calculate durations as well as perform Allen algebra.

My understanding of dateTimeStamp, or at least RFC 3339, is that it has been VERY carefully engineered to give a monotonic sequence of alphanumeric 'tokens' that can be used for Allen algebra, but makes NO statements about durations or calendars or any other semantic content.  Of course this subtle distinction is often 'thrown out with the bath water' as the notation is ISO 8601 based.

I think we should dissuade people from using dateTimeStamp as a convenient Coordinate Reference System or Calendar, when it is neither. Strictly, two dateTimeStamps from two different, unsynchronized computers cannot be compared.

HTH, Chris 

-----Original Message-----
From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] 
Sent: Wednesday, January 11, 2017 9:39 PM
To: L.Svensson@dnb.de; public-sdw-wg@w3.org
Subject: RE: Please review OWL-Time document

Thanks Lars -

1) Actually there is no domain or range for time:after, just the inverseOf relationship to time:before which does have them. 
Of course the domain and range is implied by the inverseOf relationship. 
But I'm not sure what the current recommended style is - in 2006 I guess domain and range were omitted if an inverseOf relationship was declared. 
But it requires a reasoner to understand this. Is there a general assumption that reasoning shall always be assumed? 

I had not intended to change this (though I had mistakenly added a domain and range for time:after in the ttl file, which I have now reverted). 
If the group thinks a change is merited, then I am happy to insert domains and ranges all round where they are already implied by inverseOf relationships. 

2) Processed. 

3)   Regarding ISSUE-125 - I agree that xsd:dateTimeStamp is preferable, but the problem is backward compatibility. 
If the rdfs:range of inXSDDateTime is changed from xsd:dateTime (which is still part of OWL2 btw) to xsd:dateTimeStamp, then what are the implications for existing data in which the timezone is omitted? 
Does it become 'invalid' in some way? 

Simon 

-----Original Message-----
From: Svensson, Lars [mailto:L.Svensson@dnb.de]
Sent: Thursday, 12 January, 2017 07:43
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-sdw-wg@w3.org
Subject: RE: Please review OWL-Time document

Simon, all,

On Thursday, December 22, 2016 6:37 AM, Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] wrote:

> The Editors draft of the OWL-Time specification can be considered for 
> release as a second public working draft.
> http://w3c.github.io/sdw/time/

 
I use the time after today's super-short meeting to make some very minor comments on this very concise and informative document: cudos to the editors!

1) time:before has domain and range time:TemporalEntity which time:after doesn't. I guess that time:after should have domain and range, too.

2) There is a typo in the URI given in the OWL-2 reference [1]. The text is ok, but the href says http://www.w3.org/TR/turtle/owl2-quick-reference/#Built-in_Datatypes . I think that should be http://www.w3.org/TR/owl2-quick-reference/#Built-in_Datatypes


3) Regarding ISSUE-125 and backward compatibility with OWL-1, there was a mail from Antoine Zimmermann where he said: "The standard Web Ontology Language is now OWL 2. Let us forget about OWL 1" [2]. So I think it should be safe to update the spec to use xsd:dateTimeStamp.

[1] https://w3c.github.io/sdw/time/#OWL-2

[2] https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0069.html


Best,

Lars

Received on Thursday, 12 January 2017 10:56:15 UTC