Reconsider usage of xsd:date

[siuc-nate]

We have current use cases that require support for partial dates, e.g. 2024-08 and/or 2024, which I thought were supported by xsd:date, but actually are not (ISO8601, which xsd:date is based on, supports them, but not xsd:date itself).
https://www.w3.org/TR/xmlschema-2/#date
https://www.w3.org/TR/xmlschema-2/#isoformats
https://www.w3.org/TR/xmlschema-2/#truncatedformats

Right truncated formats are also, in general, not permitted for the datatypes defined in this specification with the following exceptions: right-truncated representations of dateTime are used as lexical representations for date, gMonth, gYear.

I can see two potential solutions:

• Replace our usage of xsd:date with schema:Date (which uses ISO8601 directly and thus allows the year and year-month formats, but also allows other things we don't necessarily want to account for), or
• Update the ranges of properties that currently use xsd:date to also include xsd:gYearMonth and xsd:gYear (which have stricter rules, but may be closer to what we want)

The second option is probably the safer of the two, as it avoids opening the door to other variations/truncations ISO8601 allows. That would also give us the flexibility to allow/deny, for example, YYYY-MM-DD and YYYY-MM formats but not YYYY formats for some properties (if we ever wanted to do that).

We only need to update the properties where we specifically want to allow partial dates, but if we were to update all properties with a range of xsd:date, the list would be:

• ceterms:alignmentDate
• ceterms:dateEffective
• ceterms:endDate
• ceterms:expirationDate
• ceterms:startDate
• ceterms:temporalCoverage
• ceasn:dateCreated
• ceasn:dateModified
• ceasn:repositoryDate

Note: I can't think of a case where we need to worry about partial xsd:dateTimes, so we're probably okay with those properties as-is, but they're worth considering, too.

[philbarker]

For what it is worth I tend to use the latter approach, gYear, gYearMonth and the like.

[siuc-nate]

That's what I'm currently leaning towards as well.

[philbarker]

@siuc-nate one fly in the ointment with allowing more than one datatype for the date properties is that currently the context file has things like

    "ceterms:dateEffective": {
      "@type": "xsd:date"
    },

That would have to be removed and cannot be replaced if the datatype for values could be one of several options. The only way to specify the data type would be in the instance data, e.g.

     "@id": "http:example.org/something",
     "ceterms:dateEffective": {
        "@type": "http://www.w3.org/2001/XMLSchema#gYear",
        "@value": "2011"
      } 

Alternatively, use "duck typing" on ingest (from the options in the property's range) as we discussed on the last call.

[siuc-nate]

I wasn't aware of that limitation of JSON-LD until just now. That's really unfortunate and doesn't make much sense to me, but appears to be true. I went to see how schema.org handles multi-typing in the schema.org context file and found the following, some of which are odd to me:

• https://schema.org/birthDate can only be Date, and is marked as such in the context file
• https://schema.org/dateSent and https://schema.org/dateReceived can be DateTime, but do not have a type in the context
• https://schema.org/jobStartDate can be Date or Text, but does not have a type in the context file
• https://schema.org/datePosted can be Date or DateTime, but is only marked as Date in the context file
• Nothing in the context file has a type of DateTime, so maybe there is some reason they aren't using that at all there?
• Most things in the context file don't have type declarations, which I assume is because many things can be multiple types

This makes me question the usefulness of providing anything in the context file after the first block that provides what the URL prefixes map to. A consumer of the data is going to need to get the actual schema one way or another in order to find out what the ranges of properties are (especially for properties that are explicit URLs vs general URIs, as discussed elsewhere (#819)).

Also, the JSON-LD playground complains if you try this:

Perhaps we should remove all of the @type references from our context as well, so as not to mislead consumers of the data?

[philbarker]

I wasn't aware of that limitation of JSON-LD until just now. That's really unfortunate and doesn't make much sense to me,

I'm afraid it's necessary. The context block maps values in the JSON objects to RDF, and it can only do a one-to-one mapping that works for all values, so yeah if you give it an array and say the value may be any one of these three datatypes you're not giving it information that will work.

Perhaps we should remove all of the @type references from our context as well, so as not to mislead consumers of the data?

Then everything would be xsd:strings, which probably isn't an improvement.

Setting the range to xsd date, gMonth, gYear and the @type in the context to schema:Date would not be wrong as those are all formats that are compatible with being a date value in ISO 8601 date format.

The alternative is Rohit's suggestion of a different property for each datatype.

[siuc-nate]

Then everything would be xsd:strings, which probably isn't an improvement.

Wouldn't that also be a problem for schema.org's context? They don't specify a type value (in the context) for the vast majority of their properties, not even ones that would make sense as @type: @id. I think we create more confusion than we solve by specifying some types, but not others, or specifying them with a lesser degree of precision than that provided by the schema:rangeIncludes values for those properties. If people can figure out how to use schema.org's context with that as a limitation, it should work for us too, I'd think.