Re: Temporal validity: alternative for dcterms:valid?

2016-01-27 10:05 GMT+01:00 Svensson, Lars <L.Svensson@dnb.de>:

> Hi Frans,
>
> On Thursday, January 21, 2016 1:28 PM, Frans Knibbe wrote:
>
> > 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?
>
> But if we change the range from Literal to something else (e. g.
> time:TemporalThing), we also make it an object property instead of a
> datatype property and then we cannot use it with (date) strings. Or we
> could of course just remove the range restriction and use either a resource
> or a string in the object position but then we're in OWL Full and might
> hamper decidability (if that is a requirement).
>

In my simple mind just dropping the range constraint on dcterms:valid seems
like a good solution, but I must confess I don't have an overview of what
the consequences would be. It does leave the dcterms vocababulary simple
and easy to use, and it does acknowledge the basic fact of life that there
many ways to express time.

Or the range could be dcterms:PeriodOfTime? That seems to still allow
multiple ways of expressing time, but it does tell us that we have a time
interval. Though it could complicate matters for those that really want to
use dcterms:valid with a time instant (instants can be expressed as
intervals, but that complicates the expression).

Regards,
Frans



> Best,
>
> Lars
>
> > 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.
>
> Ah, no I hadn't spotted that so I cc the SDW list, too.
>
> > 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
>
>