- From: Alex Nelson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 May 2023 19:31:00 +0000
- To: public-sdwig@w3.org
ajnelson-nist has just created a new issue for https://github.com/w3c/sdw:
== TIME: time:inXSDDateTime deprecation impact on PROV alignment and other use cases ==
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](https://www.w3.org/TR/2022/CRD-owl-time-20221115/#time-prov).
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.:
```turtle
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.
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1421 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 12 May 2023 19:31:02 UTC