Re: Serializing datetime

On Tue, 2012-07-31 at 17:23 +0100, Andy Seaborne wrote:
> 
> On 31/07/12 17:06, David Booth wrote:
> > Hi Andy,
> >
> > I am satisfied with this resolution provided that "Advice on canonical
> > datetime values" is added to the wish list for consideration in the next
> > version:
> > http://www.w3.org/2009/sparql/wiki/Future_Work_Items
> >
> > It certainly is possible to convert, but one important point of
> > standardization is to reduce the amount of conversion that is needed
> > when transferring data from one system to another.
> 
> Standards build on other standards.
> 
> The canonical representation of datetime is already defined by:
> 
> http://www.w3.org/TR/xmlschema11-2/#vp-dateTimeCanRep
> 
> coupled with the requirements of RDF datatypes.  Surely this is an RDF 
> issue, not SPARQL specific?

I guess it touches on both RDF and SPARQL.  The problem that I ran into
is that some SPARQL servers are changing the literal representation of
an xsd:datetime and others are not, and this makes it unnecessarily
difficult to compare the serialized output of two different SPARQL
servers.

> 
> If the input data uses a specific timezone, many people will expect that 
> to be preserved.  

I think that would be an acceptable solution -- probably the best
solution if it is coupled with adequate canonicalization in RDF.  But
AFAIK, the SPARQL spec says nothing about this at present.

> Maybe the whole application is used in one timezone.
> 
> 
> Value based matching is a feature of SPARQL 1.0 and can be achieved with 
> FILTER and XSD:
> 
> "2012-07-31T17:16:00+01:00"^^xsd:dateTime
> =
> "2012-07-31T16:16:00Z"^^xsd:dateTime
> 
> The relationship of
> "2012-07-31T17:16:00+01:00"^^xsd:dateTime
> and
> "2012-07-31T16:16:00"^^xsd:dateTime
> is indeterminate
> and
> "2012-07-31T17:16:00+01:00"^^xsd:dateTime
>  >
> "2012-07-30T16:16:00"^^xsd:dateTime'
> 
> (the 14 hour rule).

Yes, but the above would require pulling the data back into a SPARQL
server to perform the comparison, and the point is to make it easier to
compare serialized SPARQL output.

David


> 
> 
>  Andy
> 
> >
> > Thanks,
> > David
> >
> >
> > On Tue, 2012-07-31 at 09:05 +0100, Andy Seaborne wrote:
> >> David,
> >>
> >> Thank you for your comment on serializing datetime values.
> >>
> >> As noted in the response to your comment on "Serializing xsd:decimal,
> >> xsd:float, xsd:double", SPARQL reuses the body of work for XSD and
> >> XQuery/XPath functions and operators.  The rules for operations on
> >> datetimes derive from that work and this includes comparing datetime
> >> values.  Support is also now to be found in many programming languages.
> >>
> >> An implementation is free to provide custom function that converts
> >> between timezones; XQuery/XPath does not itself provide such a function.
> >>
> >> The working group is not planning to make any changes in this area.
> >>
> >> I would be grateful if you reply to this message to confirm that the
> >> working group has responded to your comment.
> >>
> >> Yours, on behalf of the SPARQL Working Group,
> >>
> >>       Andy
> >>
> >> On 20/07/12 16:21, David Booth wrote:
> >>> I have also noticed that it is a hassle trying to compare datetime
> >>> values from two different SPARQL servers, because the same datetime may
> >>> be written with different timezone offsets.  This is less vexing than
> >>> xsd:decimal serializations, because at least timezone offsets are
> >>> information preserving, but still it makes comparisons more difficult
> >>> than they otherwise need to be.
> >>>
> >>> I think the WG should consider defining a default datetime format (such
> >>> as UTC or zero timezone offset) that SHOULD be use, while allowing
> >>> servers to make this a configurable option.
> >>>
> >>> I assume it is too late in the WG process to consider this for SPARQL
> >>> 1.1, so please add this to the wish list for the next version.
> >>>
> >>> Thanks!
> >>>
> >>
> >>
> >
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 31 July 2012 20:01:26 UTC