Re: Encouraging canonical serializations of datatypes in RDF

On Wed, 2012-08-01 at 23:34 +0100, Steve Harris wrote:
> On 1 Aug 2012, at 18:49, David Booth <david@dbooth.org> wrote:
> 
> > On Wed, 2012-08-01 at 17:56 +0100, Steve Harris wrote:
> >> On 2012-08-01, at 17:09, David Booth wrote:
> >> 
> >>> On Wed, 2012-08-01 at 10:10 -0400, Peter F. Patel-Schneider wrote:
> >>>> OK, both use cases are acknowledged.
> >>>> 
> >>>> Given that there is a use case where the time zone is important, how can 
> >>>> suggesting only using Z when timezone is not important be any help to 
> >>>> application writers?
> >>> 
> >>> Because using a fixed Z timezone simplifies applications for which
> >>> xsd:datetime is only used to unambiguously encode a point in time -- not
> >>> also a location.  Again, different applications have different needs. 
> >>> 
> >>> Just because this will not help *all* applications does not mean that it
> >>> won't help *some* applications.  
> >> 
> >> It *might* help some applications (ones that don't have a
> >> xsd:dateTime / ISO 8601 library, which should hopefully be rare), but
> >> it will prevent others from working at all. That doesn't seem like a
> >> good idea to me.
> > 
> > Whoa!  Not true at all.  Again, I am *not* saying that a fixed Z
> > timezone should be used for *all* data.  Clearly in your use case where
> > timezone provenance is needed, a fixed Z timezone should *not* be used.
> > Nothing changes that.  The apps will still work fine.
> 
> How is the store to know the intent of the consumer? An xsd:dateTime
> is what it is. If there was a function to normalise the timezone
> (where that's possible) then fine, but that doesn't seem to be what
> you're asking for. 

Ah-ha!  Now I see the confusion.  Clearly the store would not know the
user's intent, so the best the store could do without user guidance
would be to retain whatever literal form the user provided on input, as
Andy has advocated (though not all stores do, BTW).

The encouragement to use canonical forms is intended toward people who
are creating/generating RDF data and have control over its
serialization.  

> 
> >>> The more we can make RDF manipulable by simple tools as often as
> >>> possible the better, even if it cannot be done 100% of the time.
> >> 
> >> I agree, but I don't think this change would do that. It would move
> >> RDF further from XML, and make it very hard to use is some common
> >> situations.
> > 
> > Can you explain?  Exactly how would encouraging the use of a canonical
> > form of an XML data type when appropriate move RDF further from XML?
> 
> You're talking about changing the recommended behaviour of one of the
> XML data types, when used in RDF. 

I don't know what change you mean.  The semantics would be exactly the
same as already established for XML data types in RDF.

> 
> > And exactly how would a canonical form be harder to consume in *any*
> > situation?
> 
> A new, non-standard canonicalisation, just for RDF? Which is a lossy
> transform? Surely that's harder to consume (in the general case).

Obviously, it should not be used at all in cases where the timezone
provenance should be kept.  It would be intended for cases in which the
xsd:datetype is *only* used to represent a point in time, and for those
cases it would simplify processing.


-- 
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 Thursday, 2 August 2012 13:18:38 UTC