Re: Temporal validity: alternative for dcterms:valid?

[Frans Knibbe]

2016-01-27 10:05 GMT+01:00 Svensson, Lars <l.svens...@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@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.svens...@dnb.de]
> > Sent: Thursday, 14 January 2016 3:58 AM
> > To: Cox, Simon (L, Clayton) <simon@csiro.au>;
> frans.kni...@geodan.nl
> > Cc: public-lod@w3.org
> > Subject: RE: Temporal validity: alternative for dcterms:valid?
> >
> > On Tuesday, January 12, 2016 10:13 PM, simon@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: Sven

RE: Temporal validity: alternative for dcterms:valid?

[Simon.Cox]

OWL-Time handles this with the class time:Instant (and time:Interval). 
time:Instant has a choice of properties - 
time:inDateTime whose range is the class time:DateTimeDescription, 
which provides a choice of representations
time:inXSDDateTime whose range is the familiar 7-element microformat 
(xsd:dateTime) 
So the referring property may be an ObjectProperty with range time:Instant 
(etc), but the cost is an additional class/property wrapper before you get to 
the value. 

This approach - different, alternative, properties for values expressed as a 
literal (datatype) or as a structure (object) - seems to be standard in OWL. 
rdf:Property allows either/or, but the OWLAPI chokes on that. It would be nice 
if you could say 'either/or' in OWL, but I don't think property-unions exist in 
OWL, so I don't think the constraint can be expressed. 

Simon 

-Original Message-
From: Svensson, Lars [mailto:l.svens...@dnb.de] 
Sent: Wednesday, 27 January 2016 8:05 PM
To: Frans Knibbe <frans.kni...@geodan.nl>; Cox, Simon (L, Clayton) 
<simon@csiro.au>
Cc: public-lod@w3.org; SDW WG Public List (public-sdw...@w3.org) 
<public-sdw...@w3.org>
Subject: RE: Temporal validity: alternative for dcterms:valid?

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

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@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.svens...@dnb.de]
> Sent: Thursday, 14 January 2016 3:58 AM
> To: Cox, Simon (L, Clayton) <simon@csiro.au>; 
> frans.kni...@geodan.nl
> Cc: public-lod@w3.org
> Subject: RE: Temporal validity: alternative for dcterms:valid?
> 
> On Tuesday, January 12, 2016 10:13 PM, simon@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
> 
> /Lar

RE: Temporal validity: alternative for dcterms:valid?

[Svensson, Lars]

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

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@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.svens...@dnb.de]
> Sent: Thursday, 14 January 2016 3:58 AM
> To: Cox, Simon (L, Clayton) <simon....@csiro.au>; frans.kni...@geodan.nl
> Cc: public-lod@w3.org
> Subject: RE: Temporal validity: alternative for dcterms:valid?
> 
> On Tuesday, January 12, 2016 10:13 PM, simon@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.svens...@dnb.de]
> > Sent: Wednesday, 13 January 2016 3:41 AM
> > To: Frans Knibbe <frans.kni...@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
&

Re: Temporal validity: alternative for dcterms:valid?

[Frans Knibbe]

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@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.svens...@dnb.de]
> Sent: Thursday, 14 January 2016 3:58 AM
> To: Cox, Simon (L, Clayton) <simon@csiro.au>; frans.kni...@geodan.nl
> Cc: public-lod@w3.org
> Subject: RE: Temporal validity: alternative for dcterms:valid?
>
> On Tuesday, January 12, 2016 10:13 PM, simon@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.svens...@dnb.de]
> > Sent: Wednesday, 13 January 2016 3:41 AM
> > To: Frans Knibbe <frans.kni...@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 

RE: Temporal validity: alternative for dcterms:valid?

[Simon.Cox]

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.svens...@dnb.de] 
Sent: Thursday, 14 January 2016 3:58 AM
To: Cox, Simon (L, Clayton) <simon@csiro.au>; frans.kni...@geodan.nl
Cc: public-lod@w3.org
Subject: RE: Temporal validity: alternative for dcterms:valid?

On Tuesday, January 12, 2016 10:13 PM, simon@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.svens...@dnb.de]
> Sent: Wednesday, 13 January 2016 3:41 AM
> To: Frans Knibbe <frans.kni...@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

RE: Temporal validity: alternative for dcterms:valid?

[Svensson, Lars]

On Wednesday, January 13, 2016 9:44 PM, simon@csiro.au wrote:

