RE: I've implemented the changes to xsd:dateTimeStamp

Hello,

I've fixed the typo -- thanks!

To understand how xsd:dateTime works, you need to consider the issues of
identity and the issue of ordering separately.

1. Identity

Two date-times are identical only if their time zones are identical (and,
consequently, if day, month, ..., hour, minute, ... are identical as well). This
basically affects only number restrictions, and it does so in a way that I've
outlined in the document.

2. Comparison

Comparison becomes important only in the definition of facets, and there time
zones are not important. That is, a data range constructed by a facet of the
form "all instants after 1st of May 2009, at 10am GMT (inclusive)" will contain
the time instant " 1st of May 2009, at 11am CET". This is as expected: if you
use facets to define data ranges, time zone difference does not matter.

That's it! I really don't see any problem with it, from implementation or the
user point of view.

Regards,

	Boris


> -----Original Message-----
> From: Evan Wallace [mailto:ewallace@cme.nist.gov]
> Sent: 30 March 2009 18:27
> To: Boris Motik
> Cc: 'W3C OWL Working Group'
> Subject: Re: I've implemented the changes to xsd:dateTimeStamp
> 
> Regarding the new treatment of date-times:
> 
> In going through the diffs provided, I noticed a minor bug in the new
> text. In section 4.1
> of syntax, the first sentence of the third para now reads:
> "The datatypes owl:real and owl:decimal are defined as follows. "
> While I believe it should read:
> "The datatypes owl:real and owl:rational are defined as follows. "
> 
> I have more serious reservations about the addition of xsd:dateTime and
> perhaps
> even the new interpretation of xsd:dateTimeStamp. We previously had
> quite constrained
> but clear support for date-time. Now I am not sure what we are buying
> into by using the
> xsd 1.1 part2 interpretation, so I would like a bit more time to look at
> the changes and at
> xsd 1.1 to better understand this. One obvious concern is the partial
> ordering specified
> in the current version of xsd for xsd:dateTimes without timezone offsets
> and those with.
> Are we buying into this bit? I hope not.
> 
> -Evan
> 
> Boris Motik wrote:
> > Hello,
> >
> > I have just implemented the change to the semantics of xsd:dateTimeStamp.
> While
> > doing so, I took the liberty to clean up the datatype section a bit. The
> main
> > problem was that the section was written as if it were defining various
> > datatypes; for example, it said "The facets of xsd:string are such-and-
> such".
> > This is clearly wrong: the facets of xsd:string are as defined in the XML
> Schema
> > document, and there is nothing we can do to change this. Another problem was
> > with the tables with the semantics of facets which were superfluous.
> >
> > To clarify all this, I have explicitly stated now that the sections defines
> only
> > owl:real and owl:rational, and that the specification merely reuses the
> > definitions of various datatypes. Hence, I've removed any attempts to
> (re)define
> > XML Schema datatypes and have just added a bunch of examples by means of
> which
> > we discuss certain consequences of their definition.
> >
> >
> >
> ...
> > Finally, I would just like to point out that we should include xsd:dateTime
> into
> > our datatype map now. There is no good technical reason not to do so;
> > furthermore, most of the ontologies out there use xsd:dateTime rather than
> > xsd:dateTimeStamp so, according to our current solution, such ontologies are
> not
> > OWL 2 ontologies. I hope we can discuss and resolve this at the next
> teleconf.
> 
> 
> /
> 
> /
>

Received on Monday, 30 March 2009 17:45:24 UTC