W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > July 2012

Re: Serializing datetime

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 31 Jul 2012 21:46:12 +0100
Message-ID: <50184414.3050008@epimorphics.com>
To: public-rdf-dawg-comments@w3.org


On 31/07/12 21:00, David Booth wrote:
> 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.

We are not responsible for implementations.  Have you discussed this 
with the providers?

 From experience on support lists, the first user expectation is what 
comes out is what goes in.  Mangling term is confusing except, possibly, 
in a few well-known cases.  xsd:dateTime is not a well-known case.

SPARQL Query says nothing about how the data got into the system but it 
does say that matched terms are not warped in some datatype special way.

(Personally, if a system turned -05:00 into Z, I'd complain because more 
often you want everything in the local timezone for display.)

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

An issue for the system which the output is read into.

XSD libraries exist for many languages.

	Andy

>
> 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!
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Received on Tuesday, 31 July 2012 20:46:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 31 July 2012 20:46:41 GMT