RE: New proposal (Re: getting rid of xsd:dateTime ?)

Pierre Antoine,

I understand your last proposal but this will need to be very well documented otherwise:


-          What will be found in instances may prove hazardous.

-          It definitely makes the adoption of the ontology more difficult as the issues and implications of the options may be hard to grasp

My take on your summary of the problem is that if people want to take maximum benefit from compliance they'll have to use the dateTime format anyway. It seems a bit tricky /misleading to offer the option of not being fully compliant (and again I agree that dateTime is not particular nice).

Regards,

Jean-Pierre

From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Felix Sasaki
Sent: mercredi, 6. avril 2011 09:35
To: Pierre-Antoine Champin
Cc: public-media-annotation@w3.org
Subject: Re: New proposal (Re: getting rid of xsd:dateTime ?)

Hi Pierre-Antoine,
2011/4/6 Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr<mailto:pierre-antoine.champin@liris.cnrs.fr>>
Felix,

On 04/06/2011 12:32 AM, Felix Sasaki wrote:
> 2011/4/5 Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr<mailto:pierre-antoine.champin@liris.cnrs.fr>
> <mailto:pierre-antoine.champin@liris.cnrs.fr<mailto:pierre-antoine.champin@liris.cnrs.fr>>>
>
>     Hi all,
>
>     there seem to be a recurring problem with dates and the ma: ontology. I
>     encountered it, Martin encountered it, I know that Joakim also did...
>
>     The fact is that most metadata formats we are dealing with allow dates
>     to be more or less precise, like
>
>     * just a year
>
> in XML Schema, this would be gYear http://www.w3.org/TR/xmlschema-2/#gYear
>
>     * a year and a month
>
> this would be http://www.w3.org/TR/xmlschema-2/#gYearMonth
>
>     * a year, a month and a day
>
> this would be date http://www.w3.org/TR/xmlschema-2/#date


You are completely right.


>     * ...
>
>     while xsd:dateTime imposes to us to commit to a 1sec precision...
>
>     I suggest we change the range of date properties to rdfs:Literal, and
>     specify in the documentation that they should be of the form
>     YYYY[-MM[-DD[Thh[:mm[:ss[.fff]]]]]], to be interpreted as an incomplete
>     date.
>
> This would be very bad. RDF in many areas is linked to XML datatypes,
> see e.g. http://www.w3.org/TR/rdf-primer/#typedliterals , and I would
> encourage us to follow this approach as close as possible. To solve your
> problems, I would rather say that a date should be one of the above
> built in XML Schema data types.

I probably jumped to fast to the proposal above, for the reasons
explained below. Nevertheless I agree with you that a better solution
would be that section 4.5 be rewritten:

 A Date value MUST be represented using one of the following XML
 Schema datatypes: gYear, gYearMonth, date, dateTime, dateTimeStamp,
 depending on the precision available on the data.

NB: I add dateTimeStamp which is new in XSD 1.1 [1], and imposes a
timezone. I know that XSD 1.1. is not recommended yet, but OWL2 found a
nice way to get around this problem [2].

This would have to be reflected in the API document as well [3].


Now, if I had to do only pure RDF, I would be happy with this solution.
My problem is that we have been asked in some comments to make the
ontology compliant with the OWL2-RL profile which, I think, makes sense
(OWL-RL inferences can be efficiently implemented on top of a rule
language). And OWL2-RL does not support xsd:gYear or xsd:gYearMonth. In
fact, on only support dateTime and dateTimeStamp [4].

Hence my first proposal to use the smallest common denominator
(rdfs:Literal), although we lose some semantics in the process.


Here is a second proposal that I think will suit you better: we leave
the range of 'date' (and its subproperties) *unspecified* in the OWL
ontology, and refer to the document to explain that only date-related
datatypes are expected (and only dateTime[Stamp] are supported by OWL2-RL).


This sounds good to me, so also a +1 like Florian in this thread. I think it might be worthwhile to explain the issue in our spec, basically use your text in this thread, so that users understand the rationale.

Out of curiosity: Do you know why OWL2-RL only supports the above date / time related types?

Felix


On the one hand, I'm afraid that this is only translating the problem
from the ontology to the data: if people publish data using a datatype
not supported by OWL2-QL, will their data be correctly processed by a
OWL2-QL inference engine?...

On the other hand, this would *allow* people to use the correct datatype
if they want to, and/or to be compliant with OWL2-QL if they want to.

 pa

[1] http://www.w3.org/TR/xmlschema11-2/
[2]
http://www.w3.org/TR/2009/REC-owl2-conformance-20091027/#XML_Schema_Datatypes
[3]
http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html#attributes-7
[4] http://www.w3.org/TR/owl2-profiles/#Entities_3

>
> Felix
>
>
>
>
>     This hinders interoperability a tiny bit, but not as much as inventing a
>     day and an hour for media resources for which we only know the year.
>
>      pa
>
>
>
>     To all, some general remarks and conclusions
>
>     * as most metadata format are more permissive regarding dates than
>     xsd:dateTime, I suggest we simply use rdfs:Literal for all our date
>     properties, and explain that it should be of the form
>     YYYY[-MM[-DD[Thh[:mm[:ss[.fff]]]]]]
>
>