Schema.org provides a specification of calendar dates. For example, the @PriceSpecification property validFrom expects a beginning date (a point in time). And the property validThrough expects an ending date (also a point in time).
However, there are many contracts that specify time periods rather than specific dates/points-in-time.
Consider a software product with offer/@Offer that has an acquisition price and an optional maintenance price.
There would be two @Offer, each with a @PriceSpecification.
But we don't know the point-in-time (Date)
Instead, we should use DateTime and specify a date range e.g. @PriceSpecification/validPeriod where the offer-1 "validPeriod" is P1Y and offer-2 "validPeriod" is P2Y.
I would interpret the above to say in the vernacular: the price of the product for year 1 is (5x), and the price of the product for year 2 is (1x).
A financial lease is similar, but usually with a constant payment stream over the "validPeriod."
A mortgage is much more difficult, so let's not go there.
The type @OwnnershipInfo is similar to a software license or a lease. But the properties ownedFrom and ownedTo also are Date specific, not DateTime specific which supports time periods
How to handle this issue?
One approach might be to re-define validFrom (or ownedFrom) as either a beginning Date or the beginning of a time period.
Another approach might be to create a new property with the label validFor where values would be in the ISO 8601 time interval format
For example @CreativeWork/temporalCoverage allows ISO 8601 values.
So a third approach might be to add the property temporalCoverage to types such as @PriceSpecification.
Am I missing a solution to the time period problem for prices, ownership and leasing?
Or would one of the above make sense to add to the schema.org data model?
copying @mfhepp as GoodRelations was the source of these terms.
I think some of your answers might be found in #2689
Thanks for the link @jvandriel Jarno. Many of our issues are discussed there; in fact, our problems are a subset of that issue, so we'll participate there.
This issue is being tagged as Stale due to inactivity.
Most helpful comment
I think some of your answers might be found in #2689