TIME: time:inXSDDateTime deprecation impact on PROV alignment and other use cases

[ajnelson-nist]

A while ago, I came across this file offering an alignment of TIME and PROV:

https://github.com/w3c/sdw/blob/gh-pages/time/rdf/time-prov.ttl

I also see from the commit history that the file is non-normative. However, there is a part of it---the subject of this Issue---that is part of the TIME examples today (also non-normative), in Section 5.7.

Are there any plans to keep the alignment file in sync with the current state of TIME, and how that might influence an update to PROV? I ask because there appears to be a pending alignment issue. time:inXSDDateTime is deprecated, and some properties in that alignment graph map from PROV to the deprecated property, e.g.:

prov:endedAtTime
  owl:propertyChainAxiom (
      time:hasEnd
      time:inXSDDateTime
    ) ;
.

Unfortunately, prov:endedAtTime has range xsd:dateTime, so that propertyChainAxiom can't just swap in time:inXSDDateTimeStamp -- unless I've missed there's some mechanism that can get OWL to recognize that xsd:dateTimeStamp is a subclass of xsd:dateTime. (My current understanding is OWL 2 doesn't do "subdatatypes." There's no need to belabor this point in conversation, it's more an aside.)

I appreciate that alignment graph (and example section) is non-normative, but does it actually impose a constraint on the next TIME version's W3C progression? Or, could it again be "non-normatively" updated to insert a timezone-assigning step in the property chain?

Relatedly, it wasn't clear to me from the examples how one would "upgrade" a xsd:dateTime value to an xsd:dateTimeStamp. So, I'm not sure what an updated property chain axiom would need to include as further property-steps. Could an example be provided showing what one would do if they truly only have xsd:dateTime values? This could benefit several use cases beyond PROV, such as:

1. Mapping from a current ontology that uses xsd:dateTime instead of xsd:dateTimeStamp. (PROV is one example. PROV-O includes no mention of xsd:dateTimeStamp.)
2. Working with data that is missing time zones, such as FAT-formatted file systems, or databases that did not require time zones in their time column definitions. For these cases, seeing demonstration of time:timeZone could prevent a lot of confusion.

[dr-shorthair]

Thanks for this comment.

You have hit various nails on their heads, most of which I was aware of when I prepared the alignment:

• the relationship between xsd:dateTime and xsd:dateTimeStamp
• the difficulty of working with DataTypes in property chain axioms
• the fact that PROV uses XSD datatypes directly instead of TIME entities

I do not have a solution to any of these, which is why the whole thing is 'informative'. It was really just intended to provided general guidance about how things are conceptually aligned, rather than a formal axiomatization. There are currently no plans to revise or update OWL-Time, so as far as I am concerned these artefacts will just sit there, informatively.

Do you have stronger suggestions?

[ajnelson-nist]

Thank you for the reply, @dr-shorthair . Here is what I would suggest, after having tinkered with workarounds:

• In the non-normative alignment graph, the property chain axioms should probably be dropped, if they would lead one into a deprecated property.
• In the examples section (5) in the OWL-Time document, it would be beneficial to have an example of how to "upgrade" xsd:dateTime data to arrive at time:Instants using time:inXSDDateTimeStamp, if this is technically possible in only OWL-Time. I have a short loop, where I start out thinking "It's gotta be doable; it's gotta involve time:timeZone, I must have missed something;" stepping back to that property's domain time:GeneralDateTimeDescription; and going back to start with "I guess not" on not seeing an xsd:dateTime-valued property, repeating after a few months. If there is a path to follow through purely OWL-Time classes and properties, that would be good to know; if timezone assignment must be handled with some other programming language (including SPARQL), that would also be good to know.
• Out of scope of OWL-Time, updates to PROV-O could be beneficial for this alignment issue. An update could allow those timestamp properties to have a union-range of xsd:dateTime or xsd:dateTimeStamp. Due to scope this is mostly an aside, but do you happen know: is this GitHub Issue tracker (w3c/sdw) where issues for PROV-O should be filed? I have some unrelated technical issues I'd like to report.

[dr-shorthair]

Thanks @ajnelson-nist - could you prepare a PR?

[ajnelson-nist]

@dr-shorthair I've prepared the following two PRs, the second I noticed as I was preparing the first:

• PR 1428
• PR 1429

[dr-shorthair]

The main problem is caused by the fact that PROV uses xsd:dateTime, while in OWL-Time we preferred xsd:dateTimeStamp and thus deprecated time:inXSDDateTime in favour of time:inXSDDateTimeStamp. The motives for doing this are sound in principle - OWL-Time should be modeling best practice, which is to make the timezone information mandatory. But the rest of the world (specifically PROV-O) has not necessarily caught up.

Furthermore, while time:inXSDDateTime is formally marked rdf:type owl:DeprecatedProperty and owl:deprecated true, these are merely annotations. What real effect do they have on applications?

The background problem - which we can't solve here - is that dependencies between standards and their revisions are not synchronised. The original OWL-Time was a W3C Draft published in 2006. PROV-O came out in 2013. The Rec version of OWL-Time was released in 2017 (the Candidate Rec dated 2022 merely adds the IANA clause). The Rec preserved everything from the 2006 version in service of backward compatibility, but marked a few things 'deprecated' where we judged that best practice had moved on. (Frankly a clean re-design would have junked a whole lot of fluff, particularly around encoding of temporal position such as we are dealing with here, but we had to accommodate the fact that it was already a widely known 'ontology', and avoid making breaking changes.)

So how does that play out? We thought that marking some resources 'deprecated' but not actually removing them was the right thing to do. So time:inXSDDateTime is formally marked rdf:type owl:DeprecatedProperty and owl:deprecated true. But these are merely annotations. So what effect do they have on applications? And in what environments?

The process of developing and formalising 'standards' involves many compromises and quite a few judgment calls. You are proposing a minor change to a non-normative artefact, and frankly you may be the only person that has tried to actually use it 'in anger' ;-) But we must be aware of process and precedent here.

[chris-little]

@dr-shorthair @ajnelson-nist This is probably not a very constructive comment, but it does reveal my thinking (which may be unrealistic!). This is very reminiscent of the old joke with "I wouldn't start from here". Both Calendars and Time-zones are complicated messy beasts that are algorithm driven, often with ill-defined algorithms. I think supporting, and therefore encouraging, people to automatically directly manipulate data with time zone annotations is questionable. I would rather people were encouraged to go along the road of 'convert your data from time zone annotation to UTC' then manipulate. From my limited perspective, with not knowing the full ramifications, I have no objection to the PRs.

[PeterParslow]

Actually, Time-zones are created by administrative bodies and are therefore not at all amenable to being derived by algorithms! I thought that US time zones were agreed at their "county" level, and perhaps they are - but US friends tell me that that doesn't mean a whole county is necessarily in the same time zone...

That supports Chris's idea; of course, it requires a mechanism to reliably convert from a time zone annotation to UTC.