W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > April 2018

Re: [dxwg] Temporal coverage [RTC]

From: Dan Brickley <danbri@google.com>
Date: Mon, 23 Apr 2018 08:42:49 +0000
Message-ID: <CAK-qy=4abGgFaRKJ9CKKWTYrqq=9yG+MJoJpXLRZrXghSjkemA@mail.gmail.com>
To: Andrea Perego via GitHub <sysbot+gh@w3.org>
Cc: Dataset Exchange Working Group <public-dxwg-wg@w3.org>
Just to note that regarding the Google work we are aiming to just use
standard Schema.org with nothing Google specific beyond the choice of idiom
(graph shape / application profile etc.). The wider community periodically
discusses the need for a clearer guidance on iso durations which are
openended btw, it would be fantastic if dxwg could help progress that

On Mon, 23 Apr 2018, 00:46 Stijn Goedertier via GitHub, <sysbot+gh@w3.org>

> Thanks, Andrea. I agree with your feedback that multiple, non-contiguous
> intervals would require several dcterms:temporal instances. This is
> probably based on the definition of [dcterms:PeriodOfTime](
> http://dublincore.org/documents/dcmi-terms/#terms-PeriodOfTime), which
> reads: _An interval of time that is named or defined by its start and end
> dates._
> I did not get from the use case that we want a more "flat" alternative,
> but in this case the Google ([schema:temporalCoverage](
> http://schema.org/temporalCoverage)) approach using the ISO 8601 time
> interval notation indeed makes sense. OWL Time does not seem to have have a
> property for representing time intervals as a literal like that.
> --
> GitHub Notification of comment by stijngoedertier
> Please view or discuss this issue at
> https://github.com/w3c/dxwg/issues/85#issuecomment-383484132 using your
> GitHub account
Received on Monday, 23 April 2018 08:43:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:28:22 UTC