Re: ISO8601 for dates?

What about OWL Time [1]?

--Paul

[1] https://www.w3.org/TR/owl-time/

On 10/15/25 08:21, Robert Sanderson wrote:
>
> Hiyas,
>
> Yes, though it would be good to formalize how to refer to years before 
> 0 CE, including years with more than 4 digits. For example, 66 million 
> years ago is the end of the Cretaceous period. It's allowed in ISO8601 
> to have more than 4 years (at least according to wikipedia) so long as 
> there is agreement in advance.. we should establish that agreement for 
> RDF  / JSON-LD usage if possible.
>
> Rob
>
>
> On Tue, Oct 14, 2025 at 11:34 AM Benjamin Young 
> <byoung@bigbluehat.com> wrote:
>
>     Hi all,
>
>     There's an ancient issue in RDF land with modeling dates and times
>     well. Generally, you have to "pick a lane":
>     * do I want just a "date" (xsd:date) with no time expression
>     * do I want a "date + time" (xsd:dateTime) where every date MUST
>     come with a time
>     * do I want just "time" (xsd:time)
>
>     The pain shows up when you try to model/express/hold a date
>     *and/or* time in a single field—which is not uncommon in event
>     systems, etc.
>
>     What most "just JSON" developers seem to want (or expect they can
>     have) is something closer to ISO8601 where there's one date(and/or
>     time) format "to rule them all" such that a single field can hold:
>     * 2025-10-14 (date)
>     * 14:04:51Z (time)
>     * 2025-10-14T14:04:51Z (date and time)
>
>     The Wikipedia page for ISO8601 has some more examples:
>     https://en.wikipedia.org/wiki/ISO_8601
>
>     I realize y'all know all of the above. ;) What I'm pondering is
>     would JSON-LD/RDF benefit from a defined ISO8601 datatype to
>     support these (and more)?
>
>     There is, in fact, RFC5141
>     <https://www.rfc-editor.org/rfc/rfc5141.html> which defines URNs
>     for ISO specs, so in theory, this could look something like the
>     following:
>     <#thing> <createdOn> "2025-10-14"^urn:iso:std:iso:8601
>
>     Obviously, choosing this datatype does push the "understanding" of
>     what's inside to...well...what's inside, so there are still valid
>     reasons to use the XSD datatypes which provide a clearer "look
>     before you leap" experience. However, what this ISO8601 datatype
>     could provide is scenarios (which are all too common...) where
>     `xsd:dateTime`is chosen but with the full expectation by the
>     ontologists that the time may be set to `00:00:00` and *not* mean
>     midnight, but instead mean "ignore the time".
>
>     So, I realize this is an antique issue/topic and this may not be
>     anything like a solution for all the problems...but I thought I'd
>     propose it and get some feedback. :)
>
>     Thanks for entertaining this idea!
>     Benjamin
>
>     --
>     https://bigbluehat.com/
>     https://linkedin.com/in/benjaminyoung
>
>
>
> -- 
> Rob Sanderson
> Senior Director for Digital Cultural Heritage
> Yale University