Re: Temporal validity: alternative for dcterms:valid?

Hello Simon, Lars,

I notice a friction between a standard for a temporal property (dcterms:valid
in this case) and standards for expressing time on the other hand. A
solution does not necessarily have to found at the side of the time data
type. In this case, if dcterms were to change the range restriction the
problem would be solved too. I can imagine that there are other
vocabularies that assume time can always be captured in a single literal.
Perhaps that needs to change?

Greetings,
Frans

P.S. we know each other from the public-sdw-wg list, but this discussion is
taking place on public-lod. I thought perhaps you hadn't spotted that.



2016-01-13 21:43 GMT+01:00 <Simon.Cox@csiro.au>:

> OK - I understand.
>
> However, I'm generally wary of inventing new microsyntaxes.
> We already have
> (i) time position - 7 information items in a string
> (ii) WKT
>
> Back in the day I was responsible for developing DCMI:Period, DCMI:Box,
> DCMI:Point. I now regret those, since it was essentially just about field
> separators and punctuation. Since XML was emerging at the time it was all
> rather unnecessary.
>
> Now we have RDF for structuring complex data, so best not create more
> syntax.
> (yes, I know the "/" interval separator is in ISO 8601, but didn't make it
> into XML, so there is no software to support it. )
>
> Simon
>
> -----Original Message-----
> From: Svensson, Lars [mailto:L.Svensson@dnb.de]
> Sent: Thursday, 14 January 2016 3:58 AM
> To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; frans.knibbe@geodan.nl
> Cc: public-lod@w3.org
> Subject: RE: Temporal validity: alternative for dcterms:valid?
>
> 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
>
> /Lars
>
> > -----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
>
>