MT
Michael T. Black
Tue, Jan 17, 2012 10:59 PM
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"/>
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"/>
RL
Ray Lee
Tue, Jan 17, 2012 11:45 PM
Hi Michael,
Agreed that having this in the core schema would be nice. Here are a couple things to consider. In 2.0, the dimension group looks a little different than it did in 1.12. There's a repeating group for each part, and a repeating table of measurements within each part group:
So, there is the option of having a note at the part level, instead of or in addition to the measurement level. Also, if the note is at the measurement level, there may need to be some reworking of the UI, since the table is already pretty crowded. You'd probably only be able to see the first couple words of the note, if it were just an additional column.
This is the schema definition:
<xs:complexType name="measuredPartGroupList">
<xs:sequence>
<xs:element name="measuredPartGroup" type="measuredPartGroup" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="measuredPartGroup">
<xs:sequence>
<xs:element name="measuredPart" type="xs:string"/>
<xs:element name="dimensionSummary" type="xs:string" />
<xs:element name="dimensionSubGroupList" type="dimensionSubGroupList"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroupList">
<xs:sequence>
<xs:element name="dimensionSubGroup" type="dimensionSubGroup" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroup">
<xs:sequence>
<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="value" type="xs:decimal"/>
<xs:element name="valueDate" type="xs:dateTime"/>
<xs:element name="valueQualifier" type="xs:string"/>
</xs:sequence>
</xs:complexType>
Ray
On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Hi Michael,
Agreed that having this in the core schema would be nice. Here are a couple things to consider. In 2.0, the dimension group looks a little different than it did in 1.12. There's a repeating group for each part, and a repeating table of measurements within each part group:
So, there is the option of having a note at the part level, instead of or in addition to the measurement level. Also, if the note is at the measurement level, there may need to be some reworking of the UI, since the table is already pretty crowded. You'd probably only be able to see the first couple words of the note, if it were just an additional column.
This is the schema definition:
<xs:complexType name="measuredPartGroupList">
<xs:sequence>
<xs:element name="measuredPartGroup" type="measuredPartGroup" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="measuredPartGroup">
<xs:sequence>
<xs:element name="measuredPart" type="xs:string"/>
<xs:element name="dimensionSummary" type="xs:string" />
<xs:element name="dimensionSubGroupList" type="dimensionSubGroupList"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroupList">
<xs:sequence>
<xs:element name="dimensionSubGroup" type="dimensionSubGroup" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroup">
<xs:sequence>
<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="value" type="xs:decimal"/>
<xs:element name="valueDate" type="xs:dateTime"/>
<xs:element name="valueQualifier" type="xs:string"/>
</xs:sequence>
</xs:complexType>
Ray
On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
MT
Michael T. Black
Tue, Jan 17, 2012 11:56 PM
Hi Ray,
Thanks for pointing this out — I was still picturing the group as it was in 1.8-1.12.
We'd still need to have the note be at the per-measurement level. Even seeing just the first word or two would be fine (most such notes are just a couple of words), and users could click into the field to read the full note. If really pressed for space, we'd probably reduce or eliminate measurementMethod (in our PAHMA deployment) to accommodate the notes field, although it would be nice to have both.
I'm interested to what other potential users of the Dimension group think about squeezing a notes field in. Please chime in!
Thanks,
Michael
On Jan 17, 2012, at 3:45 PM, Ray Lee wrote:
Hi Michael,
Agreed that having this in the core schema would be nice. Here are a couple things to consider. In 2.0, the dimension group looks a little different than it did in 1.12. There's a repeating group for each part, and a repeating table of measurements within each part group:
<dimensions.png>
So, there is the option of having a note at the part level, instead of or in addition to the measurement level. Also, if the note is at the measurement level, there may need to be some reworking of the UI, since the table is already pretty crowded. You'd probably only be able to see the first couple words of the note, if it were just an additional column.
This is the schema definition:
<xs:complexType name="measuredPartGroupList">
<xs:sequence>
<xs:element name="measuredPartGroup" type="measuredPartGroup" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="measuredPartGroup">
<xs:sequence>
<xs:element name="measuredPart" type="xs:string"/>
<xs:element name="dimensionSummary" type="xs:string" />
<xs:element name="dimensionSubGroupList" type="dimensionSubGroupList"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroupList">
<xs:sequence>
<xs:element name="dimensionSubGroup" type="dimensionSubGroup" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroup">
<xs:sequence>
<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="value" type="xs:decimal"/>
<xs:element name="valueDate" type="xs:dateTime"/>
<xs:element name="valueQualifier" type="xs:string"/>
</xs:sequence>
</xs:complexType>
Ray
On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Hi Ray,
Thanks for pointing this out — I was still picturing the group as it was in 1.8-1.12.
We'd still need to have the note be at the per-measurement level. Even seeing just the first word or two would be fine (most such notes are just a couple of words), and users could click into the field to read the full note. If really pressed for space, we'd probably reduce or eliminate measurementMethod (in our PAHMA deployment) to accommodate the notes field, although it would be nice to have both.
I'm interested to what other potential users of the Dimension group think about squeezing a notes field in. Please chime in!
Thanks,
Michael
On Jan 17, 2012, at 3:45 PM, Ray Lee wrote:
> Hi Michael,
> Agreed that having this in the core schema would be nice. Here are a couple things to consider. In 2.0, the dimension group looks a little different than it did in 1.12. There's a repeating group for each part, and a repeating table of measurements within each part group:
>
> <dimensions.png>
>
>
> So, there is the option of having a note at the part level, instead of or in addition to the measurement level. Also, if the note is at the measurement level, there may need to be some reworking of the UI, since the table is already pretty crowded. You'd probably only be able to see the first couple words of the note, if it were just an additional column.
>
> This is the schema definition:
>
> <xs:complexType name="measuredPartGroupList">
> <xs:sequence>
> <xs:element name="measuredPartGroup" type="measuredPartGroup" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
> <xs:complexType name="measuredPartGroup">
> <xs:sequence>
> <xs:element name="measuredPart" type="xs:string"/>
> <xs:element name="dimensionSummary" type="xs:string" />
> <xs:element name="dimensionSubGroupList" type="dimensionSubGroupList"/>
> </xs:sequence>
> </xs:complexType>
>
> <xs:complexType name="dimensionSubGroupList">
> <xs:sequence>
> <xs:element name="dimensionSubGroup" type="dimensionSubGroup" minOccurs="0" maxOccurs="unbounded" />
> </xs:sequence>
> </xs:complexType>
>
> <xs:complexType name="dimensionSubGroup">
> <xs:sequence>
> <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="value" type="xs:decimal"/>
> <xs:element name="valueDate" type="xs:dateTime"/>
> <xs:element name="valueQualifier" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
>
> Ray
>
>
> On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
>> _______________________________________________
>> Talk mailing list
>> Talk@lists.collectionspace.org
>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
JE
Janice Eklund
Wed, Jan 18, 2012 5:07 PM
I don't believe HAVRC will have any immediate use for this field but I
can see how it might be generally useful for other collections so I
would not object to its inclusion.
On 1/17/12, Michael T. Black mtblack@berkeley.edu wrote:
Hi Ray,
Thanks for pointing this out — I was still picturing the group as it was in
1.8-1.12.
We'd still need to have the note be at the per-measurement level. Even
seeing just the first word or two would be fine (most such notes are just a
couple of words), and users could click into the field to read the full
note. If really pressed for space, we'd probably reduce or eliminate
measurementMethod (in our PAHMA deployment) to accommodate the notes field,
although it would be nice to have both.
I'm interested to what other potential users of the Dimension group think
about squeezing a notes field in. Please chime in!
Thanks,
Michael
On Jan 17, 2012, at 3:45 PM, Ray Lee wrote:
Hi Michael,
Agreed that having this in the core schema would be nice. Here are a
couple things to consider. In 2.0, the dimension group looks a little
different than it did in 1.12. There's a repeating group for each part,
and a repeating table of measurements within each part group:
<dimensions.png>
So, there is the option of having a note at the part level, instead of or
in addition to the measurement level. Also, if the note is at the
measurement level, there may need to be some reworking of the UI, since
the table is already pretty crowded. You'd probably only be able to see
the first couple words of the note, if it were just an additional column.
This is the schema definition:
<xs:complexType name="measuredPartGroupList">
<xs:sequence>
<xs:element name="measuredPartGroup" type="measuredPartGroup"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="measuredPartGroup">
xs:sequence
<xs:element name="measuredPart" type="xs:string"/>
<xs:element name="dimensionSummary" type="xs:string" />
<xs:element name="dimensionSubGroupList"
type="dimensionSubGroupList"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroupList">
<xs:sequence>
<xs:element name="dimensionSubGroup" type="dimensionSubGroup"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroup">
<xs:sequence>
<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="value" type="xs:decimal"/>
<xs:element name="valueDate" type="xs:dateTime"/>
<xs:element name="valueQualifier" type="xs:string"/>
</xs:sequence>
</xs:complexType>
Ray
On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
I don't believe HAVRC will have any immediate use for this field but I
can see how it might be generally useful for other collections so I
would not object to its inclusion.
On 1/17/12, Michael T. Black <mtblack@berkeley.edu> wrote:
> Hi Ray,
>
> Thanks for pointing this out — I was still picturing the group as it was in
> 1.8-1.12.
>
> We'd still need to have the note be at the per-measurement level. Even
> seeing just the first word or two would be fine (most such notes are just a
> couple of words), and users could click into the field to read the full
> note. If really pressed for space, we'd probably reduce or eliminate
> measurementMethod (in our PAHMA deployment) to accommodate the notes field,
> although it would be nice to have both.
>
> I'm interested to what other potential users of the Dimension group think
> about squeezing a notes field in. Please chime in!
>
> Thanks,
>
> Michael
>
> On Jan 17, 2012, at 3:45 PM, Ray Lee wrote:
>
>> Hi Michael,
>> Agreed that having this in the core schema would be nice. Here are a
>> couple things to consider. In 2.0, the dimension group looks a little
>> different than it did in 1.12. There's a repeating group for each part,
>> and a repeating table of measurements within each part group:
>>
>> <dimensions.png>
>>
>>
>> So, there is the option of having a note at the part level, instead of or
>> in addition to the measurement level. Also, if the note is at the
>> measurement level, there may need to be some reworking of the UI, since
>> the table is already pretty crowded. You'd probably only be able to see
>> the first couple words of the note, if it were just an additional column.
>>
>> This is the schema definition:
>>
>> <xs:complexType name="measuredPartGroupList">
>> <xs:sequence>
>> <xs:element name="measuredPartGroup" type="measuredPartGroup"
>> minOccurs="0"
>> maxOccurs="unbounded"/>
>> </xs:sequence>
>> </xs:complexType>
>> <xs:complexType name="measuredPartGroup">
>> <xs:sequence>
>> <xs:element name="measuredPart" type="xs:string"/>
>> <xs:element name="dimensionSummary" type="xs:string" />
>> <xs:element name="dimensionSubGroupList"
>> type="dimensionSubGroupList"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> <xs:complexType name="dimensionSubGroupList">
>> <xs:sequence>
>> <xs:element name="dimensionSubGroup" type="dimensionSubGroup"
>> minOccurs="0" maxOccurs="unbounded" />
>> </xs:sequence>
>> </xs:complexType>
>>
>> <xs:complexType name="dimensionSubGroup">
>> <xs:sequence>
>> <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="value" type="xs:decimal"/>
>> <xs:element name="valueDate" type="xs:dateTime"/>
>> <xs:element name="valueQualifier" type="xs:string"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> Ray
>>
>>
>> On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
>>> _______________________________________________
>>> Talk mailing list
>>> Talk@lists.collectionspace.org
>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>>
>
>
RM
Ralph Moon
Wed, Jan 18, 2012 5:11 PM
Michael,
A notes/remarks/comments field accompanies each
dimension/measurement in Artctos and Darwin Core. Examples of its use
included in online documentation include "tip of tail missing,"
"transcribed from collector's journal," and "weighed after substantial
loss of blood." So Arctos and Darwin Core users -- both groups
populated by potential Collection Space users -- seem to have decided
that the proposed field is useful, or even necessary.
--Ralph
On 1/17/2012 3:56 PM, Michael T. Black wrote:
Hi Ray,
Thanks for pointing this out --- I was still picturing the group as it
was in 1.8-1.12.
We'd still need to have the note be at the per-measurement level. Even
seeing just the first word or two would be fine (most such notes are
just a couple of words), and users could click into the field to read
the full note. If really pressed for space, we'd probably reduce or
eliminate measurementMethod (in our PAHMA deployment) to accommodate
the notes field, although it would be nice to have both.
I'm interested to what other potential users of the Dimension group
think about squeezing a notes field in. Please chime in!
Thanks,
Michael
On Jan 17, 2012, at 3:45 PM, Ray Lee wrote:
Hi Michael,
Agreed that having this in the core schema would be nice. Here are a
couple things to consider. In 2.0, the dimension group looks a little
different than it did in 1.12. There's a repeating group for each
part, and a repeating table of measurements within each part group:
<dimensions.png>
So, there is the option of having a note at the part level, instead
of or in addition to the measurement level. Also, if the note is at
the measurement level, there may need to be some reworking of the UI,
since the table is already pretty crowded. You'd probably only be
able to see the first couple words of the note, if it were just an
additional column.
This is the schema definition:
<xs:complexType name="measuredPartGroupList">
xs:sequence
<xs:element name="measuredPartGroup" type="measuredPartGroup"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="measuredPartGroup">
xs:sequence
<xs:element name="measuredPart" type="xs:string"/>
<xs:element name="dimensionSummary" type="xs:string" />
<xs:element name="dimensionSubGroupList" type="dimensionSubGroupList"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroupList">
xs:sequence
<xs:element name="dimensionSubGroup" type="dimensionSubGroup"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroup">
xs:sequence
<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="value" type="xs:decimal"/>
<xs:element name="valueDate" type="xs:dateTime"/>
<xs:element name="valueQualifier" type="xs:string"/>
</xs:sequence>
</xs:complexType>
Ray
On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
Talk mailing list
Talk@lists.collectionspace.org mailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Michael,
A notes/remarks/comments field accompanies each
dimension/measurement in Artctos and Darwin Core. Examples of its use
included in online documentation include "tip of tail missing,"
"transcribed from collector's journal," and "weighed after substantial
loss of blood." So Arctos and Darwin Core users -- both groups
populated by potential Collection Space users -- seem to have decided
that the proposed field is useful, or even necessary.
--Ralph
On 1/17/2012 3:56 PM, Michael T. Black wrote:
> Hi Ray,
>
> Thanks for pointing this out --- I was still picturing the group as it
> was in 1.8-1.12.
>
> We'd still need to have the note be at the per-measurement level. Even
> seeing just the first word or two would be fine (most such notes are
> just a couple of words), and users could click into the field to read
> the full note. If really pressed for space, we'd probably reduce or
> eliminate measurementMethod (in our PAHMA deployment) to accommodate
> the notes field, although it would be nice to have both.
>
> I'm interested to what other potential users of the Dimension group
> think about squeezing a notes field in. Please chime in!
>
> Thanks,
>
> Michael
>
> On Jan 17, 2012, at 3:45 PM, Ray Lee wrote:
>
>> Hi Michael,
>> Agreed that having this in the core schema would be nice. Here are a
>> couple things to consider. In 2.0, the dimension group looks a little
>> different than it did in 1.12. There's a repeating group for each
>> part, and a repeating table of measurements within each part group:
>>
>> <dimensions.png>
>>
>>
>> So, there is the option of having a note at the part level, instead
>> of or in addition to the measurement level. Also, if the note is at
>> the measurement level, there may need to be some reworking of the UI,
>> since the table is already pretty crowded. You'd probably only be
>> able to see the first couple words of the note, if it were just an
>> additional column.
>>
>> This is the schema definition:
>>
>> <xs:complexType name="measuredPartGroupList">
>> <xs:sequence>
>> <xs:element name="measuredPartGroup" type="measuredPartGroup"
>> minOccurs="0"
>> maxOccurs="unbounded"/>
>> </xs:sequence>
>> </xs:complexType>
>> <xs:complexType name="measuredPartGroup">
>> <xs:sequence>
>> <xs:element name="measuredPart" type="xs:string"/>
>> <xs:element name="dimensionSummary" type="xs:string" />
>> <xs:element name="dimensionSubGroupList" type="dimensionSubGroupList"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> <xs:complexType name="dimensionSubGroupList">
>> <xs:sequence>
>> <xs:element name="dimensionSubGroup" type="dimensionSubGroup"
>> minOccurs="0" maxOccurs="unbounded" />
>> </xs:sequence>
>> </xs:complexType>
>>
>> <xs:complexType name="dimensionSubGroup">
>> <xs:sequence>
>> <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="value" type="xs:decimal"/>
>> <xs:element name="valueDate" type="xs:dateTime"/>
>> <xs:element name="valueQualifier" type="xs:string"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> Ray
>>
>>
>> On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
>>> _______________________________________________
>>> Talk mailing list
>>> Talk@lists.collectionspace.org <mailto: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
MT
Michael T. Black
Wed, Jan 18, 2012 8:19 PM
Thanks for the feedback, Ralph!
Michael
On Jan 18, 2012, at 9:11 AM, Ralph Moon wrote:
Michael,
A notes/remarks/comments field accompanies each dimension/measurement in Artctos and Darwin Core. Examples of its use included in online documentation include "tip of tail missing," "transcribed from collector's journal," and "weighed after substantial loss of blood." So Arctos and Darwin Core users -- both groups populated by potential Collection Space users -- seem to have decided that the proposed field is useful, or even necessary.
--Ralph
On 1/17/2012 3:56 PM, Michael T. Black wrote:
Hi Ray,
Thanks for pointing this out — I was still picturing the group as it was in 1.8-1.12.
We'd still need to have the note be at the per-measurement level. Even seeing just the first word or two would be fine (most such notes are just a couple of words), and users could click into the field to read the full note. If really pressed for space, we'd probably reduce or eliminate measurementMethod (in our PAHMA deployment) to accommodate the notes field, although it would be nice to have both.
I'm interested to what other potential users of the Dimension group think about squeezing a notes field in. Please chime in!
Thanks,
Michael
On Jan 17, 2012, at 3:45 PM, Ray Lee wrote:
Hi Michael,
Agreed that having this in the core schema would be nice. Here are a couple things to consider. In 2.0, the dimension group looks a little different than it did in 1.12. There's a repeating group for each part, and a repeating table of measurements within each part group:
<dimensions.png>
So, there is the option of having a note at the part level, instead of or in addition to the measurement level. Also, if the note is at the measurement level, there may need to be some reworking of the UI, since the table is already pretty crowded. You'd probably only be able to see the first couple words of the note, if it were just an additional column.
This is the schema definition:
<xs:complexType name="measuredPartGroupList">
<xs:sequence>
<xs:element name="measuredPartGroup" type="measuredPartGroup" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="measuredPartGroup">
<xs:sequence>
<xs:element name="measuredPart" type="xs:string"/>
<xs:element name="dimensionSummary" type="xs:string" />
<xs:element name="dimensionSubGroupList" type="dimensionSubGroupList"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroupList">
<xs:sequence>
<xs:element name="dimensionSubGroup" type="dimensionSubGroup" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="dimensionSubGroup">
<xs:sequence>
<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="value" type="xs:decimal"/>
<xs:element name="valueDate" type="xs:dateTime"/>
<xs:element name="valueQualifier" type="xs:string"/>
</xs:sequence>
</xs:complexType>
Ray
On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Thanks for the feedback, Ralph!
Michael
On Jan 18, 2012, at 9:11 AM, Ralph Moon wrote:
> Michael,
>
> A notes/remarks/comments field accompanies each dimension/measurement in Artctos and Darwin Core. Examples of its use included in online documentation include "tip of tail missing," "transcribed from collector's journal," and "weighed after substantial loss of blood." So Arctos and Darwin Core users -- both groups populated by potential Collection Space users -- seem to have decided that the proposed field is useful, or even necessary.
>
> --Ralph
>
> On 1/17/2012 3:56 PM, Michael T. Black wrote:
>>
>> Hi Ray,
>>
>> Thanks for pointing this out — I was still picturing the group as it was in 1.8-1.12.
>>
>> We'd still need to have the note be at the per-measurement level. Even seeing just the first word or two would be fine (most such notes are just a couple of words), and users could click into the field to read the full note. If really pressed for space, we'd probably reduce or eliminate measurementMethod (in our PAHMA deployment) to accommodate the notes field, although it would be nice to have both.
>>
>> I'm interested to what other potential users of the Dimension group think about squeezing a notes field in. Please chime in!
>>
>> Thanks,
>>
>> Michael
>>
>> On Jan 17, 2012, at 3:45 PM, Ray Lee wrote:
>>
>>> Hi Michael,
>>> Agreed that having this in the core schema would be nice. Here are a couple things to consider. In 2.0, the dimension group looks a little different than it did in 1.12. There's a repeating group for each part, and a repeating table of measurements within each part group:
>>>
>>> <dimensions.png>
>>>
>>>
>>> So, there is the option of having a note at the part level, instead of or in addition to the measurement level. Also, if the note is at the measurement level, there may need to be some reworking of the UI, since the table is already pretty crowded. You'd probably only be able to see the first couple words of the note, if it were just an additional column.
>>>
>>> This is the schema definition:
>>>
>>> <xs:complexType name="measuredPartGroupList">
>>> <xs:sequence>
>>> <xs:element name="measuredPartGroup" type="measuredPartGroup" minOccurs="0"
>>> maxOccurs="unbounded"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>> <xs:complexType name="measuredPartGroup">
>>> <xs:sequence>
>>> <xs:element name="measuredPart" type="xs:string"/>
>>> <xs:element name="dimensionSummary" type="xs:string" />
>>> <xs:element name="dimensionSubGroupList" type="dimensionSubGroupList"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>>
>>> <xs:complexType name="dimensionSubGroupList">
>>> <xs:sequence>
>>> <xs:element name="dimensionSubGroup" type="dimensionSubGroup" minOccurs="0" maxOccurs="unbounded" />
>>> </xs:sequence>
>>> </xs:complexType>
>>>
>>> <xs:complexType name="dimensionSubGroup">
>>> <xs:sequence>
>>> <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="value" type="xs:decimal"/>
>>> <xs:element name="valueDate" type="xs:dateTime"/>
>>> <xs:element name="valueQualifier" type="xs:string"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>>
>>> Ray
>>>
>>>
>>> On Jan 17, 2012, at 2:59 PM, Michael T. Black 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"/>
>>>> _______________________________________________
>>>> 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
MF
Megan Forbes
Mon, Jan 23, 2012 4:14 PM
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.eduwrote:
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
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
MT
Michael T. Black
Mon, Jan 23, 2012 4:25 PM
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
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
>
>
KJ
King, Joe
Mon, Jan 23, 2012 4:56 PM
Michael,
I am in full agreement that a text field associated with dimension is a necessary and helpful dimension. We have enough anomalies in our collection that further clarification of dimension through the added field, will be most helpful.
Joe
Joseph King
Registrar
Walker Art Center
1750 Hennepin Avenue
Minneapolis, MN 55403
P: 612-375-7563
F: 612-375-7584
From: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Megan Forbes
Sent: Monday, January 23, 2012 10:15 AM
To: Michael T. Black
Cc: talk@lists.collectionspace.org
Subject: Re: [Talk] Proposed addition to Dimensions core fields
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.edumailto: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.ushttp://movingimage.us 718 777 6800
Direct 718 777 6834
--
CONFIDENTIALITY NOTICE: This transmission (including any accompanying attachments) is confidential and may contain privileged or proprietary information that is exempt from disclosure under applicable law. If you are not the intended recipient, or believe that you have received this message in error, you are strictly prohibited from disclosing, copying, distributing, or using the information contained herein. Inadvertent or unauthorized disclosure shall not compromise or waive the confidentiality of this transmission or any applicable attorney-client privilege.
If you have received this transmission in error, please immediately notify us at maildisc@walkerart.org and delete this transmission from your computer.
Michael,
I am in full agreement that a text field associated with dimension is a necessary and helpful dimension. We have enough anomalies in our collection that further clarification of dimension through the added field, will be most helpful.
Joe
Joseph King
Registrar
Walker Art Center
1750 Hennepin Avenue
Minneapolis, MN 55403
P: 612-375-7563
F: 612-375-7584
From: talk-bounces@lists.collectionspace.org [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of Megan Forbes
Sent: Monday, January 23, 2012 10:15 AM
To: Michael T. Black
Cc: talk@lists.collectionspace.org
Subject: Re: [Talk] Proposed addition to Dimensions core fields
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<mailto: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
________________________________
--
CONFIDENTIALITY NOTICE: This transmission (including any accompanying attachments) is confidential and may contain privileged or proprietary information that is exempt from disclosure under applicable law. If you are not the intended recipient, or believe that you have received this message in error, you are strictly prohibited from disclosing, copying, distributing, or using the information contained herein. Inadvertent or unauthorized disclosure shall not compromise or waive the confidentiality of this transmission or any applicable attorney-client privilege.
If you have received this transmission in error, please immediately notify us at maildisc@walkerart.org and delete this transmission from your computer.
CH
Chris Hoffman
Wed, Jan 25, 2012 4:48 PM
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
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