W3C home > Mailing lists > Public > public-lod@w3.org > January 2016

RE: Temporal validity: alternative for dcterms:valid?

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Wed, 13 Jan 2016 16:58:03 +0000
To: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "frans.knibbe@geodan.nl" <frans.knibbe@geodan.nl>
Cc: "public-lod@w3.org" <public-lod@w3.org>
Message-ID: <24637769D123E644A105A0AF0E1F92EF010D24D19D@dnbf-ex1.AD.DDB.DE>
On Tuesday, January 12, 2016 10:13 PM, Simon.Cox@csiro.au wrote:

> > an interval datatype similar to the ISO 8601 format ("2007-03-
> 01T13:00:00Z/2008-05-11T15:30:00Z") -- where start and end could be any xsd
> temporal datatype -- would be useful. Perhaps we can include that in the time
> deliverable.
> time:Interval already exists in OWL-Time, which will be the basis for the SDW
> time deliverable.
> (In fact it is the fundamental class in the Allen calculus.)

Yes, but here the idea is to create a _datatype_ so that we can use a literal (essentially a microsyntax) as the object of dct:valid, e. g. 

:someAssertion dct:valid "2015-12-31 / 2016-01-01T01:00:00Z"^^time:interval . # interval with a minor i, not the class Interval...

The temporal expressions before and after the '/' map nicely to time:hasBeginning and time:hasEnd and can thus be transformed to an instance of time:Interval (the class) and they can have different specificity (as in the example).

There is a similar proposal in EDTF [1] but there the syntax only allows year, year-month or year-month-day, and I think we should allow any of the date/time-datatypes in xsd.

[1] http://www.loc.gov/standards/datetime/pre-submission.html#interval


> -----Original Message-----
> From: Svensson, Lars [mailto:L.Svensson@dnb.de]
> Sent: Wednesday, 13 January 2016 3:41 AM
> To: Frans Knibbe <frans.knibbe@geodan.nl>
> Cc: public-lod@w3.org
> Subject: RE: Temporal validity: alternative for dcterms:valid?
> Frans, all,
> (Sorry for a latish reply, I'm still catching up on email...)
> On Thursday, December 24, 2015 4:57 PM, Frans Knibbe wrote:
> > The DCMI Metadata Terms vocabulary seems to have all the basic
> > ingredients for building a versioning mechanism in to a dataset (which
> > is or should be a very common requirement). Objects in a dataset can
> > have life spans (temporal validity), be versions
> > (dcterms:hasVersion/dcterms:isVersionOf) of another resource and replace
> each other (dcterms:replaces/dcterms:isReplacedBy).
> > But as Jeni Tennison has noted some time ago (see final section
> > 'Unanswered Questions'), a versioning scheme based on DCMI has a weak
> > spot: the property for denoting temporal validity (dcterms:valid) is
> > impractical to the point of being unusable. Dcterms:valid only takes
> > literals (rdfs:Literal) as value, which makes it hard to use it for
> > practical expressions of time intervals. Time intervals should be
> > compound objects that are based on useful datatypes. For instance,
> > xsd:dateTime (for dates) or xsd:integer (for years or seconds (e.g. in UNIX
> time)) could be used in SPARQL queries to filter or order temporal data.
> > In a versioned dataset queries like 'give me all changes between time
> > T1 and time T2' or 'give me the state of the dataset at time T3'
> > should be easy to create and to resolve. It seems to me that this
> > requires proper and well supported data types. A text string notation
> > for time intervals is recommended by DCMI: dcmi-period. It is easy and
> > versatile enough, but the average triple store probably does not recognize
> this notation as temporal or numerical data.
> > So I wonder if there is a good alternative for dcterms:valid somewhere
> > that can be used to indicate temporal validity.
> I don't have a solution but only wanted to throw in that this question was
> discussed on public-lod in November 2013 [1] and that no real conclusion was
> found there either... That said, I still think an interval datatype similar to the
> ISO 8601 format ("2007-03-01T13:00:00Z/2008-05-11T15:30:00Z") -- where
> start and end could be any xsd temporal datatype -- would be useful. Perhaps
> we can include that in the time deliverable.
> [1] starting at https://lists.w3.org/Archives/Public/public-

> lod/2013Nov/0019.html
> Best,
> Lars

Received on Wednesday, 13 January 2016 16:58:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:22:29 UTC