RE: Temporal validity: alternative for dcterms:valid?

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.Svensson@dnb.de] 
Sent: Wednesday, 27 January 2016 8:05 PM
To: Frans Knibbe <frans.knibbe@geodan.nl>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
Cc: public-lod@w3.org; SDW WG Public List (public-sdw-wg@w3.org) <public-sdw-wg@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.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

Received on Thursday, 28 January 2016 06:34:53 UTC