> However, I'm generally wary of inventing new microsyntaxes.

I know (we've discussed this before...)
> 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.

Hindsight is an exact science...

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

Isn't the purpose of W3C standards track to ensure that there _will_ be 
software to support it? And owl time is on standards track...

Best,

Lars
 
> -Original Message-
> From: Svensson, Lars [mailto:l.svens...@dnb.de]
> Sent: Thursday, 14 January 2016 3:58 AM
> To: Cox, Simon (L, Clayton) <simon@csiro.au>; frans.kni...@geodan.nl
> Cc: public-lod@w3.org
> Subject: RE: Temporal validity: alternative for dcterms:valid?
> 
> On Tuesday, January 12, 2016 10:13 PM, simon@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.svens...@dnb.de]
> > Sent: Wednesday, 13 January 2016 3:41 AM
> > To: Frans Knibbe <frans.kni...@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
> > > 

RE: Temporal validity: alternative for dcterms:valid?

[Simon.Cox]

OK - let's put it on the agenda for Time activity. 
If necessary there can be a vote! 

-Original Message-
From: Svensson, Lars [mailto:l.svens...@dnb.de] 
Sent: Thursday, 14 January 2016 8:05 AM
To: Cox, Simon (L, Clayton) <simon@csiro.au>; frans.kni...@geodan.nl
Cc: public-lod@w3.org
Subject: RE: Temporal validity: alternative for dcterms:valid?

On Wednesday, January 13, 2016 9:44 PM, simon@csiro.au wrote:

> However, I'm generally wary of inventing new microsyntaxes.

I know (we've discussed this before...)
> 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.

Hindsight is an exact science...

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

Isn't the purpose of W3C standards track to ensure that there _will_ be 
software to support it? And owl time is on standards track...

Best,

Lars
 
> -Original Message-
> From: Svensson, Lars [mailto:l.svens...@dnb.de]
> Sent: Thursday, 14 January 2016 3:58 AM
> To: Cox, Simon (L, Clayton) <simon@csiro.au>; 
> frans.kni...@geodan.nl
> Cc: public-lod@w3.org
> Subject: RE: Temporal validity: alternative for dcterms:valid?
> 
> On Tuesday, January 12, 2016 10:13 PM, simon@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.svens...@dnb.de]
> > Sent: Wednesday, 13 January 2016 3:41 AM
> > To: Frans Knibbe <frans.kni...@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
> > > T

RE: Temporal validity: alternative for dcterms:valid?

[Svensson, Lars]

On Tuesday, January 12, 2016 10:13 PM, simon@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.svens...@dnb.de]
> Sent: Wednesday, 13 January 2016 3:41 AM
> To: Frans Knibbe <frans.kni...@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

RE: Temporal validity: alternative for dcterms:valid?

[Simon.Cox]

> 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.svens...@dnb.de] 
Sent: Wednesday, 13 January 2016 3:41 AM
To: Frans Knibbe <frans.kni...@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

RE: Temporal validity: alternative for dcterms:valid?

[Svensson, Lars]

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

Re: Temporal validity: alternative for dcterms:valid?

[Gannon Dick]

Hi Frans,

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

Well, sort of.  If one is trying to rank temporal validity then one is trying 
to rank the negative pattern of the property.  One has to wake a sleeping 
naughty boy or girl up to determine  the naughtiness property.  In another 
familiar case, in a Hospital patients are woken up at all hours to take 
medications - you can be just as ill at home, with uninterrupted sleep.  This 
seems to me to be the same logical problem (post hoc ergo propter hoc).

Santa Claus, et al. can do this sort of thing without waking up naughty boys 
and girls.   An Artificial Intelligence which believes it can do what Santa 
Claus can do is quite unhinged, I think :)

--Gannon 

On Thu, 12/24/15, Frans Knibbe  wrote:

 Subject: Temporal validity: alternative for dcterms:valid?
 To: public-lod@w3.org
 Date: Thursday, December 24, 2015, 9:57 AM
 
 Hello again,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 did find 
http://www.w3.org/ns/prov#invalidatedAtTime in
 PROV-O, which could be considered applicable, but a matching
 property to indicate the start of the time period of
 validity does not seem to exist in PROV-O. Also, its range
 is xsd:dateTime, which I think is too restrictive because
 the time needs to be known up to the level of seconds.Does this gap still need 
to be
 plugged? Or is the solution out there?Greetings,Frans