On Fri, Jun 3, 2011 at 6:39 AM, Bruce D'Arcus <[email protected]> wrote: > On Thu, Jun 2, 2011 at 5:33 PM, Frank Bennett <[email protected]> wrote: >> On Fri, Jun 3, 2011 at 4:20 AM, Bruce D'Arcus <[email protected]> wrote: >>> More on EDTF that has relevance for CSL. Thoughts? >>> >>> >>> ---------- Forwarded message ---------- >>> From: Ray Denenberg, Library of Congress <[email protected]> >>> Date: Thu, Jun 2, 2011 at 2:50 PM >>> Subject: Re: A three level suggestion >>> To: [email protected] >>> >>> >>> Saašha, I do think the three-level suggestion has merit and is worth >>> considering further. >>> >>> The spec could be represented as: >>> Level 0: a profile of 8601 >>> Level 1: first-level extensions >>> Level 2: second level extensions >>> >>> And to claim conformance, you must at least support level 1 (support >>> for level 2 includes support for level 1). >>> >>> Level 0 would be the 100 and 200 features. >>> >>> For level 1, I suggest: >>> - uncertain/approximate excluding internal. >>> - intervals, excluding those with uncertain/approximate and temporal >>> expressions, but including open and unknown. >>> - masking with "u" >> >> The specification certainly is firming up. Dates for citation purposes >> wouldn't fit neatly into the level scheme, > > That was my sense as well, except that I think we could settle on > saying CSL could support levels 0 and 1, plus a few features in 2?
In Level 1, we could treat "open" the same as "unknown end" (in terms of rendering); but the only use case seems to be for a citation to and entire run of serials, so I'm not sure it's in scope for CSL? Also in Level 1, I'm not sure what the processor should do with the "u" mask character. The choices seem to be (a) implicitly render it as "x" by convention, with or without a "circa" term in rendered output; (b) extend CSL to allow the behavior to be defined (which seems like overkill); or (c) treat the data as invalid (and so probably dumping it out as a literal string). Not sure what to do there. In the short term at least, Zotero translators (say) are probably not going to recognize and pass in "u" masked dates anyway, since they would be encoded in unpredictable ways in the source from which field content is derived. So whatever choice is made, it probably wouldn't affect much content or many users. > > I also conclude it's unlikely we'd want to suggest any concrete > changes to the way Ray has sliced the levels? > >> but the feature list is >> very helpful for clarity. >> >> In a quck trawl, I've marked items that seem fully within scope for >> citation dates with **, those which could be used with some data loss >> with ++, and those which seem out of scope without some extension of >> CSL with --. > > Nice list; on quick look, I agree. > > Bruce > >> **101 Date (with hyphen) >> ++102 Date and time (date with hyphen, time with colon) >> **103 Year and month >> **105 Year >> --108 Duration >> ++109 Date with time zone indicator >> **111 Negative year >> --203 100 year period >> **208 Interval: years >> **209 Interval: months >> **210 Interval: days >> --211 Interval: start and duration >> ++301 uncertain year >> ++302 uncertain year-month >> --3021 Year known, uncertain month within year >> ++303 uncertain date >> --304 year, month known; uncertain day >> --305 uncertain year; month, day known >> ++306 Approximate year >> ++307 Approximate month >> ++308 Approximate day >> ++309 Time and day approximate >> --310 Time is approximate but the event occurred on a known day >> --311 Day is approximate; year month, time known. >> --312 unspecified year within a known decade >> --313 unspecified month within a known year >> --314 unspecified day within a known month >> --315 Internal "unspecified" >> --316 One of a set >> --317 Multiple dates >> --3171 Multiple Dates via mask character >> **320 Interval: unknown start >> **321 Interval: unknown end >> --322 Interval: open end >> --325 Named period or event as the endpoint of an interval >> --326 Temporal Expressions; Named periods/event >> --329 Calendar >> --330 Year requiring more than four digits >> ++331 Season >> >> >> >>> >>> Level 2: >>> - Lists (one of a set, all of a set) >>> - internal uncertain/approximate >>> - temporal expressions >>> - calendar >>> - long year >>> - season >>> - masking with "x" >>> >>> Please comment. I will hold off on further BNF changes pending some >>> agreement on this. >>> >>> --Ray >>> >>> >>>> -----Original Message----- >>>> From: Discussion of the Developing Date/Time Standards >>>> [mailto:[email protected]] On Behalf Of Bruce D'Arcus >>>> Sent: Wednesday, May 25, 2011 9:07 AM >>>> To: [email protected] >>>> Subject: Re: [DATETIME] A three level suggestion >>>> >>>> On Wed, May 25, 2011 at 8:38 AM, Saašha Metsärantala <[email protected]> >>>> wrote: >>>> > Hello! >>>> > >>>> > I wonder what you think about the following suggestion. >>>> > >>>> > Keeping in mind that EDTF is thought of as >>>> > >>>> > "both a profile of and extension to ISO 8601" >>>> > >>>> > according to >>>> > >>>> > http://www.loc.gov/standards/datetime/spec.html >>>> > >>>> > we could skip "reinventing the wheel", define the first EDTF level as >>>> > a profile of ISO 8601 and just add some constraints on ISO 8601 to >>>> > build the first level of EDTF. This could make both the BNF and the >>>> > coming regexes easier to write, just carving away what we do not want >>>> have. >>>> > >>>> > Thereafter, we could have a second level thought of as an extension >>>> of >>>> > the first level. Thus, we could use the BNF just to add features to >>>> > the first level. I'm particularly thinking of lists, "x", longYears, >>>> > seasons and temporal expressions. There would not be any "uncertain, >>>> > approximate, unspecified" here. Well, ... "temporal expressions" and >>>> > seasons may contain a kind of approximation, but I suggest to place >>>> > them in the second level anyway. >>>> >>>> - where would intervals go? >>>> - not clear why 'x' is here and not below? >>>> >>>> Bruce >>>> >>>> > Thereafter, we could have a third level thought of as an extension of >>>> > the second level. Thus, we could use the BNF just to add features to >>>> > the second level. I'm particularly thinking of "?", "~" and "u". >>>> There >>>> > we would introduce "uncertain, approximate, unspecified". >>>> > >>>> > Comments are welcome! >>>> > >>>> > Regards! >>>> > >>>> > Saašha, >>>> > >>> >>> ------------------------------------------------------------------------------ >>> Simplify data backup and recovery for your virtual environment with vRanger. >>> Installation's a snap, and flexible recovery options mean your data is safe, >>> secure and there when you need it. Discover what all the cheering's about. >>> Get your free trial download today. >>> http://p.sf.net/sfu/quest-dev2dev2 >>> _______________________________________________ >>> xbiblio-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >>> >> >> ------------------------------------------------------------------------------ >> Simplify data backup and recovery for your virtual environment with vRanger. >> Installation's a snap, and flexible recovery options mean your data is safe, >> secure and there when you need it. Discover what all the cheering's about. >> Get your free trial download today. >> http://p.sf.net/sfu/quest-dev2dev2 >> _______________________________________________ >> xbiblio-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >> > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
