- From: Simon Cox via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 Apr 2018 00:32:04 +0000
- To: public-sdwig@w3.org
> If you choose to use them, the tool behavior is not predictable. Indeed. See also the notes regarding OWL processing of the new datatypes here https://www.w3.org/TR/owl-time/#Datatypes As mentioned above, we had competing demands. It was felt, given the lengthy period in which the 2006 draft had been on the books and in use, that backward compatibility was very important. So we left the global range constraints on day, month and year in place. We also introduced generalized versions for non-gregorian calendars. The Recommendation went through the full W3C process and was available for review as a draft, proposed rec, and candidate rec prior to adoption and we did not receive any comments on this issue. The OWL-Time ontology is pretty messy in that it provides multiple options for encoding temporal position - see https://www.w3.org/TR/owl-time/#time-position. IMO the encoding issue would have been best left to a separate layer, with OWL-Time only addressing the conceptual model, but that probably would have surprised practitioners. So we just tried to rationalize what was there, and accommodate the additional requirements to support non-gregorian calendars and longer time periods and deeper time positions - the latter requiring temporal coordinates rather than date-time style encoding. When adopting an RDF vocabulary you will often choose to ignore or suppress some elements. There are RDF technologies to support this, such as SHACL. Perhaps that can help your application? I know OMG likes to have exhaustive automation, but in this case it may have to be partial. -- GitHub Notification of comment by dr-shorthair Please view or discuss this issue at https://github.com/w3c/sdw/issues/987#issuecomment-383424904 using your GitHub account
Received on Monday, 23 April 2018 00:32:27 UTC