 |
 |
On Thu, 16 Oct 1997, Arthur Chapman wrote: > >1. In Helsinki it was agreed that the syntax for DC.Time > >should be revised to include the possiblity of > >(i) various forms of time-spans, including disjoint spans, and > >(ii) fuzzy times. > >It was commented that this syntax (when complete) should also be > >transfered to DC.Coverage - logically being used also for spatial > >extent when a "bounding box" style of extent is being specified. > > DC.Coverage.t > > time spans and disjoints can be handled the same as spatial discontinuities, > etc. > > DC.Coverage.t.min > DC.Coverage.t.max > I think there are some general design issues here, one affecting the other: The coverage proposal uses t1, t2, t3, etc for 'repeatability' on the top level, rather than 'real' repeatability with exactly the same label. This is a logical consequence from splitting the ranges up in a min/max and this having one piece of information split up over two labels and consequently the need of matching the labels by arbitrary numbers. I.e. I am trying to convey the differences between (for a record which describes an 5+3 day cource) Date.t1.min 12 October 1997 Date.t1.max 17 October 1997 Date.t2.min 19 October 1997 Date.t2.max 21 October 1997 versus Date 12 October 1997 - 17 October 1997 Date 19 October 1997 - 21 October 1997 For this reason the data proposal during the DC5 meeting (and stop me if I misrepresent it) has a subtly different sematic; 1-> The Date-Element contains a single Date (and can be repeated) 2-> A Date contains either A point in time A range in time (from a point in time to another point in time) An open time range (from a point in time, or till a point in time) 3-> A point in time is specified with arbitrary accuracy, i.e. (and ignore the syntax) 2e3 (wonderfully obscure) 19e2 (wonderfully obscure) circa 1997 (inpractical) 1997 Oct 1997 12 Oct 1997 12 Oct 1997 12:30 GMT 12 Oct 1997 12:30:12 GMT 12 Oct 1997 12:30:12.91256712 GMT2 .... all the way to .... 823455617.1979452125352352235345323442323 StarDate (again IGNORE the syntax) The reason for this was to _avoid_ any tag matching, and make the _value_ of each Date 'on-its-own' a semantically meaningful bit of information. Religion: This is (IMHO) a good thing for architecure you implements things on; it means that each single Dublin Core element is a meaning full element in its own right. All which was said during the workshop was that the a given expression encoding/language/protcol/... used to code chunk of DC information in should (must?) be able to express the above three levels. Just to stop things from floating in the air, think of it as something simple like 12 October 1997 12 October 1997 ; 17 October 1997 12 October 1997 ; ; 17 October 1997 Obviously this can not easily be expanded to any number of dimensions, without imposing severe syntax capability requirements on the language used to express the date value in. If my memory serves me well, there is some extensive and very simple syntactic sugare for this in either the GCMD or some FGDC standard. Is this a fair representation ? Dw.