Does it make sense to add time:inXSDDate and others? (was: RE: Please review OWL-Time document)

Simon,

On Wednesday, January 11, 2017 10:39 PM, Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] wrote:

[...]

> 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?

Looking at this again, I find it a bit restricting that the only XML datatypes that are allowed directly on instances of time:Instant require the user to specify the time with second precision (which generally means that you just say "midnight" if you don't have that kind of information which makes the data look more precise than it is...). If you don't have that precision in your data (as is often the case in the cultural heritage domain) and don't want to pretend that you do, the only way to encode a date in OWL Time is to supply an instance of time:DateTimeDescription and then use time:month, time:year etc.

This could be much easier if there was a way to use other XSD datatypes directly (particularly xsd:gYear, xsd:gYearMonth and xsd:date). Is there a possibility to add three more properties time:inXSDDate, time:inXSDgYear and time:inXSDgYearMonth as analogues to time:inXSDDateTimeStamp?

And BTW: If we think it's a bad idea to use xsd:dateTime we should update all examples to use xsd:dateTimeStamp instead.

Best,

Lars

Received on Thursday, 12 January 2017 08:35:07 UTC