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.

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"/>

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

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.

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"/>

I prefer your suggested order. Thanks, Michael On Jan 27, 2012, at 4: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 >

Ray wrote: > 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 DateNote Michael wrote: > I prefer your suggested order. Agreed as well. And as a bonus, your sensible reordering of fields happens to resolve this JIRA: Dimension unit field in Cataloging and Media templates should appear to the immediate right of the dimension value field http://issues.collectionspace.org/browse/CSPACE-4638 :-) Aron

                  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.

<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"/>

Thanks Ray. We fully agree! Cheers, Kim ________________________________ Fra: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] På vegne af Ray Lee Sendt: 28. januar 2012 01:08 Til: Chris Hoffman Cc: talk@lists.collectionspace.org Emne: Re: [Talk] Proposed addition to Dimensions core fields 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 <http://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