Process start and end time/date

[johnwjudkins]

Should these be in COB, and if so, how should they be represented?

Related: https://github.com/OBOFoundry/COB/issues/35

[ddooley]

I envision these as time measurement datums which can be about a given process. How their values are specified is a separate matter. The values could be xsd:dateTime etc, or possibly some other time format such as relative days/monthis/years etc, or even a count of tree rings say.

(At moment however IAO time measurement datum has an axiom that it IS a duration of a process, but that seems too general to be helpful. Perhaps that was generally intended to describe the process of elapsing time, or say, Gregorian calendar elapsing time?)

[wdduncan]

I've encountered data sets in which only the month and year was provided (no day). In for xsd:datetime to work, you have to impute at day (e.g., 15th of each month).

[ddooley]

Yes, that's why I suggest these are datums, perhaps time measurement datums, but not specify how the value must be supplied. One could then as desired subclass these to add classes with constraining axioms about how the value must be supplied (by data property, by value specification, string, xsd:datetime, integer etc.)

[edit: p.s. in past I considered a precision one could attach to a datetime field, which could be a unit such as "month". but of course that would basically be a parameter in a comparison operator that has to be interpreted outside of OWL.]

[wdduncan]

@ddooley Sorry, I didn't catch that.
I think there is pragmatic value if having simple data properties such as start_datetime, end_datetime, start_year, end_year, etc. (these are only suggested labels), since these cover a many (perhaps most) of the use cases.

That is not to say that there are cases when having a datum is helpful. Perhaps the above can be viewed as "shortcut data properties".

[ddooley]

I can see the data properties you propose would probably be used trillions of times!

[wdduncan]

@ddooley I guess that's a good thing? :)
I implemented something similar for a large dental data project I worked on.

[ddooley]

Any objections to allowing some WC3 OWL-Time into COB/ OBOFoundry? I looked at their relations:

We could model that processes have hasBeginning, hasEnd, and hasTemporalDuration via time ontology, but not import any of the other OWL-Time relations between temporal entities. We could use the RO Allen interval relations to establish dependencies between processes instead. The attraction here is that time ontology already has the different granularity expressions of time (to year, month, week etc) covered.

[ddooley]

COB could have a measurement datum about a process beginning time or end time or duration, with unit and decimal or date time. Or could consider allowing the time granularities of OWL-Time, either as time:Duration, time:GeneralDurationDescription, or time:hasXSDDuration.

[wdduncan]

@ddooley Sorry, I'm not quite following how you are proposing to fit the Time Ontology's properties into COB.

Are proposing to:

1. Add data properties to measurement datum (about a process) to capture beginning, end, and duration?
2. Add time measurement datum to COB with aforementioned data properties?
3. Apply the data properties directly to processes?

I am in favor of #3. We need simple ways to represent quantitative information about processes.

We can also use the attribute value pattern I described in #187. E.g.:

:process1 :has-attribrute-value :time-value1 .
:time-value 
  a time-stamp-value;
  :has-begin-datetime "2020-01-10"; 
  :has-end-datetime "2021-01-01" .

I used "datetime" at the end of ":has-begin-datetime" and ":has-end-datetime", to make it clear what the datatype is. Other properties can of be added, such as a simple occurrence-datetime property for cases in which we only know that a process happens on particular date.

IMHO, I would reserve measurement datum for cases in which there is a clear case of the information being the output of some process and it is important to do so. For example, experiments in which the temporal information was produced by a specialized instrument, and it is necessary to capture that information was produced by that specific instrument (type).

Not sure about adding time measurement datum to COB. If we are allowing temporal information on measurement datum, does time measurement datum do any extra work? Developers can always add it to their ontology if they think it does.

[cmungall]

We have many concepts labeled date in OBO:

• SubClassOf zero-dimensional temporal region (ONTONEO)
• a data property, mapping between 1d temporal region and string (http://purl.obolibrary.org/obo/OMRSE_00000136)
• time measurement datum (FLU, STATO -- "time stamped measurement datum")
• a subclass of date food product (???) (FOODON)
• a "name of temporal region" (APOLLO_SV)
• ....

[ddooley]

FoodOn's "date" has been renamed "date (food)" in draft, soon to be released. As for the rest, I think that proliferation is partly a function of not having a comprhehensive, proscribed way to attach dates to processes (hence proposal above, and yes Bill it would be neat to have "process" be able to be typed to a time:TemporalDuration directly, but do logicians object?); nor of having a proscribed way to attach time instance or durations as datums - a prescription being proposed in QQV).

[alanruttenberg]

Thoughts, no strong opinions.

• The only one that I think gives reasoning leverage is to use xsd:dateTime or xsd:dateTimeStamp. The latter is preferable because it is a total order whereas since the time zone isn't required for xsd:dateTime order is not defined for some pairs.
• In some conversations for some work I was doing a preference was expressed for capturing the precision by a separate property rather than implicitly by, say, the number of digits or components in the time expression.
• In the OHD we landed up using an ad hoc property linking a dental procedure to a date as we didn't need finer granularity. If this is a common enough need (only need precision to the day), then perhaps add something for that.
• The time ontology has a bunch of different ways of expressing the same time, so it's not so easy to search for time within a range. It might be useful in some contexts, not sure it is here. A number of the datatypes they use are outside the OWL datatype map. IIRC the Allen relations are already in RO.
• Directly linking to process makes practical sense to me. It would be effectively a shortcut instead of relating to first and last instant via occupies temporal region to process.
• Rather than measurement datum, value specification might make more sense.
• Overall, I think it might be premature to add to COB unless there's a clear enough widespread use and the global requirements are understood.
• If something is to be put in I'd suggest offering two ways: 1) use xsd:dateTime or preferably xsd:dateTimeStamp for start and end points or 2) Use a time value specification about the process and let development of kinds of time indicators evolve as subclasses of the value specification. Add a new subproperty of 'is about' that makes it clear that the specification is of the extent of the process.

[wdduncan]

In the OHD we landed up using an ad hoc property linking a dental procedure to a date as we didn't need finer granularity. If this is a common enough need (only need precision to the day), then perhaps add something for that.

Agreed. In my experience (both in the dental domain and beyond), only the month/day/year is needed. What is the best way to do this? We've all seen databases that have a start date and end date with start date == end date used to represent things that happen on a single day (with the times being same too). I find this approach inelegant, although it gets the work done.

Perhaps something like the following would work:

• occurrence date
  • start date
  • end date

There should be a means for representing dateTime and time zone information as well.