W3C home > Mailing lists > Public > public-owl-wg@w3.org > May 2012

RE: status of xsd:duration in OWL (and RIF and SPARQL) - ACTION-164: RDF WG

From: Evain, Jean-Pierre <evain@ebu.ch>
Date: Tue, 8 May 2012 13:43:05 +0200
To: 'Bijan Parsia' <bparsia@cs.man.ac.uk>
CC: 'Michael Schneider' <schneid@fzi.de>, 'Ivan Herman' <ivan@w3.org>, Ian Horrocks <ian.horrocks@cs.ox.ac.uk>, "public-owl-wg@w3.org" <public-owl-wg@w3.org>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Sandro Hawke <sandro@w3.org>
Message-ID: <7D1656F54141C042A1B2556AE5237D600116304E6142@GVAMAIL.gva.ebu.ch>
Just a last one :--)

You actually provided me with good reasons to just ban time and duration from all my ontologies, I mean based on xsd types.

I think I'll just restrict myself to using time and duration based on float (I hope that one is supported... just joking) for a number of second and associated fractions of a second and integer for a number of edit unit.

If people ask me why I'll cut and paste that thread :--)

Jean-Pierre

From: Bijan Parsia [mailto:bparsia@cs.man.ac.uk]
Sent: mardi, 8. mai 2012 11:36
To: Evain, Jean-Pierre
Cc: 'Michael Schneider'; 'Ivan Herman'; Ian Horrocks; public-owl-wg@w3.org; Public-Rif-Wg (E-mail); Peter F. Patel-Schneider; Sandro Hawke
Subject: Re: status of xsd:duration in OWL (and RIF and SPARQL) - ACTION-164: RDF WG

Just a quick hit and then I really must prep for class. (Thanks to Ivan for the diff...it's pretty useful.)

On 8 May 2012, at 10:18, Evain, Jean-Pierre wrote:


Dear Michael,

I appreciate your time and effort in trying to bring more background around the current situation.

I must say that I am growingly puzzled. This is definitely making me question my resolution to move for these technologies.

The problem really generally is in XSD.

[snip]
I believe that the semantics of time, date and duration are clear

This is definitely a false belief. Simple reflection on calendars should show that. That's not to say that we can't come up with something useful, but the history of computing (and of science) is littered with problematic representations of time (generally speaking).


and I am surprised that they may be considered as being not mathematically univocally representable.

Relativity theory has a few things to say about that :) (Seriously, identity of time instants or durations is non trivial.)

In any case, we're not talking about representations in general, but the particular representations given by XSD 1.1. They need to be well defined enough and *properly* defined enough to not cause problems and be useful.
[snip]
Why not simply reuse the xsd datatypes? That would solve all the above problems with a simple expression in a well defined format. What do I miss?
[snip]

That the XSD datatypes are not as nice as you presume. Seriously. Just look at the comparison critera for Duration:
            http://www.w3.org/TR/xmlschema11-2/#duration

It's not, "Represent as an integer number of seconds, and then use integer comparison", it's "add them to some magic constants and":
            "If all four resulting dateTime value pairs are ordered the same way (less than, equal, or greater than), then the original pair of durationvalues is ordered the same way; otherwise the original pair is *incomparable*."

Now it also claims that:
            "Under the definition just given, two duration<http://www.w3.org/TR/xmlschema11-2/#duration> values are equal if and only if they are identical."
Which is promising.


I hope this makes it clear that "just reusing" xsd:duration requires significant effort.


Cheers,
Bijan.


------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************
Received on Tuesday, 8 May 2012 11:43:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:15 UTC