I'd like to gauge community interest in adding a notes field to the dimensions repeating group.  This would be a repeating, per-measurement note, not an overall dimensions note.  PAHMA would use it for legacy data and for data entry for measurement-specific notes such as "measured at greatest diameter of base" or "estimated; edges are damaged."


                             Because fields from schema extensions cannot currently be added to core repeating groups, so we'd have to scrap the core dimensions group and then create an extension schema with the same fields *plus* the new notes field.  We've done this before (to add a notes field to Other Numbers), but in the case of Dimensions, we'd be losing out on future functionality (e.g., the promise of the Dimension Summary field) if we abandoned the core Dimensions group in favor of an extension Dimensions group.


                             The change to the user experience/UI would be minimal — just one additional field in an existing row of fields, no larger/taller than any of the existing fields in that group.  This change would be backwards compatible with earlier CSpace versions, as it's a simple addition of a field; no existing core fields would be altered.  As such, it should not create any problems in upgrading existing data.


                             What do you think?  If others publicly express interest, we could hopefully get this field added to the CSpace core!

 <xs:element name="measuredPart" type="xs:string"/>
 <xs:element name="dimension" type="xs:string"/>
 <xs:element name="measuredBy" type="xs:string"/>
 <xs:element name="measurementUnit" type="xs:string"/>
 <xs:element name="measurementMethod" type="xs:string"/>
 <xs:element name="notes" type="xs:string"/>       <!-- PROPOSED NEW FIELD -->
 <xs:element name="value" type="xs:decimal"/>
 <xs:element name="valueDate" type="xs:string"/>
 <xs:element name="valueQualifier" type="xs:string"/>

John brings up the point that we could just extend the core schema, but not add the dimension notes field to the default UI. This makes a lot of sense, if there are more deployers who won't want to use the field than there are those who do. I don't have a good feel for this. Comments? We could just make the schema change for 2.1 since it's about to close, and see if there's demand for the field to be included in the default UI later. Ray On Jan 27, 2012, at 4:19 PM, John Keller wrote: > Ray, > > I don't think Note should be added to the UI by default. Instead, I think it should be left to tenants to make the choice to display it. This would make the addition less disruptive to folks that are using the default html for this section and don't want Notes added to it. Just my two cents... > > - john > > > > On 01/27/2012 04:08 PM, Ray Lee wrote: >> >> Hi everyone, >> While I'm making these changes: Does the ordering of the dimension fields in the core UI make sense? Currently, they look like this: >> >> Dimension Value Method Measured By Dimension Unit Value Qualifier Date >> >> >> It seems more logical to have the value, unit, and qualifier grouped together. With the addition of Note, here's what I propose: >> >> >> Dimension Measured By Method Value Dimension Unit Value Qualifier Date Note >> >> >> If there are no objections, I'll make this change while adding the Note field. >> >> Thanks, >> Ray >> >> >> >> >> On Jan 25, 2012, at 8:48 AM, Chris Hoffman wrote: >> >>> Hi all, >>> I guess I'm fine having UCB do that work locally. I'm also trying to see if someone on our team can do the work on 4 structured dates needed by PAHMA now (they were originally targeted for 2.0 but missed the boat). So we'll have to figure out how someone on my team can make these changes and have those make their way into the core. >>> Thanks, >>> Chris >>> >>> On Jan 23, 2012, at 8:25 AM, Michael T. Black wrote: >>> >>>> Hi Megan, >>>> >>>> Thanks for the good news! From my perspective, both approaches are acceptable, although having it be a UCB-deployment contribution might be preferable if going that route means that it'll be implemented sooner. >>>> >>>> I'll defer to Chris Hoffman for making the decision on which approach is best, as it'll be his group doing the work. >>>> >>>> Thanks again, >>>> >>>> Michael >>>> >>>> On Jan 23, 2012, at 8:14 AM, Megan Forbes wrote: >>>> >>>>> Michael, >>>>> >>>>> Thanks for bringing this up. Because of the current limitation you note - implementers can't add new fields to existing groups of fields, but instead must create a whole new group as an extension - this seems like a reasonable request. >>>>> >>>>> Please let me know if you were hoping to have the core team take care of this change, in which case I'll have to work it in among our other priorities, or if it would be a UCB--deployment contribution. >>>>> >>>>> Thanks, >>>>> Megan >>>>> >>>>> >>>>> On Tue, Jan 17, 2012 at 5:59 PM, Michael T. Black <mtblack@berkeley.edu> wrote: >>>>> Hi all, >>>>> >>>>> >>>>> I'd like to gauge community interest in adding a notes field to the dimensions repeating group. This would be a repeating, per-measurement note, not an overall dimensions note. PAHMA would use it for legacy data and for data entry for measurement-specific notes such as "measured at greatest diameter of base" or "estimated; edges are damaged." >>>>> >>>>> >>>>> Because fields from schema extensions cannot currently be added to core repeating groups, so we'd have to scrap the core dimensions group and then create an extension schema with the same fields *plus* the new notes field. We've done this before (to add a notes field to Other Numbers), but in the case of Dimensions, we'd be losing out on future functionality (e.g., the promise of the Dimension Summary field) if we abandoned the core Dimensions group in favor of an extension Dimensions group. >>>>> >>>>> >>>>> The change to the user experience/UI would be minimal — just one additional field in an existing row of fields, no larger/taller than any of the existing fields in that group. This change would be backwards compatible with earlier CSpace versions, as it's a simple addition of a field; no existing core fields would be altered. As such, it should not create any problems in upgrading existing data. >>>>> >>>>> >>>>> What do you think? If others publicly express interest, we could hopefully get this field added to the CSpace core! >>>>> >>>>> Thanks, >>>>> >>>>> Michael >>>>> >>>>> <xs:element name="measuredPart" type="xs:string"/> >>>>> <xs:element name="dimension" type="xs:string"/> >>>>> <xs:element name="measuredBy" type="xs:string"/> >>>>> <xs:element name="measurementUnit" type="xs:string"/> >>>>> <xs:element name="measurementMethod" type="xs:string"/> >>>>> <xs:element name="notes" type="xs:string"/> <!-- PROPOSED NEW FIELD --> >>>>> <xs:element name="value" type="xs:decimal"/> >>>>> <xs:element name="valueDate" type="xs:string"/> >>>>> <xs:element name="valueQualifier" type="xs:string"/> >>>>> >>>>> >>>>> >>>>> -- >>>>> Megan Forbes >>>>> Collection Manager >>>>> >>>>> Museum of the Moving Image >>>>> 36-01 35 Avenue Astoria, NY 11106 >>>>> movingimage.us 718 777 6800 >>>>> Direct 718 777 6834 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk mailing list >>>> 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 >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > -- > John W Keller > Web/Db Applications Programmer > EECS and IST, UC Berkeley > jkeller@berkeley.edu

