Dear Ray,

On Wednesday, October 24, 2018 6:59 PM, Discussion of the Developing Date/Time Standards [mailto:[log in to unmask]] On Behalf Of Denenberg, Ray wrote:
>  From: Svensson, Lars
> > Are there any plans to register datatypes for EDTF datestrings in order to
> > transport those in e. g. RDF (à la "2001-34"^^edtf:seasonCode)?
> Glad you mentioned that.
> We registered this several years ago.
> (or in rdf: )
> We haven't publicized it, but you're free to use it, e.g.   "2001-34"^^edtf:EDTF"
> where  edtf:  is the prefix for
> There is a slight complication.  itself is a datatype
> scheme, meaning it is a group of datatypes, four of them, one for edtf in general
> and one for each level.   I am going to try to get this changed.  I don't think there
> needs to be more than one datatype (edtf general) and therefore no scheme.
> If we make this change,  you would instead say:     2001-34"^^someprefix:EDTF
> Where the prefix is for   (I don't know at this time what
> the recommended prefix will be, because we don't define any other active
> datatypes.)
> I'll keep you posted on this.

Thanks for your reply. I finally got round to have a closer look at the EDTF datatypes and my gut feeling is that they are seriously underspecified, at least if you compare them with the corresponding XSD datatypes.

My proposal would be to have several, more specific datatypes that allow a user to validate EDTF expressions on syntactic and semantic conformance. This would require us to think not only about syntax, but also about value spaces, so that an EDTF parser that encounters "2018-11"^^edtf:season would throw an error saying that "11" is not a valid season code. I _think_ that for some of the Level 0 formats we can re-use the XSD datatypes instead of defining own ones, but when it comes to season codes or uncertain dates (both of which are not specified in XSD) we'd need to figure out something on our own.

Does that make sense to you (or others in this community)?