- From: Ian Horrocks <ian.horrocks@comlab.ox.ac.uk>
- Date: Fri, 20 Mar 2009 15:16:18 +0000
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: Boris Motik <boris.motik@comlab.ox.ac.uk>, W3C OWL Working Group <public-owl-wg@w3.org>
Alan, Apart from dateTime, we are now at least *consistent* with XML Schema even if we don't support *all* of XML Schema, and it seems to me that it would make sense to be completely consistent with XML Schema. Elsewhere (e.g., AR1) you say that interoperability is crucial and that it should be absolutely forbidden to attach non-standard interpretations to existing IRIs, but in this context you seem to be saying that it is OK for us to do exactly that. I'm confused. Ian On 18 Mar 2009, at 09:22, Alan Ruttenberg wrote: > Hello Boris. > > Why do you think that the time zone information needs to be in the > model? Could not the XML schema functions be implemented on syntax? > Moreover, how are we to answer queries about individuals implied by > existential restrictions? > > In short, I don't agree with this proposal and consider it a step > backwards. We won't have complete conformance with XML Schema > datatypes for a number of reasons, for example because we can't > support all the facets they define. I don't see why this case is > particularly compelling, and I anticipate that it will cause > complications for developers who simply want to know at what time > something was said to happen. > > -Alan > > On Thu, Mar 12, 2009 at 8:07 AM, Boris Motik > <boris.motik@comlab.ox.ac.uk> wrote: >> Hello, >> >> At the yesterday's teleconf, we have decided to follow strictly >> XML Schema in >> the design of numeric and binary data datatypes. We are now left >> with only one >> datatype that does not comply with XML Schema, and that is >> xsd:dateTime(Stamp). >> I believe that, for consistency, we should change the definition >> of that >> datatype as well. Below are answers to some questions I expect >> people will ask. >> >> Q. Why did I cause the stir with changing XML Schema datatypes in >> the first >> place? >> A. Initially, we were working off of XML Schema 1.0, which was not >> sufficiently >> precise for our purpose. Therefore, I felt we needed to fix the >> definitions so >> that they can be implemented in OWL 2. In the meanwhile, the >> developments in the >> XML Schema 1.1 specification have rendered many of my initial >> concerns moot. >> >> >> Q. Why bother? >> A. I believe that we should have a consistent set of design >> principles across >> the board. Following different guidelines for different datatypes >> makes us look >> schizophrenic :-), and is just likely to raise questions with the >> readers. >> >> >> Q. Our behaviour was sanctioned by the XML Schema WG, so why bother? >> A. The same was true for the numerics: the XML Schema WG >> explicitly said that >> they don't see a problem with us using equality as identity. >> Despite their >> approval, we changed the numeric datatypes to follow XML Schema; >> well then, I >> believe we should apply the same principles across the board. >> >> >> Q. What will change technically? >> A. Consider the following ontology: >> >> (1) FunctionalDataProperty( a:P ) >> (2) DataPropertyAssertion( a:I a:P "12/03/2009, 2am >> CET"^^xsd:dateTime) >> (3) DataPropertyAssertion( a:I a:P "12/03/2009, 1am >> GMT"^^xsd:dateTime) >> >> Although the dates "12/03/2009, 2am CET" and "12/03/2009, 1am GMT" >> have a >> different time zone, they are currently interpreted as the >> identical point on >> the time line. Hence, the individual a:I has exactly one value of >> the property >> a:P, so the axiom (1) is not violated. >> >> In XML Schema, however, "12/03/2009, 2am CET" and "12/03/2009, 1am >> GMT" are >> mapped to *distinct* objects. Hence, although the two objects >> represent the same >> time instant, there are two values of a:P for a:I, so the ontology >> would be >> inconsistent under the XML Schema semantics. >> >> Note that this is *exactly* the same problem as the one we have >> with xsd:decimal >> and xsd:double; hence, I consider it really strange to use one >> solution for >> numerics but a completely different one for dates. >> >> >> Q. What are other, more general benefits to the spec? >> A. I can see several benefits: >> >> - The spec gets simpler. We can point to XML Schema for all >> definitions, and I >> would just add a couple of examples that highlight various tricky >> consequences >> of these definitions. >> >> - We can support xsd:dateTime, and not just xsd:dateTimeStamp. >> (That is, we can >> support dates without a time zone.) We cannot do this now because >> we need the >> time zone to map the date-time literals onto the time line. XML >> Schema, however, >> provides a different time line for each time zone, and one more >> time line >> without the time zone. This makes xsd:dateTime perfectly >> supportable under the >> XML Semantics. >> >> - Nobody (such as RIF) can scorn us for going our way: we can >> always point to >> XML Schema and say "Here is the holy bible!" >> >> >> Regards, >> >> Boris >> >> >> >
Received on Friday, 20 March 2009 15:17:04 UTC