<xs:element name="value" type="xs:decimal"/>

                             I'd like to gauge community interest

                             Because fields from schema

                             The change to the user experience/UI

                             What do you think?  If others

 <xs:element name="measuredPart" type="xs:string"/>
 <xs:element name="dimension" type="xs:string"/>
 <xs:element name="measuredBy" type="xs:string"/>
 <xs:element name="measurementUnit" type="xs:string"/>
 <xs:element name="measurementMethod" type="xs:string"/>
 <xs:element name="notes" type="xs:string"/>       <!-- PROPOSED

Another schema point that will need to be addressed someday, though perhaps not now. The value is constraint to being a decimal number. <xs:element name="value" type="xs:decimal"/> However, at PAHMA already there are: - "dimension ranges", e.g. "Wd. 27-29 cm.", i.e. "27 to 29 centimeters wide" - "fractional representations", "2 3/4 inches", which, I am told, is not the same as "2.75 inches". An ideal representation would make <value> some sort of intelligent data type, one that would know how to interpret itself for use as a decimal number when needed. I going to guess that for PAHMA we will work around this limitation by putting ranges and fractional values in the notes fields and picking something appropriate for <value>. Is this worth filing an enhancement JIRA? John > John brings up the point that we could just extend the core schema, but > not add the dimension notes field to the default UI. This makes a lot of > sense, if there are more deployers who won't want to use the field than > there are those who do. I don't have a good feel for this. Comments? > > We could just make the schema change for 2.1 since it's about to close, > and see if there's demand for the field to be included in the default UI > later. > > Ray > > > On Jan 27, 2012, at 4:19 PM, John Keller wrote: > >> Ray, >> >> I don't think Note should be added to the UI by default. Instead, I >> think it should be left to tenants to make the choice to display it. >> This would make the addition less disruptive to folks that are using the >> default html for this section and don't want Notes added to it. Just my >> two cents... >> >> - john >> >> >> >> On 01/27/2012 04:08 PM, Ray Lee wrote: >>> >>> Hi everyone, >>> While I'm making these changes: Does the ordering of the dimension >>> fields in the core UI make sense? Currently, they look like this: >>> >>> Dimension Value Method Measured By Dimension Unit Value Qualifier Date >>> >>> >>> It seems more logical to have the value, unit, and qualifier grouped >>> together. With the addition of Note, here's what I propose: >>> >>> >>> Dimension Measured By Method Value Dimension Unit Value >>> Qualifier Date Note >>> >>> >>> If there are no objections, I'll make this change while adding the Note >>> field. >>> >>> Thanks, >>> Ray >>> >>> >>> >>> >>> On Jan 25, 2012, at 8:48 AM, Chris Hoffman wrote: >>> >>>> Hi all, >>>> I guess I'm fine having UCB do that work locally. I'm also trying to >>>> see if someone on our team can do the work on 4 structured dates >>>> needed by PAHMA now (they were originally targeted for 2.0 but missed >>>> the boat). So we'll have to figure out how someone on my team can >>>> make these changes and have those make their way into the core. >>>> Thanks, >>>> Chris >>>> >>>> On Jan 23, 2012, at 8:25 AM, Michael T. Black wrote: >>>> >>>>> Hi Megan, >>>>> >>>>> Thanks for the good news! From my perspective, both approaches are >>>>> acceptable, although having it be a UCB-deployment contribution >>>>> might be preferable if going that route means that it'll be >>>>> implemented sooner. >>>>> >>>>> I'll defer to Chris Hoffman for making the decision on which >>>>> approach is best, as it'll be his group doing the work. >>>>> >>>>> Thanks again, >>>>> >>>>> Michael >>>>> >>>>> On Jan 23, 2012, at 8:14 AM, Megan Forbes wrote: >>>>> >>>>>> Michael, >>>>>> >>>>>> Thanks for bringing this up. Because of the current limitation you >>>>>> note - implementers can't add new fields to existing groups of >>>>>> fields, but instead must create a whole new group as an >>>>>> extension - this seems like a reasonable request. >>>>>> >>>>>> Please let me know if you were hoping to have the core team take >>>>>> care of this change, in which case I'll have to work it in among our >>>>>> other priorities, or if it would be a UCB--deployment contribution. >>>>>> >>>>>> Thanks, >>>>>> Megan >>>>>> >>>>>> >>>>>> On Tue, Jan 17, 2012 at 5:59 PM, Michael T. Black >>>>>> <mtblack@berkeley.edu> wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> I'd like to gauge community interest >>>>>> in adding a notes field to the >>>>>> dimensions repeating group. This >>>>>> would be a repeating, >>>>>> per-measurement note, not an overall >>>>>> dimensions note. PAHMA would use it >>>>>> for legacy data and for data entry >>>>>> for measurement-specific notes such >>>>>> as "measured at greatest diameter of >>>>>> base" or "estimated; edges are >>>>>> damaged." >>>>>> >>>>>> >>>>>> Because fields from schema >>>>>> extensions cannot currently be added >>>>>> to core repeating groups, so we'd >>>>>> have to scrap the core dimensions >>>>>> group and then create an extension >>>>>> schema with the same fields *plus* >>>>>> the new notes field. We've done >>>>>> this before (to add a notes field to >>>>>> Other Numbers), but in the case of >>>>>> Dimensions, we'd be losing out on >>>>>> future functionality (e.g., the >>>>>> promise of the Dimension Summary >>>>>> field) if we abandoned the core >>>>>> Dimensions group in favor of an >>>>>> extension Dimensions group. >>>>>> >>>>>> >>>>>> The change to the user experience/UI >>>>>> would be minimal — just one >>>>>> additional field in an existing row >>>>>> of fields, no larger/taller than any >>>>>> of the existing fields in that >>>>>> group. This change would be >>>>>> backwards compatible with earlier >>>>>> CSpace versions, as it's a simple >>>>>> addition of a field; no existing >>>>>> core fields would be altered. As >>>>>> such, it should not create any >>>>>> problems in upgrading existing data. >>>>>> >>>>>> >>>>>> What do you think? If others >>>>>> publicly express interest, we could >>>>>> hopefully get this field added to >>>>>> the CSpace core! >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Michael >>>>>> >>>>>> <xs:element name="measuredPart" type="xs:string"/> >>>>>> <xs:element name="dimension" type="xs:string"/> >>>>>> <xs:element name="measuredBy" type="xs:string"/> >>>>>> <xs:element name="measurementUnit" type="xs:string"/> >>>>>> <xs:element name="measurementMethod" type="xs:string"/> >>>>>> <xs:element name="notes" type="xs:string"/> <!-- PROPOSED >>>>>> NEW FIELD --> >>>>>> <xs:element name="value" type="xs:decimal"/> >>>>>> <xs:element name="valueDate" type="xs:string"/> >>>>>> <xs:element name="valueQualifier" type="xs:string"/> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Megan Forbes >>>>>> Collection Manager >>>>>> >>>>>> Museum of the Moving Image >>>>>> 36-01 35 Avenue Astoria, NY 11106 >>>>>> movingimage.us 718 777 6800 >>>>>> Direct 718 777 6834 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> 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 >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> -- >> John W Keller >> Web/Db Applications Programmer >> EECS and IST, UC Berkeley >> jkeller@berkeley.edu > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >