The file time-prov.ttl provides a non-normative alignment between OWL-Time and PROV-O. One of the included suggestions is an alignment of the time:inXSDDateTimeStamp with the currently-deprecated property time:inXSDDateTime.
This patch drops that suggested alignment, for two reasons:
Entailment, in both RDFS and OWL semantics, would cause any usage of time:inXSDDateTimeStamp to induce usage of time:inXSDDateTime in the graph, which could raise OWL warnings about usage of a deprecated property.
A triple X time:inXSDDateTimeStamp Y would be required by the range of time:inXSDDateTimeStamp to have Y bear the datatype xsd:dateTimeStamp. Entailment, in both RDFS and OWL semantics, would induce a triple X time:inXSDDateTime Y, with the same subject and object as in the original triple. The literal Y would have an incompatible datatype with the range of the induced time:inXSDDateTime triple, because a second datatype could not be assigned to it per RDF design.
This contribution is made only by myself, and is not being made by the National Institute of Standards and Technology or any other organization.
The XML Schema Datatypes rec specifies that xsd:dateTimeStamp is a specialization of xsd:dateTime, requiring the optional time-zone information to be present. Doesn't that resolve the problem?
The file time-prov.ttl provides a non-normative alignment between OWL-Time and PROV-O. One of the included suggestions is an alignment of the
time:inXSDDateTimeStamp
with the currently-deprecated propertytime:inXSDDateTime
.This patch drops that suggested alignment, for two reasons:
time:inXSDDateTimeStamp
to induce usage oftime:inXSDDateTime
in the graph, which could raise OWL warnings about usage of a deprecated property.X time:inXSDDateTimeStamp Y
would be required by the range oftime:inXSDDateTimeStamp
to have Y bear the datatypexsd:dateTimeStamp
. Entailment, in both RDFS and OWL semantics, would induce a tripleX time:inXSDDateTime Y
, with the same subject and object as in the original triple. The literalY
would have an incompatible datatype with the range of the inducedtime:inXSDDateTime
triple, because a second datatype could not be assigned to it per RDF design.This contribution is made only by myself, and is not being made by the National Institute of Standards and Technology or any other organization.