A question about how to handle this issue: > Sometimes we do not know the full date for an accession acquisition or loan, perhaps we only have a year or month/year. Is there a way to make this more flexible but keep some structure? When you put something into a calendar date field, what is stored and spit back is the complete ISO-8601 time format, when what is really wanted is the approximations available in the structured date field. (Setting aside for the moment CSPACE-4928 which deals with dropping the time portion of date-relevant-only displays.) Are there issues (other than the complexities of pulling this data back out in reports) with changing a calendar date field into a structured date field? Or is there a better way to handle this date approximation problem? Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Hi Peter, We at Berkeley have customized a number of schema to add a structured date version of something that is a calendar date in core CollectionSpace. It can be a bit of a hassle to get something computable out of that structured date schema, but at least it’s a problem that the museum community knows very well. Then it becomes a functional discussion to determine which part of the structured date to pull out for reports and web sites. Also, I think that there are clever things that can be done outside of CollectionSpace with different kinds of extracted date values (e.g., in Solr) in order to provide nice functionality. Another consideration would be what you might need to do on the Advanced Search screen that corresponds to the record type. You might need to add the Structured Date search widget, which is essentially checking some of the calendar begin and end dates that are calculated and stored in the structured date schema. Wow, does any of this make sense?! Thanks, Chris > On Nov 23, 2015, at 11:09 AM, Peter Murray <pmurray@chillco.com> wrote: > > A question about how to handle this issue: > >> Sometimes we do not know the full date for an accession acquisition or loan, perhaps we only have a year or month/year. Is there a way to make this more flexible but keep some structure? > > When you put something into a calendar date field, what is stored and spit back is the complete ISO-8601 time format, when what is really wanted is the approximations available in the structured date field. (Setting aside for the moment CSPACE-4928 which deals with dropping the time portion of date-relevant-only displays.) Are there issues (other than the complexities of pulling this data back out in reports) with changing a calendar date field into a structured date field? Or is there a better way to handle this date approximation problem? > > > Peter > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Ah, I had not considered the implications of search. Hmmm... We had noticed that the display date field is not automatically computed when one enters values into the structured fields of the date. This is a similar kind of issue, except that it is impacting how the data is searched. This is now ringing bells from a time a few years ago when I was looking that the Library of Congress' Extended Date-Time Format (https://www.loc.gov/standards/datetime/), except I think CSpace's structure date format is even more precise than EDTF. I'm starting to think of handling dates/times with the same loathing I usually reserve for handling Unicode in non-native-Unicode systems... Peter > On Nov 23, 2015, at 2:47 PM, Chris Hoffman <chris_h@berkeley.edu> wrote: > > Hi Peter, > > We at Berkeley have customized a number of schema to add a structured date version of something that is a calendar date in core CollectionSpace. It can be a bit of a hassle to get something computable out of that structured date schema, but at least it’s a problem that the museum community knows very well. Then it becomes a functional discussion to determine which part of the structured date to pull out for reports and web sites. Also, I think that there are clever things that can be done outside of CollectionSpace with different kinds of extracted date values (e.g., in Solr) in order to provide nice functionality. > > Another consideration would be what you might need to do on the Advanced Search screen that corresponds to the record type. You might need to add the Structured Date search widget, which is essentially checking some of the calendar begin and end dates that are calculated and stored in the structured date schema. > > Wow, does any of this make sense?! > > Thanks, > Chris > > >> On Nov 23, 2015, at 11:09 AM, Peter Murray <pmurray@chillco.com> wrote: >> >> A question about how to handle this issue: >> >>> Sometimes we do not know the full date for an accession acquisition or loan, perhaps we only have a year or month/year. Is there a way to make this more flexible but keep some structure? >> >> When you put something into a calendar date field, what is stored and spit back is the complete ISO-8601 time format, when what is really wanted is the approximations available in the structured date field. (Setting aside for the moment CSPACE-4928 which deals with dropping the time portion of date-relevant-only displays.) Are there issues (other than the complexities of pulling this data back out in reports) with changing a calendar date field into a structured date field? Or is there a better way to handle this date approximation problem? >> >> >> Peter >> -- >> Peter Murray >> Dev/Ops Lead and Project Manager >> Cherry Hill Company >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Yes, dates are a source of many CSpace headaches! Ray Lee has built a wonderful customization in place at Berkeley. https://github.com/cspace-deployment/services/tree/master/services/structureddate <https://github.com/cspace-deployment/services/tree/master/services/structureddate> People enter a text string in the display date, and the structured date components are calculated and entered. It uses a grammar file that might need to be customized for different date data entry norms of behavior, but it is very powerful. Chris > On Nov 24, 2015, at 8:14 AM, Peter Murray <pmurray@chillco.com> wrote: > > Ah, I had not considered the implications of search. Hmmm... We had noticed that the display date field is not automatically computed when one enters values into the structured fields of the date. This is a similar kind of issue, except that it is impacting how the data is searched. This is now ringing bells from a time a few years ago when I was looking that the Library of Congress' Extended Date-Time Format (https://www.loc.gov/standards/datetime/), except I think CSpace's structure date format is even more precise than EDTF. > > I'm starting to think of handling dates/times with the same loathing I usually reserve for handling Unicode in non-native-Unicode systems... > > > Peter > >> On Nov 23, 2015, at 2:47 PM, Chris Hoffman <chris_h@berkeley.edu> wrote: >> >> Hi Peter, >> >> We at Berkeley have customized a number of schema to add a structured date version of something that is a calendar date in core CollectionSpace. It can be a bit of a hassle to get something computable out of that structured date schema, but at least it’s a problem that the museum community knows very well. Then it becomes a functional discussion to determine which part of the structured date to pull out for reports and web sites. Also, I think that there are clever things that can be done outside of CollectionSpace with different kinds of extracted date values (e.g., in Solr) in order to provide nice functionality. >> >> Another consideration would be what you might need to do on the Advanced Search screen that corresponds to the record type. You might need to add the Structured Date search widget, which is essentially checking some of the calendar begin and end dates that are calculated and stored in the structured date schema. >> >> Wow, does any of this make sense?! >> >> Thanks, >> Chris >> >> >>> On Nov 23, 2015, at 11:09 AM, Peter Murray <pmurray@chillco.com> wrote: >>> >>> A question about how to handle this issue: >>> >>>> Sometimes we do not know the full date for an accession acquisition or loan, perhaps we only have a year or month/year. Is there a way to make this more flexible but keep some structure? >>> >>> When you put something into a calendar date field, what is stored and spit back is the complete ISO-8601 time format, when what is really wanted is the approximations available in the structured date field. (Setting aside for the moment CSPACE-4928 which deals with dropping the time portion of date-relevant-only displays.) Are there issues (other than the complexities of pulling this data back out in reports) with changing a calendar date field into a structured date field? Or is there a better way to handle this date approximation problem? >>> >>> >>> Peter >>> -- >>> Peter Murray >>> Dev/Ops Lead and Project Manager >>> Cherry Hill Company >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Wow -- that is nice. I hadn't heard of Antlr before. This might date my learning, but I cut my language parsing teeth when Bison and Flex were the bees knees. This would be a nice thing to add to an implementation. I don't quite see how it hooks in, though; I'll have to study it some more in relation to the services directory. Peter > On Nov 24, 2015, at 2:32 PM, Chris Hoffman <chris_h@berkeley.edu> wrote: > > Yes, dates are a source of many CSpace headaches! > > Ray Lee has built a wonderful customization in place at Berkeley. > https://github.com/cspace-deployment/services/tree/master/services/structureddate <https://github.com/cspace-deployment/services/tree/master/services/structureddate> > > People enter a text string in the display date, and the structured date components are calculated and entered. It uses a grammar file that might need to be customized for different date data entry norms of behavior, but it is very powerful. > > Chris > > >> On Nov 24, 2015, at 8:14 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> >> Ah, I had not considered the implications of search. Hmmm... We had noticed that the display date field is not automatically computed when one enters values into the structured fields of the date. This is a similar kind of issue, except that it is impacting how the data is searched. This is now ringing bells from a time a few years ago when I was looking that the Library of Congress' Extended Date-Time Format (https://www.loc.gov/standards/datetime/ <https://www.loc.gov/standards/datetime/>), except I think CSpace's structure date format is even more precise than EDTF. >> >> I'm starting to think of handling dates/times with the same loathing I usually reserve for handling Unicode in non-native-Unicode systems... >> >> >> Peter >> >>> On Nov 23, 2015, at 2:47 PM, Chris Hoffman <chris_h@berkeley.edu <mailto:chris_h@berkeley.edu>> wrote: >>> >>> Hi Peter, >>> >>> We at Berkeley have customized a number of schema to add a structured date version of something that is a calendar date in core CollectionSpace. It can be a bit of a hassle to get something computable out of that structured date schema, but at least it’s a problem that the museum community knows very well. Then it becomes a functional discussion to determine which part of the structured date to pull out for reports and web sites. Also, I think that there are clever things that can be done outside of CollectionSpace with different kinds of extracted date values (e.g., in Solr) in order to provide nice functionality. >>> >>> Another consideration would be what you might need to do on the Advanced Search screen that corresponds to the record type. You might need to add the Structured Date search widget, which is essentially checking some of the calendar begin and end dates that are calculated and stored in the structured date schema. >>> >>> Wow, does any of this make sense?! >>> >>> Thanks, >>> Chris >>> >>> >>>> On Nov 23, 2015, at 11:09 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >>>> >>>> A question about how to handle this issue: >>>> >>>>> Sometimes we do not know the full date for an accession acquisition or loan, perhaps we only have a year or month/year. Is there a way to make this more flexible but keep some structure? >>>> >>>> When you put something into a calendar date field, what is stored and spit back is the complete ISO-8601 time format, when what is really wanted is the approximations available in the structured date field. (Setting aside for the moment CSPACE-4928 which deals with dropping the time portion of date-relevant-only displays.) Are there issues (other than the complexities of pulling this data back out in reports) with changing a calendar date field into a structured date field? Or is there a better way to handle this date approximation problem? >>>> >>>> >>>> Peter >>>> -- >>>> Peter Murray >>>> Dev/Ops Lead and Project Manager >>>> Cherry Hill Company >>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org> >>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >> -- >> Peter Murray >> Dev/Ops Lead and Project Manager >> Cherry Hill Company >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

Hi Peter, There are a couple additional pieces needed to hook it in. That code in the services layer is just a library that provides a Java API to do the parsing. I put it there thinking it would be useful to have in the services layer, but ended up not using it there. Instead there's some app layer code that wraps that API as a web service accepting a date string and returning a parsed date as JSON, and some UI modifications so that when a display date is entered in the structured date popup, the web service is called and the results are entered in the appropriate fields. Ray On Tue, Nov 24, 2015 at 3:35 PM, Peter Murray <pmurray@chillco.com> wrote: > Wow -- that is nice. I hadn't heard of Antlr before. This might date my > learning, but I cut my language parsing teeth when Bison and Flex were the > bees knees. This would be a nice thing to add to an implementation. I > don't quite see how it hooks in, though; I'll have to study it some more in > relation to the services directory. > > > Peter > > > On Nov 24, 2015, at 2:32 PM, Chris Hoffman <chris_h@berkeley.edu> wrote: > > Yes, dates are a source of many CSpace headaches! > > Ray Lee has built a wonderful customization in place at Berkeley. > > https://github.com/cspace-deployment/services/tree/master/services/structureddate > > People enter a text string in the display date, and the structured date > components are calculated and entered. It uses a grammar file that might > need to be customized for different date data entry norms of behavior, but > it is very powerful. > > Chris > > > On Nov 24, 2015, at 8:14 AM, Peter Murray <pmurray@chillco.com> wrote: > > Ah, I had not considered the implications of search. Hmmm... We had > noticed that the display date field is not automatically computed when one > enters values into the structured fields of the date. This is a similar > kind of issue, except that it is impacting how the data is searched. This > is now ringing bells from a time a few years ago when I was looking that > the Library of Congress' Extended Date-Time Format ( > https://www.loc.gov/standards/datetime/), except I think CSpace's > structure date format is even more precise than EDTF. > > I'm starting to think of handling dates/times with the same loathing I > usually reserve for handling Unicode in non-native-Unicode systems... > > > Peter > > On Nov 23, 2015, at 2:47 PM, Chris Hoffman <chris_h@berkeley.edu> wrote: > > Hi Peter, > > We at Berkeley have customized a number of schema to add a structured date > version of something that is a calendar date in core CollectionSpace. It > can be a bit of a hassle to get something computable out of that structured > date schema, but at least it’s a problem that the museum community knows > very well. Then it becomes a functional discussion to determine which part > of the structured date to pull out for reports and web sites. Also, I think > that there are clever things that can be done outside of CollectionSpace > with different kinds of extracted date values (e.g., in Solr) in order to > provide nice functionality. > > Another consideration would be what you might need to do on the Advanced > Search screen that corresponds to the record type. You might need to add > the Structured Date search widget, which is essentially checking some of > the calendar begin and end dates that are calculated and stored in the > structured date schema. > > Wow, does any of this make sense?! > > Thanks, > Chris > > > On Nov 23, 2015, at 11:09 AM, Peter Murray <pmurray@chillco.com> wrote: > > A question about how to handle this issue: > > Sometimes we do not know the full date for an accession acquisition or > loan, perhaps we only have a year or month/year. Is there a way to make > this more flexible but keep some structure? > > > When you put something into a calendar date field, what is stored and spit > back is the complete ISO-8601 time format, when what is really wanted is > the approximations available in the structured date field. (Setting aside > for the moment CSPACE-4928 which deals with dropping the time portion of > date-relevant-only displays.) Are there issues (other than the > complexities of pulling this data back out in reports) with changing a > calendar date field into a structured date field? Or is there a better way > to handle this date approximation problem? > > > Peter > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

By the way, we’d dearly love to contribute this to the core code. There are some complications, in addition to the ones Ray’s mentioned. For example, given that CollectionSpace is an international system, we have to document (and possibly simplify) the internationalization of this code. I think that’s not too bad, given the antlr grammar, but minimally there should be some other examples than the one we’ve implemented at Berkeley. Chris > On Nov 24, 2015, at 3:59 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > Hi Peter, > There are a couple additional pieces needed to hook it in. That code in the services layer is just a library that provides a Java API to do the parsing. I put it there thinking it would be useful to have in the services layer, but ended up not using it there. Instead there's some app layer code that wraps that API as a web service accepting a date string and returning a parsed date as JSON, and some UI modifications so that when a display date is entered in the structured date popup, the web service is called and the results are entered in the appropriate fields. > > Ray > > > On Tue, Nov 24, 2015 at 3:35 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > Wow -- that is nice. I hadn't heard of Antlr before. This might date my learning, but I cut my language parsing teeth when Bison and Flex were the bees knees. This would be a nice thing to add to an implementation. I don't quite see how it hooks in, though; I'll have to study it some more in relation to the services directory. > > > Peter > > >> On Nov 24, 2015, at 2:32 PM, Chris Hoffman <chris_h@berkeley.edu <mailto:chris_h@berkeley.edu>> wrote: >> >> Yes, dates are a source of many CSpace headaches! >> >> Ray Lee has built a wonderful customization in place at Berkeley. >> https://github.com/cspace-deployment/services/tree/master/services/structureddate <https://github.com/cspace-deployment/services/tree/master/services/structureddate> >> >> People enter a text string in the display date, and the structured date components are calculated and entered. It uses a grammar file that might need to be customized for different date data entry norms of behavior, but it is very powerful. >> >> Chris >> >> >>> On Nov 24, 2015, at 8:14 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >>> >>> Ah, I had not considered the implications of search. Hmmm... We had noticed that the display date field is not automatically computed when one enters values into the structured fields of the date. This is a similar kind of issue, except that it is impacting how the data is searched. This is now ringing bells from a time a few years ago when I was looking that the Library of Congress' Extended Date-Time Format (https://www.loc.gov/standards/datetime/ <https://www.loc.gov/standards/datetime/>), except I think CSpace's structure date format is even more precise than EDTF. >>> >>> I'm starting to think of handling dates/times with the same loathing I usually reserve for handling Unicode in non-native-Unicode systems... >>> >>> >>> Peter >>> >>>> On Nov 23, 2015, at 2:47 PM, Chris Hoffman <chris_h@berkeley.edu <mailto:chris_h@berkeley.edu>> wrote: >>>> >>>> Hi Peter, >>>> >>>> We at Berkeley have customized a number of schema to add a structured date version of something that is a calendar date in core CollectionSpace. It can be a bit of a hassle to get something computable out of that structured date schema, but at least it’s a problem that the museum community knows very well. Then it becomes a functional discussion to determine which part of the structured date to pull out for reports and web sites. Also, I think that there are clever things that can be done outside of CollectionSpace with different kinds of extracted date values (e.g., in Solr) in order to provide nice functionality. >>>> >>>> Another consideration would be what you might need to do on the Advanced Search screen that corresponds to the record type. You might need to add the Structured Date search widget, which is essentially checking some of the calendar begin and end dates that are calculated and stored in the structured date schema. >>>> >>>> Wow, does any of this make sense?! >>>> >>>> Thanks, >>>> Chris >>>> >>>> >>>>> On Nov 23, 2015, at 11:09 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >>>>> >>>>> A question about how to handle this issue: >>>>> >>>>>> Sometimes we do not know the full date for an accession acquisition or loan, perhaps we only have a year or month/year. Is there a way to make this more flexible but keep some structure? >>>>> >>>>> When you put something into a calendar date field, what is stored and spit back is the complete ISO-8601 time format, when what is really wanted is the approximations available in the structured date field. (Setting aside for the moment CSPACE-4928 which deals with dropping the time portion of date-relevant-only displays.) Are there issues (other than the complexities of pulling this data back out in reports) with changing a calendar date field into a structured date field? Or is there a better way to handle this date approximation problem? >>>>> >>>>> >>>>> Peter >>>>> -- >>>>> Peter Murray >>>>> Dev/Ops Lead and Project Manager >>>>> Cherry Hill Company >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org> >>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org <http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org> >>> >>> >>> -- >>> Peter Murray >>> Dev/Ops Lead and Project Manager >>> Cherry Hill Company >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org <http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org> > > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org <mailto:Talk@lists.collectionspace.org> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org <http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org> > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org