EO QB inconsistent use of qb4st:TemporalProperty (QB4ST ontological commitment is too strong)

[VladimirAlexiev]

https://w3c.github.io/sdw/eo-qb/#OWL-Time:

:time a qb:DimensionProperty, qb4st:TemporalProperty ;
    rdfs:range xsd:dateTime ;

is not consistent with the definition

qb4st:TemporalProperty a rdfs:Class, owl:Class;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty rdfs:range ;
        owl:someValuesFrom time:Interval ;
     ]  ;

because time:Interval cannot be a simple literal.

I rather like using simple literals where sufficient, and I think that qb4st:TemporalProperty (and in general QB4ST) makes ontological commitments that are too strong... But anyway, this class should not be used here

[rob-metalinkage]

QB4ST is a note, in this case somewhat of a placeholder for important concepts that should not be reinvented, but for which nothing exists. In reality there is very little or poor semantic description of data and services in the world, so it remains untested, particularly the balance between ontological commitment and not saying anything useful at all. We may need more general superclasses and usefully narrowed subclasses - Time is an area where its hard to get a read on how specific practices - in general time is really an interval - even if its expressed as a DateTime instant it is potentially indicative of an interval - for example an hour.

probably the range ought to be time:TemporalEntity and we should create subclasses for instant and interval so people can express precise semantics.

feedback on what is missing and what can be relaxed is welcome and I will try to collate for a future iteration.

[VladimirAlexiev]

CIDOC CRM has the view that "time is always an interval". But in most cases, for all practical purposes, the observation time of a sensor is an instant. Let's not create spurious complexity where simpler mechanisms can be used.