- 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