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

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>>
> 
>     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).

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]]]]]]
> 
>

Received on Wednesday, 6 April 2011 06:51:39 UTC