Empathy List Archives

 can reason,
 or

 from some of the existing text fields. By very simple, 

 we only consider fields like year, month, day, and that 

 produce two scalar dates (early and late), which either define a
 range, or define a point (if they are equal). AIUI, a structured
 date /cannot/ model the idea of "some time/any time after (or
 before) a date".

 *From:* Chris Hoffman [mailto:chris.hoffman@berkeley.edu]
 *Sent:* Wednesday, August 24, 2011 9:01 AM
 *To:* Patrick Schmitz
 *Cc:* 'Christopher Pott'; 'Aron Roberts'; 

 *Subject:* Re: [Talk] what's the best way to represent 

 Hi Patrick, I think it's fair to say there's no 

 there's been no discussion :-) It's possible that each 

 want to use structured dates differently, which will 

 add any intelligence or even predictability to things 

 However, I also think that if a significant number of deploying
 institutions can come to some consensus on best ways to use and
 search structured dates, then many institutions will 

 the same best practices.

 Thanks,
 Chris

 On Aug 24, 2011, at 8:55 AM, Patrick Schmitz wrote:

 Aron was out yesterday, and Rick is out for a few 

 done a lot of the structured dates work to date.
 The last I heard, Aron was hoping to get consensus 

 about how we map all the text fields to actual date 

 can reason on (for search, ordering, etc). To date, 

 be no such consensus, which will preclude search, 

 on structured dates. I would think that this would 

 dates quite a bit less useful...
 Perhaps (I hope) my understanding is out of date, and 

 to implement the logic. Perhaps Aron can jump in this 

 gets in.
 Patrick

     *From:* talk-bounces@lists.collectionspace.org
     <mailto:talk-bounces@lists.collectionspace.org>
     [mailto:talk-bounces@lists.collectionspace.org] 

     *Chris Hoffman
     *Sent:* Tuesday, August 23, 2011 11:05 AM
     *To:* Christopher Pott
     *Cc:* talk@lists.collectionspace.org
     <mailto:talk@lists.collectionspace.org>
     *Subject:* Re: [Talk] what's the best way to represent
     structured dates?

     Hi Chris,

     Thanks for asking these questions. We've been wondering the
     same things. Have you changed any existing calendar date
     fields to structured dates or added new structured date
     fields? I think this is all quite new, and 

     be able to come up with some best practices 

     migration and data entry).

     I suspect that search and advanced search of 

     fields is going to be an issue for those of us deploying
     CollectionSpace. Our users will want CSpace to be 

     structured dates, interpreting qualifiers, and so on, but I
     bet that we won't see much as much as we would like in the
     first version of advanced search. I'm always happy to be
     proved wrong! :-)

     Chris

     On Aug 23, 2011, at 8:48 AM, Christopher Pott wrote:

     Hi,

     I'm looking at the structured date schema and the 

     represent dates migrated from our old system. Any 

     about the following would be much appreciated..

     1. I see some different/overlapping possibilities for
     recording an object creation date. For example, 

     "1718" (display date) one could either store:

     a) a single date, providing year only (1718)

     b) an earliest date (01.01.1718) with a latest date 

     c) a single date (01.01.1718) with a qualifier of 

     Is there any difference in the meaning of these three (and
     would they all be treated equally by services such as
     advanced search)? Our migration data is currently 

     'b' but the other formats are sometimes 

     input.

     2. How are date "certainties" and "qualifiers" used by
     advanced search?

     I've specified "1718", as a creation date with a 

     "circa". Will a search for objects created during 

     in a hit?

     Or is it necessary to use qualifiers (eg. 1718 

     to define exact limits for this type of searching?

     3. Is the Date schema locally extendable? (We 

     hold an English translation of the display text)

     4. Will Advanced search by creation date also search the
     display date or will it just use the single/earliest and
     latest date groups?

     Thanks,

     Chris

     _______________________________________________
     Talk mailing list
     Talk@lists.collectionspace.org
     <mailto:Talk@lists.collectionspace.org>

  can reason,
  or

  from some of the existing text fields. By very simple,

  we only consider fields like year, month, day, and that

  produce two scalar dates (early and late), which either define a
  range, or define a point (if they are equal). AIUI, a structured
  date /cannot/ model the idea of "some time/any time after (or
  before) a date".

  *From:* Chris Hoffman [mailto:chris.hoffman@berkeley.edu]
  *Sent:* Wednesday, August 24, 2011 9:01 AM
  *To:* Patrick Schmitz
  *Cc:* 'Christopher Pott'; 'Aron Roberts';

  *Subject:* Re: [Talk] what's the best way to represent

  Hi Patrick, I think it's fair to say there's no

  there's been no discussion :-) It's possible that each

  want to use structured dates differently, which will

  add any intelligence or even predictability to things

  However, I also think that if a significant number of deploying
  institutions can come to some consensus on best ways to use and
  search structured dates, then many institutions will

  the same best practices.

  Thanks,
  Chris

  On Aug 24, 2011, at 8:55 AM, Patrick Schmitz wrote:

  Aron was out yesterday, and Rick is out for a few

  done a lot of the structured dates work to date.
  The last I heard, Aron was hoping to get consensus

  about how we map all the text fields to actual date

  can reason on (for search, ordering, etc). To date,

  be no such consensus, which will preclude search,

  on structured dates. I would think that this would

  dates quite a bit less useful...
  Perhaps (I hope) my understanding is out of date, and

  to implement the logic. Perhaps Aron can jump in this

  gets in.
  Patrick

      *From:* talk-bounces@lists.collectionspace.org
      <mailto:talk-bounces@lists.collectionspace.org>
      [mailto:talk-bounces@lists.collectionspace.org]

      *Chris Hoffman
      *Sent:* Tuesday, August 23, 2011 11:05 AM
      *To:* Christopher Pott
      *Cc:* talk@lists.collectionspace.org
      <mailto:talk@lists.collectionspace.org>
      *Subject:* Re: [Talk] what's the best way to represent
      structured dates?

      Hi Chris,

      Thanks for asking these questions. We've been wondering the
      same things. Have you changed any existing calendar date
      fields to structured dates or added new structured date
      fields? I think this is all quite new, and

      be able to come up with some best practices

      migration and data entry).

      I suspect that search and advanced search of

      fields is going to be an issue for those of us deploying
      CollectionSpace. Our users will want CSpace to be

      structured dates, interpreting qualifiers, and so on, but I
      bet that we won't see much as much as we would like in the
      first version of advanced search. I'm always happy to be
      proved wrong! :-)

      Chris

      On Aug 23, 2011, at 8:48 AM, Christopher Pott wrote:

      Hi,

      I'm looking at the structured date schema and the

      represent dates migrated from our old system. Any

      about the following would be much appreciated..

      1. I see some different/overlapping possibilities for
      recording an object creation date. For example,

      "1718" (display date) one could either store:

      a) a single date, providing year only (1718)

      b) an earliest date (01.01.1718) with a latest date

      c) a single date (01.01.1718) with a qualifier of

      Is there any difference in the meaning of these three (and
      would they all be treated equally by services such as
      advanced search)? Our migration data is currently

      'b' but the other formats are sometimes

      input.

      2. How are date "certainties" and "qualifiers" used by
      advanced search?

      I've specified "1718", as a creation date with a

      "circa". Will a search for objects created during

      in a hit?

      Or is it necessary to use qualifiers (eg. 1718

      to define exact limits for this type of searching?

      3. Is the Date schema locally extendable? (We

      hold an English translation of the display text)

      4. Will Advanced search by creation date also search the
      display date or will it just use the single/earliest and
      latest date groups?

      Thanks,

      Chris

      _______________________________________________
      Talk mailing list
      Talk@lists.collectionspace.org
      <mailto:Talk@lists.collectionspace.org>

 can reason,
 or

 from some of the existing text fields. By very simple, 

 we only consider fields like year, month, day, and 

 produce two scalar dates (early and late), which 

 range, or define a point (if they are equal). AIUI, a 

 date /cannot/ model the idea of "some time/any time after (or
 before) a date".

 *From:* Chris Hoffman [mailto:chris.hoffman@berkeley.edu]
 *Sent:* Wednesday, August 24, 2011 9:01 AM
 *To:* Patrick Schmitz
 *Cc:* 'Christopher Pott'; 'Aron Roberts'; 

 Hi Patrick, I think it's fair to say there's no 

 there's been no discussion :-) It's possible that each 

 want to use structured dates differently, which will 

 add any intelligence or even predictability to things 

 However, I also think that if a significant number of deploying
 institutions can come to some consensus on best ways to use and
 search structured dates, then many institutions will 

 the same best practices.

 Thanks,
 Chris

 On Aug 24, 2011, at 8:55 AM, Patrick Schmitz wrote:

 Aron was out yesterday, and Rick is out for a few 

 done a lot of the structured dates work to date.
 The last I heard, Aron was hoping to get consensus 

 about how we map all the text fields to actual date 

 can reason on (for search, ordering, etc). To date, 

 be no such consensus, which will preclude search, 

 on structured dates. I would think that this would 

 dates quite a bit less useful...
 Perhaps (I hope) my understanding is out of date, and 

 to implement the logic. Perhaps Aron can jump in this 

 gets in.
 Patrick

     *From:* talk-bounces@lists.collectionspace.org
     <mailto:talk-bounces@lists.collectionspace.org>
     [mailto:talk-bounces@lists.collectionspace.org] 

     *Chris Hoffman
     *Sent:* Tuesday, August 23, 2011 11:05 AM
     *To:* Christopher Pott
     *Cc:* talk@lists.collectionspace.org
     <mailto:talk@lists.collectionspace.org>
     *Subject:* Re: [Talk] what's the best way to represent
     structured dates?

     Hi Chris,

     Thanks for asking these questions. We've been 

     same things. Have you changed any existing calendar date
     fields to structured dates or added new structured date
     fields? I think this is all quite new, and 

     be able to come up with some best practices 

     migration and data entry).

     I suspect that search and advanced search of 

     fields is going to be an issue for those of us deploying
     CollectionSpace. Our users will want CSpace to be 

     structured dates, interpreting qualifiers, and so 

     bet that we won't see much as much as we would like in the
     first version of advanced search. I'm always happy to be
     proved wrong! :-)

     Chris

     On Aug 23, 2011, at 8:48 AM, Christopher Pott wrote:

     Hi,

     I'm looking at the structured date schema and 

     represent dates migrated from our old system. 

     about the following would be much appreciated..

     1. I see some different/overlapping possibilities for
     recording an object creation date. For example, 

     "1718" (display date) one could either store:

     a) a single date, providing year only (1718)

     b) an earliest date (01.01.1718) with a latest date 

     c) a single date (01.01.1718) with a qualifier of + 364 

     Is there any difference in the meaning of these 

     would they all be treated equally by services such as
     advanced search)? Our migration data is 

     'b' but the other formats are sometimes 

     input.

     2. How are date "certainties" and "qualifiers" used by
     advanced search?

     I've specified "1718", as a creation date with a 

     "circa". Will a search for objects created 

     in a hit?

     Or is it necessary to use qualifiers (eg. 1718 

     to define exact limits for this type of searching?

     3. Is the Date schema locally extendable? (We 

     hold an English translation of the display text)

     4. Will Advanced search by creation date also search the
     display date or will it just use the single/earliest and
     latest date groups?

     Thanks,

     Chris

     _______________________________________________
     Talk mailing list
     Talk@lists.collectionspace.org
     <mailto:Talk@lists.collectionspace.org>

 can reason,
 or

 from some of the existing text fields. By very simple,

 we only consider fields like year, month, day, and

 produce two scalar dates (early and late), which

 range, or define a point (if they are equal). AIUI, a

 date /cannot/ model the idea of "some time/any time after (or
 before) a date".

 *From:* Chris Hoffman [mailto:chris.hoffman@berkeley.edu]
 *Sent:* Wednesday, August 24, 2011 9:01 AM
 *To:* Patrick Schmitz
 *Cc:* 'Christopher Pott'; 'Aron Roberts';

 Hi Patrick, I think it's fair to say there's no

 there's been no discussion :-) It's possible that each

 want to use structured dates differently, which will

 add any intelligence or even predictability to things

 However, I also think that if a significant number of deploying
 institutions can come to some consensus on best ways to use and
 search structured dates, then many institutions will

 the same best practices.

 Thanks,
 Chris

 On Aug 24, 2011, at 8:55 AM, Patrick Schmitz wrote:

 Aron was out yesterday, and Rick is out for a few

 done a lot of the structured dates work to date.
 The last I heard, Aron was hoping to get consensus

 about how we map all the text fields to actual date

 can reason on (for search, ordering, etc). To date,

 be no such consensus, which will preclude search,

 on structured dates. I would think that this would

 dates quite a bit less useful...
 Perhaps (I hope) my understanding is out of date, and

 to implement the logic. Perhaps Aron can jump in this

 gets in.
 Patrick

     *From:* talk-bounces@lists.collectionspace.org
     <mailto:talk-bounces@lists.collectionspace.org>
     [mailto:talk-bounces@lists.collectionspace.org]

     *Chris Hoffman
     *Sent:* Tuesday, August 23, 2011 11:05 AM
     *To:* Christopher Pott
     *Cc:* talk@lists.collectionspace.org
     <mailto:talk@lists.collectionspace.org>
     *Subject:* Re: [Talk] what's the best way to represent
     structured dates?

     Hi Chris,

     Thanks for asking these questions. We've been

     same things. Have you changed any existing calendar date
     fields to structured dates or added new structured date
     fields? I think this is all quite new, and

     be able to come up with some best practices

     migration and data entry).

     I suspect that search and advanced search of

     fields is going to be an issue for those of us deploying
     CollectionSpace. Our users will want CSpace to be

     structured dates, interpreting qualifiers, and so

     bet that we won't see much as much as we would like in the
     first version of advanced search. I'm always happy to be
     proved wrong! :-)

     Chris

     On Aug 23, 2011, at 8:48 AM, Christopher Pott wrote:

     Hi,

     I'm looking at the structured date schema and

     represent dates migrated from our old system.

     about the following would be much appreciated..

     1. I see some different/overlapping possibilities for
     recording an object creation date. For example,

     "1718" (display date) one could either store:

     a) a single date, providing year only (1718)

     b) an earliest date (01.01.1718) with a latest date

     c) a single date (01.01.1718) with a qualifier of + 364

     Is there any difference in the meaning of these

     would they all be treated equally by services such as
     advanced search)? Our migration data is

     'b' but the other formats are sometimes

     input.

     2. How are date "certainties" and "qualifiers" used by
     advanced search?

     I've specified "1718", as a creation date with a

     "circa". Will a search for objects created

     in a hit?

     Or is it necessary to use qualifiers (eg. 1718

     to define exact limits for this type of searching?

     3. Is the Date schema locally extendable? (We

     hold an English translation of the display text)

     4. Will Advanced search by creation date also search the
     display date or will it just use the single/earliest and
     latest date groups?

     Thanks,

     Chris

     _______________________________________________
     Talk mailing list
     Talk@lists.collectionspace.org
     <mailto:Talk@lists.collectionspace.org>

  can reason,
  or

  from some of the existing text fields. By very simple,

  we only consider fields like year, month, day, and

  produce two scalar dates (early and late), which

  range, or define a point (if they are equal). AIUI, a

  date /cannot/ model the idea of "some time/any time after (or
  before) a date".

  *From:* Chris Hoffman [mailto:chris.hoffman@berkeley.edu]
  *Sent:* Wednesday, August 24, 2011 9:01 AM
  *To:* Patrick Schmitz
  *Cc:* 'Christopher Pott'; 'Aron Roberts';

  Hi Patrick, I think it's fair to say there's no

  there's been no discussion :-) It's possible that each

  want to use structured dates differently, which will

  add any intelligence or even predictability to things

  However, I also think that if a significant number of deploying
  institutions can come to some consensus on best ways to use and
  search structured dates, then many institutions will

  the same best practices.

  Thanks,
  Chris

  On Aug 24, 2011, at 8:55 AM, Patrick Schmitz wrote:

  Aron was out yesterday, and Rick is out for a few

  done a lot of the structured dates work to date.
  The last I heard, Aron was hoping to get consensus

  about how we map all the text fields to actual date

  can reason on (for search, ordering, etc). To date,

  be no such consensus, which will preclude search,

  on structured dates. I would think that this would

  dates quite a bit less useful...
  Perhaps (I hope) my understanding is out of date, and

  to implement the logic. Perhaps Aron can jump in this

  gets in.
  Patrick

      *From:* talk-bounces@lists.collectionspace.org
      <mailto:talk-bounces@lists.collectionspace.org>
      [mailto:talk-bounces@lists.collectionspace.org]

      *Chris Hoffman
      *Sent:* Tuesday, August 23, 2011 11:05 AM
      *To:* Christopher Pott
      *Cc:* talk@lists.collectionspace.org
      <mailto:talk@lists.collectionspace.org>
      *Subject:* Re: [Talk] what's the best way to represent
      structured dates?

      Hi Chris,

      Thanks for asking these questions. We've been

      same things. Have you changed any existing calendar date
      fields to structured dates or added new structured date
      fields? I think this is all quite new, and

      be able to come up with some best practices

      migration and data entry).

      I suspect that search and advanced search of

      fields is going to be an issue for those of us deploying
      CollectionSpace. Our users will want CSpace to be

      structured dates, interpreting qualifiers, and so

      bet that we won't see much as much as we would like in the
      first version of advanced search. I'm always happy to be
      proved wrong! :-)

      Chris

      On Aug 23, 2011, at 8:48 AM, Christopher Pott wrote:

      Hi,

      I'm looking at the structured date schema and

      represent dates migrated from our old system.

      about the following would be much appreciated..

      1. I see some different/overlapping possibilities for
      recording an object creation date. For example,

      "1718" (display date) one could either store:

      a) a single date, providing year only (1718)

      b) an earliest date (01.01.1718) with a latest date

      c) a single date (01.01.1718) with a qualifier of + 364

      Is there any difference in the meaning of these

      would they all be treated equally by services such as
      advanced search)? Our migration data is

      'b' but the other formats are sometimes

      input.

      2. How are date "certainties" and "qualifiers" used by
      advanced search?

      I've specified "1718", as a creation date with a

      "circa". Will a search for objects created

      in a hit?

      Or is it necessary to use qualifiers (eg. 1718

      to define exact limits for this type of searching?

      3. Is the Date schema locally extendable? (We

      hold an English translation of the display text)

      4. Will Advanced search by creation date also search the
      display date or will it just use the single/earliest and
      latest date groups?

      Thanks,

      Chris

      _______________________________________________
      Talk mailing list
      Talk@lists.collectionspace.org
      <mailto:Talk@lists.collectionspace.org>

Just concluded a summit of the chronometric working group here at the Hearst (or, as we call it, me and Paolo), and we're happy with a 300Myr limit (BTW—we and presumably paleo, geology, etc. would call this BP, not BCE).  We have a handful of 50–150Myr BP objects for which we might conceivably have dates we'd want to enter.  However, we can't think of any cases in which we've got objects older than 300Myr for which the ≥ 300Myr date would have enough importance to make entry of these dates a requirement for us at the moment (e.g., we might have a bead made of an Ordovician brachiopod, but the collection and production dates would be the critical ones for us, not the date of the material from which the item was made).  I say "at the moment" because it would be awfully handy to have these dates entered once we're at the point where we can offer federated searching across collections/museums.

I can tell you, though, that you'll probably have a tough time convincing the paleo folks that they don't need to enter dates for their Carboniferous and earlier collections:

 can reason,
 or

 from some of the existing text fields. By very simple,

 we only consider fields like year, month, day, and

 produce two scalar dates (early and late), which

 range, or define a point (if they are equal). AIUI, a

 date /cannot/ model the idea of "some time/any 

 before) a date".

 *From:* Chris Hoffman [mailto:chris.hoffman@berkeley.edu]
 *Sent:* Wednesday, August 24, 2011 9:01 AM
 *To:* Patrick Schmitz
 *Cc:* 'Christopher Pott'; 'Aron Roberts'; 

 Hi Patrick, I think it's fair to say there's no

 there's been no discussion :-) It's possible that each

 want to use structured dates differently, which will

 add any intelligence or even predictability to things

 However, I also think that if a significant number of 

 the same best practices.

 Thanks,
 Chris

 On Aug 24, 2011, at 8:55 AM, Patrick Schmitz wrote:

 Aron was out yesterday, and Rick is out for a few

 done a lot of the structured dates work to date.
 The last I heard, Aron was hoping to get consensus

 about how we map all the text fields to actual date

 can reason on (for search, ordering, etc). To date,

 be no such consensus, which will preclude search,

 on structured dates. I would think that this would

 dates quite a bit less useful...
 Perhaps (I hope) my understanding is out of date, and

 to implement the logic. Perhaps Aron can jump in this

 gets in.
 Patrick

     *From:* talk-bounces@lists.collectionspace.org
     <mailto:talk-bounces@lists.collectionspace.org>
     [mailto:talk-bounces@lists.collectionspace.org]

     *Chris Hoffman
     *Sent:* Tuesday, August 23, 2011 11:05 AM
     *To:* Christopher Pott
     *Cc:* talk@lists.collectionspace.org
     <mailto:talk@lists.collectionspace.org>
     *Subject:* Re: [Talk] what's the best way to represent
     structured dates?

     Hi Chris,

     Thanks for asking these questions. We've been

     same things. Have you changed any existing 

     fields to structured dates or added new 

     fields? I think this is all quite new, and

     be able to come up with some best practices

     migration and data entry).

     I suspect that search and advanced search of

     fields is going to be an issue for those of 

     CollectionSpace. Our users will want CSpace to be

     structured dates, interpreting qualifiers, and so

     bet that we won't see much as much as we 

     proved wrong! :-)

     Chris

     On Aug 23, 2011, at 8:48 AM, Christopher Pott wrote:

     Hi,

     I'm looking at the structured date schema and

     represent dates migrated from our old system.

     about the following would be much appreciated..

     1. I see some different/overlapping possibilities for
     recording an object creation date. For example,

     "1718" (display date) one could either store:

     a) a single date, providing year only (1718)

     b) an earliest date (01.01.1718) with a latest date

     c) a single date (01.01.1718) with a 

     Is there any difference in the meaning of these

     would they all be treated equally by services such as
     advanced search)? Our migration data is

     'b' but the other formats are sometimes

     input.

     2. How are date "certainties" and 

     advanced search?

     I've specified "1718", as a creation date with a

     "circa". Will a search for objects created

     in a hit?

     Or is it necessary to use qualifiers (eg. 1718

     to define exact limits for this type of searching?

     3. Is the Date schema locally extendable? (We

     hold an English translation of the display text)

     4. Will Advanced search by creation date also search 

     Thanks,

     Chris

     _______________________________________________
     Talk mailing list
     Talk@lists.collectionspace.org
     <mailto:Talk@lists.collectionspace.org>

Just concluded a summit of the chronometric working 

I can tell you, though, that you'll probably have a 

 can reason,
 or

 from some of the existing text fields. By very simple,

 we only consider fields like year, month, day, and

 produce two scalar dates (early and late), which

 range, or define a point (if they are equal). AIUI, a

 date /cannot/ model the idea of "some time/any

 before) a date".

 *From:* Chris Hoffman [mailto:chris.hoffman@berkeley.edu]
 *Sent:* Wednesday, August 24, 2011 9:01 AM
 *To:* Patrick Schmitz
 *Cc:* 'Christopher Pott'; 'Aron Roberts'; 

 Hi Patrick, I think it's fair to say there's no

 there's been no discussion :-) It's possible that each

 want to use structured dates differently, which will

 add any intelligence or even predictability to things

 However, I also think that if a significant number of 

 the same best practices.

 Thanks,
 Chris

 On Aug 24, 2011, at 8:55 AM, Patrick Schmitz wrote:

 Aron was out yesterday, and Rick is out for a few

 done a lot of the structured dates work to date.
 The last I heard, Aron was hoping to get consensus

 about how we map all the text fields to actual date

 can reason on (for search, ordering, etc). To date,

 be no such consensus, which will preclude search,

 on structured dates. I would think that this would

 dates quite a bit less useful...
 Perhaps (I hope) my understanding is out of date, and

 to implement the logic. Perhaps Aron can jump in this

 gets in.
 Patrick

     *From:* talk-bounces@lists.collectionspace.org
     <mailto:talk-bounces@lists.collectionspace.org>
     [mailto:talk-bounces@lists.collectionspace.org]

     *Chris Hoffman
     *Sent:* Tuesday, August 23, 2011 11:05 AM
     *To:* Christopher Pott
     *Cc:* talk@lists.collectionspace.org
     <mailto:talk@lists.collectionspace.org>
     *Subject:* Re: [Talk] what's the best way to 

     structured dates?

     Hi Chris,

     Thanks for asking these questions. We've been

     same things. Have you changed any existing

     fields to structured dates or added new

     fields? I think this is all quite new, and

     be able to come up with some best practices

     migration and data entry).

     I suspect that search and advanced search of

     fields is going to be an issue for those of

     CollectionSpace. Our users will want CSpace to be

     structured dates, interpreting qualifiers, and so

     bet that we won't see much as much as we

     proved wrong! :-)

     Chris

     On Aug 23, 2011, at 8:48 AM, Christopher Pott wrote:

     Hi,

     I'm looking at the structured date schema and

     represent dates migrated from our old system.

     about the following would be much appreciated..

     1. I see some different/overlapping 

     recording an object creation date. For example,

     "1718" (display date) one could either store:

     a) a single date, providing year only (1718)

     b) an earliest date (01.01.1718) with a latest date

     c) a single date (01.01.1718) with a

     Is there any difference in the meaning of these

     would they all be treated equally by 

     advanced search)? Our migration data is

     'b' but the other formats are sometimes

     input.

     2. How are date "certainties" and

     advanced search?

     I've specified "1718", as a creation date with a

     "circa". Will a search for objects created

     in a hit?

     Or is it necessary to use qualifiers (eg. 1718

     to define exact limits for this type of searching?

     3. Is the Date schema locally extendable? (We

     hold an English translation of the display text)

     4. Will Advanced search by creation date 

     Thanks,

     Chris

     _______________________________________________
     Talk mailing list
     Talk@lists.collectionspace.org
     <mailto:Talk@lists.collectionspace.org>

Just concluded a summit of the chronometric working

I can tell you, though, that you'll probably have a

 can reason,
 or

 from some of the existing text fields. By very simple,

 we only consider fields like year, month, day, and

 produce two scalar dates (early and late), which

 range, or define a point (if they are equal). AIUI, a

 date /cannot/ model the idea of "some time/any

 before) a date".

 *From:* Chris Hoffman [mailto:chris.hoffman@berkeley.edu]
 *Sent:* Wednesday, August 24, 2011 9:01 AM
 *To:* Patrick Schmitz
 *Cc:* 'Christopher Pott'; 'Aron Roberts';

 Hi Patrick, I think it's fair to say there's no

 there's been no discussion :-) It's possible that each

 want to use structured dates differently, which will

 add any intelligence or even predictability to things

 However, I also think that if a significant number of

 the same best practices.

 Thanks,
 Chris

 On Aug 24, 2011, at 8:55 AM, Patrick Schmitz wrote:

 Aron was out yesterday, and Rick is out for a few

 done a lot of the structured dates work to date.
 The last I heard, Aron was hoping to get consensus

 about how we map all the text fields to actual date

 can reason on (for search, ordering, etc). To date,

 be no such consensus, which will preclude search,

 on structured dates. I would think that this would

 dates quite a bit less useful...
 Perhaps (I hope) my understanding is out of date, and

 to implement the logic. Perhaps Aron can jump in this

 gets in.
 Patrick

     *From:* talk-bounces@lists.collectionspace.org
     <mailto:talk-bounces@lists.collectionspace.org>
     [mailto:talk-bounces@lists.collectionspace.org]

     *Chris Hoffman
     *Sent:* Tuesday, August 23, 2011 11:05 AM
     *To:* Christopher Pott
     *Cc:* talk@lists.collectionspace.org
     <mailto:talk@lists.collectionspace.org>
     *Subject:* Re: [Talk] what's the best way to

     structured dates?

     Hi Chris,

     Thanks for asking these questions. We've been

     same things. Have you changed any existing

     fields to structured dates or added new

     fields? I think this is all quite new, and

     be able to come up with some best practices

     migration and data entry).

     I suspect that search and advanced search of

     fields is going to be an issue for those of

     CollectionSpace. Our users will want CSpace to be

     structured dates, interpreting qualifiers, and so

     bet that we won't see much as much as we

     proved wrong! :-)

     Chris

     On Aug 23, 2011, at 8:48 AM, Christopher Pott wrote:

     Hi,

     I'm looking at the structured date schema and

     represent dates migrated from our old system.

     about the following would be much appreciated..

     1. I see some different/overlapping

     recording an object creation date. For example,

     "1718" (display date) one could either store:

     a) a single date, providing year only (1718)

     b) an earliest date (01.01.1718) with a latest date

     c) a single date (01.01.1718) with a

     Is there any difference in the meaning of these

     would they all be treated equally by

     advanced search)? Our migration data is

     'b' but the other formats are sometimes

     input.

     2. How are date "certainties" and

     advanced search?

     I've specified "1718", as a creation date with a

     "circa". Will a search for objects created

     in a hit?

     Or is it necessary to use qualifiers (eg. 1718

     to define exact limits for this type of searching?

     3. Is the Date schema locally extendable? (We

     hold an English translation of the display text)

     4. Will Advanced search by creation date

     Thanks,

     Chris

     _______________________________________________
     Talk mailing list
     Talk@lists.collectionspace.org
     <mailto:Talk@lists.collectionspace.org>

talk@lists.collectionspace.org

what's the best way to represent structured dates?