RE: Temporal validity: alternative for dcterms:valid?

> 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.) 

Simon  

-----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 Tuesday, 12 January 2016 21:13:43 UTC