RE: UCR issue 26

On Friday, October 30, 2015 7:17 AM, Simon.Cox@csiro.au wrote:

[...]
> The position of a time:Instant is either
> (i)                 xsd:dateTime – YYY-MM-DDTHH:MM:SS.ss[Z|(-)NN.NN] – the
> only part that can dropped in the Time Zone

Yes, this is one of the points that makes it impossible to make cultural heritage data compatible with OWL-DL: We simply don't have millisecond precision for most of our data...

> (ii)               time:DateTimeDescription, which has separate properties for year,
> month, day etc. but with a mandatory (to the extent you can say that in OWA
> …) time:unitType.
> 
> It is this last property which specifies the precision, which I think is pretty
> much what we want.
> However, its range is limited to the enumeration
> (Year,Month,Week,Day,Hour,Minute,Second) which is clearly not enough.
> I didn’t spot this limitation when I developed the extension for non-
> Gregorian systems that I keep banging on about, so this is another place
> where the revised Ontology needs some attention.
> 
> The current definition is
> 
> time:TemporalUnit
>   rdf:type owl:Class ;
>   rdfs:subClassOf owl:Thing ;
>   owl:oneOf (
>       time:unitSecond
>       time:unitMinute
>       time:unitHour
>       time:unitDay
>       time:unitWeek
>       time:unitMonth
>       time:unitYear
>     ) ;
> .
> 
> And each of the members of the enumeration is separately defined like
> 
> time:unitWeek
>   rdf:type time:TemporalUnit ;
> .
> 
> Etc.
> So I guess this could be relaxed to
> 
> time:TemporalUnit
>   rdf:type owl:Class ;
>   rdfs:subClassOf owl:Thing ;
> .
> 
> Leaving the definitions of the existing enumeration in place so they are still
> available, but opening it up to other values of rdf:type time:TemporalUnit.

I always thought that the (one of the?) reasons for this enumeration was that it would be impossible to develop a reasoner when the set of temporal units is not restricted to pre-defined types. I'd love to be proven wrong, though, since I agree that the current list is not exhaustive for our purposes.

Best,

Lars

Received on Tuesday, 3 November 2015 20:50:16 UTC