On the definition and naming of temporal entities and their usage in the examples

[bertvannuffelen]

The definition of temporal entity in https://www.w3.org/TR/owl-time/#time:TemporalEntity is

A temporal interval or instant.

According to the figure1 is Instant (probably meaning time:Instant) a subclass of it. See https://www.w3.org/TR/owl-time/#time:Instant.

A temporal entity with zero extent or duration

This has a properties _:inXSDDateTimeStamp, etc.

In the example https://www.w3.org/TR/owl-time/#time-prov, an Activity is considered a TemporalEntity. But that seems not correct to me: it is a occurance that happened on a moment. See the definition in https://www.w3.org/TR/2013/REC-prov-o-20130430/#Activity

An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.

So an activity is manufacturing a car at 15 march 2020, but not 15 march 2020 which according to me is a temporal entity (See the other examples. Moreover an activity can have multiple temporal information aspects: started, ended, published, audited, etc... In that case the values of those aspects are for me temporal entities and not the Activity itself.

The origin of this is that one names a temporal entity. E.g. The example in https://www.w3.org/TR/owl-time/#different-TRS is giving a name ex:AbbyBirthday to the timestamp: "2001-05-23T08:20:00+08:00"^^xsd:dateTimeStamp .

So modeling a Person this is the complete example:

ex:Abby  a foaf:Person ;
      <http://schema.org/birthDate> ex:AbbyBirthday.

The above should thus be read as: Abby is a person who is born an her birthday. Including the information in the example, the reading can be added with the additional sentence: Her birthday, i.e. ex:AbbyBirthday occurs at "2001-05-23T08:20:00+08:00".

Naming temporal moments with a business interpretation has consequences. E.g. When Bob is born on the exact same timestamp as Abby, then honestly I would not advice in any digital system to reuse the name of ex:AbbyBirthDay to record the birth date of Bob. Not only to avoid misinterpretations, but also to avoid unintended connections like one has made an editorial mistake for Abby timestamp and then all of the sudden day of birth for Bob changes .

I understand that the examples are to be concise and often benefit from a business context, but here the impression is given that naming temporal entities is sensible. I think in most cases where people record temporal information there is no name for that temporal information, only a path/query on how to identify it: the date of publishing of the book, the generation time of the log entry, etc. Only is dedicated purposes where temporal reason is applied the temporal information and the business entity coincide. E.g. order all log entries according their auditing time. In those cases a projection happens from the business data to a named temporal entity having some business notion.

For instance removing the rdfs:label entries is already a step in that direction. Or at least add a disclaimer that those are added only for introducing a business context to make the example readible, but these things are outside the scope of the recommendation.

kr,

Bert

[dr-shorthair]

Thanks @bertvannuffelen

Your points are all valid. But I would suggest that some of this is just modeling choices. In particular, an event could legitimately be modeled in two ways:

• it is a (kind of) temporal-entity, or
• it is associated with a temporal-entity

So we could have defined a class Birthday and associated it with a set of individual representations of the date, in the various time systems, also with one for the conventional gregorian representation. My judgement was that this example was good enough for the main point here - illustrating the equivalence of the different representations of a time instant. If we had wanted to make a different point - for example to define a class Birthday - then the example would have looked different. So although you certainly could make a case for a different pattern, IMO there is nothing wrong with the example in context.

[bertvannuffelen]

@dr-shorthair

Your points are all valid. But I would suggest that some of this is just modeling choices. In particular, an event could legitimately be modeled in two ways:

* it  _is_ a (kind of) temporal-entity, or

* it _is associated with_ a temporal-entity

For me the above modelings are different. When modeling real world entities I would use the second case, because it allows to express the temporal dimension semantics. The first I would use in the context of temporal reasoning, after selecting the temporal dimension semantics.

These are different use-cases, and unfortunately when reading quickly the examples one get the impression that the first case is the desired usage. It took me a while and (re)reading to understand what was happening in the examples. That is the motivation for this comment.

So an example where an event/business entity is modeled with 2 or more temporal dimensions illustrating the second case would be helpful.

ex:dataset1
     dct:issued ex:time1
     dct:modified ex:time2