Re: [sdw] Implementation of SWRL Rules for Time Ontology (#1434)

> 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.

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. 

-- 
GitHub Notification of comment by mdebellis
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1434#issuecomment-1740377506 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 29 September 2023 06:33:45 UTC