Unsupported datatype - xsd:DateTimeStamp

[dr-shorthair]

@mdebellis has reported that the datatype xsd:DateTimeStamp is not recognised by Pellet, SWRL, and probably other OWL applications

This concern emerged incidentally, so I created this new issue for it.

[dr-shorthair]

Details from this comment

@dr-shorthair wrote

When we revised the 2006 OWL-Time for the 2017 version, switching to xsd:dateTimeStamp was considered to be a very useful step forward. The reasons are obvious - without timezone information, none of the topological relationships between temporal entities in the same 24 hour period can be determined. Clearly the tools have not kept up, but the requirement is clear. The datatype builds it into the language infrastructure. If the datatype was relaxed to xsd:dateTime then there would need to be external checks.

@mdebellis responded

I wanted to think about this for a bit but just for the record I disagree with this decision. First, I agree that it is kind of ridiculous that SWRL doesn't support xsd:dateTimeStamp but even if it did I would still disagree with this decision. The reason is that IMO these vocabularies should be all about reuse. So if you want to do reuse you don't want to impose your design decisions on the users. I don't know what your real world experience with ontologies has been but in my experience I have to deal with all sorts of existing requirements that don't make sense but can't be changed. I.e., it is quite possible that someone may want to use the Time ontology and have to work in a system that uses xsd:dateTime because there is some other database that uses that datatype and the datatype can't be changed without breaking existing code. So is it really rational to say to such people:
"well sucks to be you, you should design your systems better"?? I see the point about time zones and agree they are a good thing but you can still use them with xsd:dateTime, they just aren't mandatory. So you put a warning in the documentation and the ontology that says: make sure you use time zones if you use xsd:dateTime. A while ago I studied some of the design documents around SKOS and one thing I loved that I think many vocabularies (e.g., BFO and in this case the Time ontology) ignore is something that Tom Gruber coined in a short paper called I think "the principle of least ontological commitment" The point was that an ontology language (and in the opinion of the SKOS designers and me also a vocabulary) should try to be as minimal on design decisions as possible. Leave those things to the user, those are their decisions. Reusable assets should be as open and free of such commitments as possible. Anyway, just my opinion.

[dr-shorthair]

Thank you for your comments @mdbellis

First I should note that OWL-Time is not currently under consideration for revision, so even if we agreed that they were warranted, I'm unclear if any changes can be made at this point. My understanding of W3C processes are incomplete however.

On to the substantive issue: when the SDWWG converted OWL-Time from a Draft (2006) to a Recommendation (2017), a constraint was that it should be backward compatible as much as possible. This unfortunately meant that we had to retain many and varied ways to express temporal position, as well as the temporal relations (the Allen algebra).

Backward compatibility is assessed at the instance level - instances of OWL-Time-2006 should be allowed by the 2017 version of the Ontology. So while :inXSDDateTimeStamp added, and :inXSDDateTime deprecated, the deprecation is only an annotation, and the property was not deleted

• see note at https://www.w3.org/TR/owl-time/#x2017-version.

Nevertheless, testing was cursory. It seemed like a good idea at the time, and no-one pushed back, so it stayed.

With hindsight I'm inclined to agree with you that it was a mistake.

In hindsight also I would like to have separated the topological parts of OWL-Time (i.e. the temporal relations*) from the positional parts (i.e. all the various ways that temporal position can be expressed). This could have allowed OWL-Time to be formulated as a set of profiles suitable for different applications. For example, while geological and archeological applications can use the same temporal relations, the way that time position in those application is expressed is very different to how it is in transaction records or travel itineraries. Each application profile should be able to constrain the ways that temporal position is expressed to the appropriate datatypes - we don't need timezones for geological dates!

*(It is the relations that are really the interesting part of OWL-Time, as also shown by the subsequent Extensions to the OWL-Time Ontology - entity relations note.)

[PeterParslow]

This seems to be an instance of the perennials design argument about how much of the semantics of a property should be encapsulated in its data type (allowable target) and how much "elsewhere" (the semantics of the property).

In this example, xsd:dateTimeStamp is a data type that is more semantically precise than xsd:dateTime and is therefore appropriate for some properties but not others. Same sort of thing applies to "length" vs "distance".

Whether the semantics should be captured in the relationship or the target differs with the design decisions embedded in different encodings (for want of a better word!).

[mdebellis]

Thanks for the explanations. That makes sense, sorry if I came off a bit hot headed. I didn't know that Time wasn't being revised anymore. IMO that's too bad because the domain is a very important niche for a reusable vocabulary and of all the models out there Time is the best. I also like the idea of different profiles very much. For now, given the problems with SWRL I'm not going to work on this more but at some point I may develop some Python code that can do the same as the SWRL rules only much faster. Unfortunately, that will be bound with some Python library but it still might be useful to others. Cheers, Michael

…

On Tue, Oct 3, 2023 at 12:45 AM Peter Parslow ***@***.***> wrote: This seems to be an instance of the perennials design argument about how much of the semantics of a property should be encapsulated in its data type (allowable target) and how much "elsewhere" (the semantics of the property). In this example, xsd:dateTimeStamp is a data type that is more semantically precise than xsd:dateTime and is therefore appropriate for some properties but not others. Same sort of thing applies to "length" vs "distance". Whether the semantics should be captured in the relationship or the target differs with the design decisions embedded in different encodings (for want of a better word!). — Reply to this email directly, view it on GitHub <#1435 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7TPBEWYBPIWF3VIZE7L6LX5O7AVAVCNFSM6AAAAAA5QK4SOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBUGM4DKMJRGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dr-shorthair]

sorry if I came off a bit hot headed

Not at all. Your comments were well motivated and well explained.