Change the range of ceterms:foundingDate from xsd:dateTime to rdfs:Literal

[siuc-nate]

In order to enable entry of partial dates in a way that is universally flexible, we should change the range of ceterms:foundingDate from xsd:dateTime (which requires a full date) to rdfs:Literal (which allows "1995", "January 2012", "3/2011", etc).

This date is not a critical element used in any calculations anyway, and is typically just a point of trivia or interest in regards to an organization, so I do not see a downside.

we would also likely want to remove foundingDate as a subproperty of ceterms:temporalCoverage.

[cwd-mparsons]

I would prefer only number.
The downside would being able to do minimum validation.
Requiring a number (for each section), prevents spelling issues, as well as use of multiple languages.

[siuc-nate]

If we only want a number, then I think a "foundingYear" (and potentially foundingMonth and foundingDay) property would make more sense.

[stuartasutton]

As I noted in #370, I don't see why this simply can't have a range of xsd:date.

[siuc-nate]

We want to enable entry of partial dates (such as the founding year, sometimes with a month) and not require a full date for this property.

[stuartasutton]

OK, so what's wrong with xsd:gYear (https://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes)

[siuc-nate]

gYear wouldn't allow a value like "January 2001", only the number 2001.

If foundingDate should permit any portion of a date, I think it should be a Literal.

If foundingDate should only be the year, I think we should still make it a Literal and create a "foundingYear" property that could then use xsd:gYear

if foundingDate should permit only a full date, then we can use it as-is (albeit with a change to xsd:date instead of xsd:dateTime)

Ultimately founding date is mostly just an informational property rather than something that needs to be strictly controlled for use in calculations, sorting, etc., unless you have some niche system that groups organizations by how old they are (in which case foundingYear would likely be adequate, unless you have a number of organizations that were created in the same year), which may be an edge case beyond something we need to burden the majority of schema users with.

My proposal is thus:

• Change the range of foundingDate to a Literal
• Create a foundingYear property with a range of xsd:gYear

Alternatively (perhaps this meets all needs?):

• Change the range of foundingDate to xsd:date
• Create a foundingYear property with a range of xsd:gYear
• Create a foundedOn property with a range of Literal

An entry system such as our editor could present a text field to the user and if they happen to enter a complete date, store the information within foundingDate, otherwise store it within foundedOn (perhaps with a similar check to see if they only entered a year?)

[siuc-nate]

Per our 4/7/2017 call:
We will change the range of ceterms:foundingDate to rdfs:literal.

Action to be taken:

Remove

Subject: ceterms:foundingDate
Predicate: rdfs:range
Object: xsd:dateTime

Add

Subject: ceterms:foundingDate
Predicate: rdfs:range
Object: rdfs:literal

[siuc-nate]

This change has been made in pending CTDL and noted in history tracking.