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

Michael,

Thanks for the documented explanations.

However, that looks like very convoluted. Anytime, those who want to solve the issues that you mention can use dateTime.

But, I am trying to bring RDF and OWL in audiovisual production and I need to express things as simple as:

- segment video "y" start at time "t" for a duration "d"

I do not see why I should use any date information in this, it is not relevant. Also because dateTime is a frequent source of errors.

But maybe it is a bad idea altogether to bring RDF and OWL in audiovisual production?

Jean-Pierre

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

Am 07.05.2012 12:42, schrieb Bijan Parsia:
> On 7 May 2012, at 11:29, Michael Schneider wrote:
>
>> Am 07.05.2012 00:19, schrieb Ian Horrocks:
>>> Hi Bijan (et al),
>>>
>>> According to my understanding, we agreed to keep the WG alive so that we could fix any OWL 2 problems caused by changes to XSD 1.1 and update the OWL 2 Rec to reference the XSD 1.1 Rec. It was also foreseen that we could take advantage of this update to fix any editorial errata in the OWL 2 Rec.
>>>
>>> While I agree that the dividing line between editorial errata and substantive changes is not 100% clear, it does seem pretty obvious to me that adding support for a new datatype goes beyond the spirit of this agreement.
>>
>> I agree!
>
> But, you know, who the heck cares about the spirit of some agreement?

Oops, sorry for having been so short on words - that's not what people 
generally expect from me and, certainly, I have more to say than simply 
agreeing to Ian. :-)

Fine, not talking about procedural stuff here, and also not mentioning 
(ok, I do) that I believe that it's not so easy to bring a working group 
happily back to work after 2 1/2 years, there is still the question 
whether these three datatypes are technically appropriate for inclusion 
in OWL at all (whether in OWL 2, or OWL 2.1, or whatever). So here is 
the situation as I recall it:

First to say, it's not that these datatypes were simply forgotten to be 
considered, as some people seem to believe. Rather, at least two of them 
were discussed and then excluded deliberately. Below is my understanding 
of why and when this happened.

NOTE: In the remainder, whenever I refer to the XSD datatype spec, I 
refer to the Candidate Recommendation as of 30 April 2009, which was the 
one to which the OWL 2 and RIF specs currently refer to.

1) xsd:time

IIRC, the OWL WG had adopted a certain design principle for the 
time-related datatypes of OWL 2, which was the "timeOnTimeline" 
property, as defined in the XSD datatype spec [1]: each data value in 
the value space of a datatype must be exactly one point on the 
everlasting time line.

This is certainly fulfilled by xsd:dateTimeStamp, which is included in 
OWL 2. In xsd:time, however, each data value specifies infinitely many 
times on the time line: "12:00:00 o'clock" happens every day! In fact, 
The XSD spec at that time said [2]:

     time represents instants of time that recur
     at the same point in each calendar day, or
     that occur in some arbitrary calendar day.

For OWL 2 reasoners (well, actually for the OWL 2 semantics), such a 
definition is a problem, because they have to decide for two given times 
whether the two times are equal or not and, if not, whether one time 
value is smaller or larger than the other one. Comparisons of this sort 
become particularly troublesome, if one tries to compare, say, a 
xsd:time value with a xsd:dateTimeStamp value: the dateTimeStamp value 
is a fixed point on the time line, but any xsd:time value will refer to 
time points both before and after that fixed time point.

The corresponding OWL WG issue was ISSUE-126 [3]. The description of the 
issue swiftly mentions the problems of the time-related datatypes. There 
was a long discussion on this issue, as you can see from the list of 
references below the issue description; I guess, these mails contain 
more discussion on the xsd:time datatype problem, but I haven't read 
them all. The eventually accepted proposal (which only mentions 
xsd:dateTime but not any of the other time-related datatypes anymore) to 
resolve the issue was [4], with resolution at F2F3 [5] and 
implementation by ACTION-177 [6].

2) xsd:date

Here, the situation was different compared to xsd:time, as data values 
in the value space of xsd:date do not represent time points, but time 
/intervals/, as stated in the old version of the spec [7]:

     date represents top-open intervals of exactly
     one day in length on the timelines of dateTime,
     beginning on the beginning moment of each day,
     up to but not including the beginning moment
     of the next day.

This, of course, is also not compatible with the 
single-point-on-timeline design criteria. Consequently, xsd:date was 
excluded by the resolution of ISSUE-126 as well.

3) xsd:duration

Unfortunately, I wasn't able to find any discussion on xsd:duration in 
the OWL WG mailing list. The reason might be that this datatype was 
already excluded in the XSD datatype map of RDF [8]:

     The other built-in XML Schema datatypes are
     unsuitable for various reasons, and SHOULD NOT
     be used: xsd:duration does not have a well-defined
     value space

In retrospect, this first came to a surprise to me, so let's see how the 
value space of xsd:duration was defined in the old CR of XSD 1.1 [9] 
(long after the RDF rec, which still referred to XSD 1.0!):

     Duration values can be modelled as two-property
     tuples. Each value consists of an integer number
     of months and a decimal number of seconds.

Hrmpf, that appears to me a strange definition: why months? The length 
of a month is not well-defined, it may be anything between 28 and 31 
days. So it would be easy to give two xsd:duration literals, basically 
consisting of month-second tuples, for which it becomes non-well-defined 
whether they are equal or, if not, which of them is smaller or larger. 
In fact, the text continues by:

     duration is partially ordered.

Sorry, but... I'm not clear where this idea of using months as part of 
the value space definition came from. Anyhow, for OWL 2 reasoners, 
adopting xsd:duration would make things troublesome, as some OWL 2 
ontologies would not have a well-defined semantics then.

    * * *

Now, so far for the situation at the time of OWL 2 recommendation. All 
three datatypes, according to their definitions in the XSD candidate 
recommendation at the time of OWL 2 and RIF spec, provided problems for 
OWL 2, be it with respect to the one-point-on-timeline design criteria 
(xsd:time and xsd:date), or with regard to well-definedness of the (two) 
OWL 2 semantics (xsd:time and xsd:duration). I leave it to the 
proponents of these datatypes to explain what has changed in the XSD 
spec since the recommendation of OWL 2 to allow for these datatypes to 
be included now, such that (a) the design decisions made for OWL 2 are 
retained and (b) without rendering the semantics of OWL 2 non-well-defined.

Best,
Michael

References:

[1] 
<http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#vp-dt-timeOnTimeline>
[2] <http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#time>
[3] <http://lists.w3.org/Archives/Public/public-owl-wg/2008Jun/0138.html>
[4] <http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0433.html>
[5] <http://www.w3.org/2007/OWL/meeting/2008-07-29#resolution_1>
[6] <http://www.w3.org/2007/OWL/tracker/actions/177>
[7] <http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#date>
[8] <http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#XSDtable>
[9] <http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#duration>

-- 
.........................................................
Dipl.-Inform. Michael Schneider
Research Scientist, IPE / WIM

FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10-14
76131 Karlsruhe, Germany
Tel.: +49 721 9654-726
Fax: +49 721 9654-727

michael.schneider@fzi.de
www.fzi.de

.........................................................
Forschungszentrum Informatik (FZI) an der Universität Karlsruhe
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Dipl. Wi.-Ing. Michael Flor, Prof. Dr. Ralf Reussner,
Prof. Dr. Rudi Studer, Prof. Dr.-Ing. J. Marius Zöllner
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
.........................................................
------------------------------------------------------------------------------

**************************************************
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 06:28:10 UTC