Has anyone attempted import on 3.2? I've been running some old (2.6) import jobs against the latest release (plus local config) and have been having some trouble. I'm attempting to import Place Authorities, and the import itself claims to have succeeded. The records do appear in the Nuxeo database as expected. However, records created in this way are not visible via the Collectionspace UI (using csid) and cannot be found via search. They can be found via the Services API, both listed under the authority and as individual items via the csid. In the results from the Services API, the only difference between these records and those created in the CSpace UI are that these records are missing the refName field (even though the refNames exist in the Nuxeo database table just as expected, in exactly the same format as the Cspace UI created records). Anyone any ideas what could be going wrong here? /Chris

Hi Chris, I did load some Place records for the SaaS demo trial. There is a refname field now in collectionspace_core that is required. It has to be in the main place authority schema too, and they must be identical. Here's an import template I used. Hope this helps, Chris On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: > Has anyone attempted import on 3.2? I’ve been running some old (2.6) import jobs against the latest release (plus local config) and have been having some trouble. I’m attempting to import Place Authorities, and the import itself claims to have succeeded. The records do appear in the Nuxeo database as expected. > > However, records created in this way are not visible via the Collectionspace UI (using csid) and cannot be found via search. They can be found via the Services API, both listed under the authority and as individual items via the csid. In the results from the Services API, the only difference between these records and those created in the CSpace UI are that these records are missing the refName field (even though the refNames exist in the Nuxeo database table just as expected, in exactly the same format as the Cspace UI created records). > > Anyone any ideas what could be going wrong here? > > /Chris > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi, Can someone who understands this well update the imports wiki page to show what needs to go into collectionspace_core and when (3.2+, authorities or everything? what the refname should look like if it is needed for other than authorities)? I don't understand this and I see there are others. Susan On 01/24/2013 08:17 AM, Chris Hoffman wrote: > Hi Chris, > I did load some Place records for the SaaS demo trial. There is a > refname field now in collectionspace_core that is required. It has to > be in the main place authority schema too, and they must be identical. > Here's an import template I used. > Hope this helps, > Chris > > > > > On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: > >> Has anyone attempted import on 3.2? I’ve been running some old (2.6) >> import jobs against the latest release (plus local config) and have >> been having some trouble. I’m attempting to import Place Authorities, >> and the import itself claims to have succeeded. The records do appear >> in the Nuxeo database as expected. >> However, records created in this way are not visible via the >> Collectionspace UI (using csid) and cannot be found via search. They >> can be found via the Services API, both listed under the authority and >> as individual items via the csid. In the results from the Services >> API, the only difference between these records and those created in >> the CSpace UI are that these records are missing the refName field >> (even though the refNames exist in the Nuxeo database table just as >> expected, in exactly the same format as the Cspace UI created records). >> Anyone any ideas what could be going wrong here? >> /Chris >> _______________________________________________ >> 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 >

Thanks Chris! This is just what I was missing. (note: for anyone else attempting this, the tag "schema2" in the template from Chris should be replaced with "schema"). How did you know to add this? Like Susan, I'd like to know the scope of this change (is it for all records?) and if there's any documentation. /Chris ________________________________ Fra: Chris Hoffman [mailto:chris_h@berkeley.edu] Sendt: 24. januar 2013 17:17 Til: Christopher Pott Cc: talk@lists.collectionspace.org Emne: Re: [Talk] importing Place authorities to 3.2 Hi Chris, I did load some Place records for the SaaS demo trial. There is a refname field now in collectionspace_core that is required. It has to be in the main place authority schema too, and they must be identical. Here's an import template I used. Hope this helps, Chris On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: Has anyone attempted import on 3.2? I've been running some old (2.6) import jobs against the latest release (plus local config) and have been having some trouble. I'm attempting to import Place Authorities, and the import itself claims to have succeeded. The records do appear in the Nuxeo database as expected. However, records created in this way are not visible via the Collectionspace UI (using csid) and cannot be found via search. They can be found via the Services API, both listed under the authority and as individual items via the csid. In the results from the Services API, the only difference between these records and those created in the CSpace UI are that these records are missing the refName field (even though the refNames exist in the Nuxeo database table just as expected, in exactly the same format as the Cspace UI created records). Anyone any ideas what could be going wrong here? /Chris _______________________________________________ Talk mailing list Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Hi Chris P., Susan, and all, Thanks much for these questions and this discussion! The only documentation of this change to date, AFAIK, is in the release notes for version 3.0, and that's just in the form of a note suggesting future documentation: http://wiki.collectionspace.org/display/collectionspace/Release+3.0 We'll definitely will document this further, in those Release Notes and on the Import Service Home page, where Chris Hoffman's excellent example (with Chris Pott's correction) will be included. In brief, our collective understanding (with corrections/clarification welcome) is: - refName values have been effectively moved into the collectionspace_core schema, the schema which holds metadata (including creation/update times and authors) for most CollectionSpace records. - When Relation records are created, their refName values are pulled out of the collectionspace_core:refName fields for the subject and object records in that relation. - This effectively means that, at a minimum, when importing records via the Imports service in CollectionSpace 3.0 or later, you'll need to include the collectionspace_core schema on import, along with your other schemas, for any record that's likely to be involved in a relation. This includes: * Cataloging / CollectionObject records * Procedural records (with the possible exception of outliers like reports, id_generators, etc.) * Authority and authority item records Also, there will be a new JIRA issue for inserting these refName values automatically in collectionspace_core during import, rather than requiring that you include those values in your import file. (These values are already added automatically when creating new records via other Services REST API calls ...) Aron On Mon, Jan 28, 2013 at 1:46 AM, Christopher Pott <Christopher.Pott@smk.dk> wrote: > Thanks Chris! This is just what I was missing. (note: for anyone else > attempting this, the tag “schema2” in the template from Chris should be > replaced with “schema”). How did you know to add this? Like Susan, I’d like > to know the scope of this change (is it for all records?) and if there’s any > documentation. On Thu, Jan 24, 2013 at 10:07 AM, Susan Stone <sstone@socrates.berkeley.edu> wrote: > Can someone who understands this well update the imports wiki page to show > what needs to go into collectionspace_core and when (3.2+, authorities or > everything? what the refname should look like if it is needed for other than > authorities)? I don't understand this and I see there are others. -- Chris Hoffman's example (with Chris Pott's sharp-eyed correction): <?xml version="1.0" encoding="UTF-8"?> <imports> <import service="Places" type="Placeitem" CSID=""> <schema xmlns:collectionspace_core="http://collectionspace.org/collectionspace_core/" name="collectionspace_core"> <refName>urn:cspace:museumofman.org:placeauthorities:name(place):item:name(Placedisplayname1354214392756)'Place display name'</refName> </schema> <schema xmlns:places_common="http://collectionspace.org/services/place" name="places_common"> <inAuthority>b9ed4754-f8aa-4407-9ad9</inAuthority> <refName>urn:cspace:museumofman.org:placeauthorities:name(place):item:name(Placedisplayname1354214392756)'Place display name'</refName> <shortIdentifier>Placedisplayname1354214392756</shortIdentifier> <placeTermGroupList> <placeTermGroup> <termSource>Museum of Man</termSource> <historicalStatus>current</historicalStatus> <termDisplayName>Place display name</termDisplayName> <termType>descriptive</termType> <termStatus>accepted</termStatus> </placeTermGroup> </placeTermGroupList> </schema> </import> </imports> -- > > > > /Chris > > ________________________________ > > Fra: Chris Hoffman [mailto:chris_h@berkeley.edu] > Sendt: 24. januar 2013 17:17 > Til: Christopher Pott > Cc: talk@lists.collectionspace.org > Emne: Re: [Talk] importing Place authorities to 3.2 > > > > Hi Chris, > > I did load some Place records for the SaaS demo trial. There is a refname > field now in collectionspace_core that is required. It has to be in the > main place authority schema too, and they must be identical. Here's an > import template I used. > > Hope this helps, > > Chris > > > > > > On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: > > > > Has anyone attempted import on 3.2? I’ve been running some old (2.6) import > jobs against the latest release (plus local config) and have been having > some trouble. I’m attempting to import Place Authorities, and the import > itself claims to have succeeded. The records do appear in the Nuxeo database > as expected. > > > > However, records created in this way are not visible via the Collectionspace > UI (using csid) and cannot be found via search. They can be found via the > Services API, both listed under the authority and as individual items via > the csid. In the results from the Services API, the only difference between > these records and those created in the CSpace UI are that these records are > missing the refName field (even though the refNames exist in the Nuxeo > database table just as expected, in exactly the same format as the Cspace UI > created records). > > > > Anyone any ideas what could be going wrong here? > > > > /Chris > > _______________________________________________ > > > 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 so much Aron. Can you clarify whether/when the refnames must be of the "name" variety or if the id variety is OK as for collection objects? Susan > Hi Chris P., Susan, and all, > > Thanks much for these questions and this discussion! > > The only documentation of this change to date, AFAIK, is in the > release notes for version 3.0, and that's just in the form of a note > suggesting future documentation: > > http://wiki.collectionspace.org/display/collectionspace/Release+3.0 > > We'll definitely will document this further, in those Release Notes > and on the Import Service Home page, where Chris Hoffman's excellent > example (with Chris Pott's correction) will be included. > > In brief, our collective understanding (with > corrections/clarification welcome) is: > > - refName values have been effectively moved into the > collectionspace_core schema, the schema which holds metadata > (including creation/update times and authors) for most CollectionSpace > records. > > - When Relation records are created, their refName values are pulled > out of the collectionspace_core:refName fields for the subject and > object records in that relation. > > - This effectively means that, at a minimum, when importing records > via the Imports service in CollectionSpace 3.0 or later, you'll need > to include the collectionspace_core schema on import, along with your > other schemas, for any record that's likely to be involved in a > relation. This includes: > > * Cataloging / CollectionObject records > * Procedural records (with the possible exception of outliers like > reports, id_generators, etc.) > * Authority and authority item records > > Also, there will be a new JIRA issue for inserting these refName > values automatically in collectionspace_core during import, rather > than requiring that you include those values in your import file. > (These values are already added automatically when creating new > records via other Services REST API calls ...) > > Aron > > On Mon, Jan 28, 2013 at 1:46 AM, Christopher Pott > <Christopher.Pott@smk.dk> wrote: >> Thanks Chris! This is just what I was missing. (note: for anyone else >> attempting this, the tag “schema2” in the template from Chris should be >> replaced with “schema”). How did you know to add this? Like Susan, I’d >> like >> to know the scope of this change (is it for all records?) and if there’s >> any >> documentation. > > On Thu, Jan 24, 2013 at 10:07 AM, Susan Stone > <sstone@socrates.berkeley.edu> wrote: >> Can someone who understands this well update the imports wiki page to >> show >> what needs to go into collectionspace_core and when (3.2+, authorities >> or >> everything? what the refname should look like if it is needed for other >> than >> authorities)? I don't understand this and I see there are others. > > -- > > Chris Hoffman's example (with Chris Pott's sharp-eyed correction): > > <?xml version="1.0" encoding="UTF-8"?> > <imports> > <import service="Places" type="Placeitem" CSID=""> > <schema > xmlns:collectionspace_core="http://collectionspace.org/collectionspace_core/" > name="collectionspace_core"> > <refName>urn:cspace:museumofman.org:placeauthorities:name(place):item:name(Placedisplayname1354214392756)'Place > display name'</refName> > </schema> > <schema > xmlns:places_common="http://collectionspace.org/services/place" > name="places_common"> > <inAuthority>b9ed4754-f8aa-4407-9ad9</inAuthority> > <refName>urn:cspace:museumofman.org:placeauthorities:name(place):item:name(Placedisplayname1354214392756)'Place > display name'</refName> > <shortIdentifier>Placedisplayname1354214392756</shortIdentifier> > <placeTermGroupList> > <placeTermGroup> > <termSource>Museum of Man</termSource> > <historicalStatus>current</historicalStatus> > <termDisplayName>Place display name</termDisplayName> > <termType>descriptive</termType> > <termStatus>accepted</termStatus> > </placeTermGroup> > </placeTermGroupList> > </schema> > </import> > </imports> > > -- >> >> >> >> /Chris >> >> ________________________________ >> >> Fra: Chris Hoffman [mailto:chris_h@berkeley.edu] >> Sendt: 24. januar 2013 17:17 >> Til: Christopher Pott >> Cc: talk@lists.collectionspace.org >> Emne: Re: [Talk] importing Place authorities to 3.2 >> >> >> >> Hi Chris, >> >> I did load some Place records for the SaaS demo trial. There is a >> refname >> field now in collectionspace_core that is required. It has to be in the >> main place authority schema too, and they must be identical. Here's an >> import template I used. >> >> Hope this helps, >> >> Chris >> >> >> >> >> >> On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: >> >> >> >> Has anyone attempted import on 3.2? I’ve been running some old (2.6) >> import >> jobs against the latest release (plus local config) and have been having >> some trouble. I’m attempting to import Place Authorities, and the import >> itself claims to have succeeded. The records do appear in the Nuxeo >> database >> as expected. >> >> >> >> However, records created in this way are not visible via the >> Collectionspace >> UI (using csid) and cannot be found via search. They can be found via >> the >> Services API, both listed under the authority and as individual items >> via >> the csid. In the results from the Services API, the only difference >> between >> these records and those created in the CSpace UI are that these records >> are >> missing the refName field (even though the refNames exist in the Nuxeo >> database table just as expected, in exactly the same format as the >> Cspace UI >> created records). >> >> >> >> Anyone any ideas what could be going wrong here? >> >> >> >> /Chris >> >> _______________________________________________ >> >> >> 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 >> >

On Mon, Jan 28, 2013 at 5:05 PM, <sstone@socrates.berkeley.edu> wrote: > Thanks so much Aron. Can you clarify whether/when the refnames must be of > the "name" variety or if the id variety is OK as for collection objects? AFAIK, the refNames for CollectionObjects are of the ID variety. > > Susan > >> Hi Chris P., Susan, and all, >> >> Thanks much for these questions and this discussion! >> >> The only documentation of this change to date, AFAIK, is in the >> release notes for version 3.0, and that's just in the form of a note >> suggesting future documentation: >> >> http://wiki.collectionspace.org/display/collectionspace/Release+3.0 >> >> We'll definitely will document this further, in those Release Notes >> and on the Import Service Home page, where Chris Hoffman's excellent >> example (with Chris Pott's correction) will be included. >> >> In brief, our collective understanding (with >> corrections/clarification welcome) is: >> >> - refName values have been effectively moved into the >> collectionspace_core schema, the schema which holds metadata >> (including creation/update times and authors) for most CollectionSpace >> records. >> >> - When Relation records are created, their refName values are pulled >> out of the collectionspace_core:refName fields for the subject and >> object records in that relation. >> >> - This effectively means that, at a minimum, when importing records >> via the Imports service in CollectionSpace 3.0 or later, you'll need >> to include the collectionspace_core schema on import, along with your >> other schemas, for any record that's likely to be involved in a >> relation. This includes: >> >> * Cataloging / CollectionObject records >> * Procedural records (with the possible exception of outliers like >> reports, id_generators, etc.) >> * Authority and authority item records >> >> Also, there will be a new JIRA issue for inserting these refName >> values automatically in collectionspace_core during import, rather >> than requiring that you include those values in your import file. >> (These values are already added automatically when creating new >> records via other Services REST API calls ...) >> >> Aron >> >> On Mon, Jan 28, 2013 at 1:46 AM, Christopher Pott >> <Christopher.Pott@smk.dk> wrote: >>> Thanks Chris! This is just what I was missing. (note: for anyone else >>> attempting this, the tag “schema2” in the template from Chris should be >>> replaced with “schema”). How did you know to add this? Like Susan, I’d >>> like >>> to know the scope of this change (is it for all records?) and if there’s >>> any >>> documentation. >> >> On Thu, Jan 24, 2013 at 10:07 AM, Susan Stone >> <sstone@socrates.berkeley.edu> wrote: >>> Can someone who understands this well update the imports wiki page to >>> show >>> what needs to go into collectionspace_core and when (3.2+, authorities >>> or >>> everything? what the refname should look like if it is needed for other >>> than >>> authorities)? I don't understand this and I see there are others. >> >> -- >> >> Chris Hoffman's example (with Chris Pott's sharp-eyed correction): >> >> <?xml version="1.0" encoding="UTF-8"?> >> <imports> >> <import service="Places" type="Placeitem" CSID=""> >> <schema >> xmlns:collectionspace_core="http://collectionspace.org/collectionspace_core/" >> name="collectionspace_core"> >> <refName>urn:cspace:museumofman.org:placeauthorities:name(place):item:name(Placedisplayname1354214392756)'Place >> display name'</refName> >> </schema> >> <schema >> xmlns:places_common="http://collectionspace.org/services/place" >> name="places_common"> >> <inAuthority>b9ed4754-f8aa-4407-9ad9</inAuthority> >> <refName>urn:cspace:museumofman.org:placeauthorities:name(place):item:name(Placedisplayname1354214392756)'Place >> display name'</refName> >> <shortIdentifier>Placedisplayname1354214392756</shortIdentifier> >> <placeTermGroupList> >> <placeTermGroup> >> <termSource>Museum of Man</termSource> >> <historicalStatus>current</historicalStatus> >> <termDisplayName>Place display name</termDisplayName> >> <termType>descriptive</termType> >> <termStatus>accepted</termStatus> >> </placeTermGroup> >> </placeTermGroupList> >> </schema> >> </import> >> </imports> >> >> -- >>> >>> >>> >>> /Chris >>> >>> ________________________________ >>> >>> Fra: Chris Hoffman [mailto:chris_h@berkeley.edu] >>> Sendt: 24. januar 2013 17:17 >>> Til: Christopher Pott >>> Cc: talk@lists.collectionspace.org >>> Emne: Re: [Talk] importing Place authorities to 3.2 >>> >>> >>> >>> Hi Chris, >>> >>> I did load some Place records for the SaaS demo trial. There is a >>> refname >>> field now in collectionspace_core that is required. It has to be in the >>> main place authority schema too, and they must be identical. Here's an >>> import template I used. >>> >>> Hope this helps, >>> >>> Chris >>> >>> >>> >>> >>> >>> On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: >>> >>> >>> >>> Has anyone attempted import on 3.2? I’ve been running some old (2.6) >>> import >>> jobs against the latest release (plus local config) and have been having >>> some trouble. I’m attempting to import Place Authorities, and the import >>> itself claims to have succeeded. The records do appear in the Nuxeo >>> database >>> as expected. >>> >>> >>> >>> However, records created in this way are not visible via the >>> Collectionspace >>> UI (using csid) and cannot be found via search. They can be found via >>> the >>> Services API, both listed under the authority and as individual items >>> via >>> the csid. In the results from the Services API, the only difference >>> between >>> these records and those created in the CSpace UI are that these records >>> are >>> missing the refName field (even though the refNames exist in the Nuxeo >>> database table just as expected, in exactly the same format as the >>> Cspace UI >>> created records). >>> >>> >>> >>> Anyone any ideas what could be going wrong here? >>> >>> >>> >>> /Chris >>> >>> _______________________________________________ >>> >>> >>> 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 >>> >> > >

 <import service="Places" type="Placeitem" CSID="">
     <schema

         <placeTermGroupList>
             <placeTermGroup>
                 <termSource>Museum of Man</termSource>
                 <historicalStatus>current</historicalStatus>
                 <termDisplayName>Place display

                 <termType>descriptive</termType>
                 <termStatus>accepted</termStatus>
             </placeTermGroup>
         </placeTermGroupList>
     </schema>
 </import>

All refNames for objects other than authorities and authoryItems, only support the id form, as they have no defined shortIdentifier that would be the basis of a name form. The refname forms are very simple, and can easily be seen by creating objects through the web app, and then see the values in the services or the UI console. Patrick > -----Original Message----- > From: Talk [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of > Aron Roberts > Sent: Monday, January 28, 2013 8:41 PM > To: sstone@socrates.berkeley.edu > Cc: talk@lists.collectionspace.org > Subject: Re: [Talk] importing Place authorities to 3.2 > > On Mon, Jan 28, 2013 at 5:05 PM, <sstone@socrates.berkeley.edu> wrote: > > Thanks so much Aron. Can you clarify whether/when the refnames must > be > > of the "name" variety or if the id variety is OK as for collection objects? > > AFAIK, the refNames for CollectionObjects are of the ID variety. > > > > > Susan > > > >> Hi Chris P., Susan, and all, > >> > >> Thanks much for these questions and this discussion! > >> > >> The only documentation of this change to date, AFAIK, is in the > >> release notes for version 3.0, and that's just in the form of a note > >> suggesting future documentation: > >> > >> http://wiki.collectionspace.org/display/collectionspace/Release+3.0 > >> > >> We'll definitely will document this further, in those Release Notes > >> and on the Import Service Home page, where Chris Hoffman's excellent > >> example (with Chris Pott's correction) will be included. > >> > >> In brief, our collective understanding (with > >> corrections/clarification welcome) is: > >> > >> - refName values have been effectively moved into the > >> collectionspace_core schema, the schema which holds metadata > >> (including creation/update times and authors) for most > >> CollectionSpace records. > >> > >> - When Relation records are created, their refName values are > >> pulled out of the collectionspace_core:refName fields for the subject > >> and object records in that relation. > >> > >> - This effectively means that, at a minimum, when importing records > >> via the Imports service in CollectionSpace 3.0 or later, you'll need > >> to include the collectionspace_core schema on import, along with your > >> other schemas, for any record that's likely to be involved in a > >> relation. This includes: > >> > >> * Cataloging / CollectionObject records > >> * Procedural records (with the possible exception of outliers like > >> reports, id_generators, etc.) > >> * Authority and authority item records > >> > >> Also, there will be a new JIRA issue for inserting these refName > >> values automatically in collectionspace_core during import, rather > >> than requiring that you include those values in your import file. > >> (These values are already added automatically when creating new > >> records via other Services REST API calls ...) > >> > >> Aron > >> > >> On Mon, Jan 28, 2013 at 1:46 AM, Christopher Pott > >> <Christopher.Pott@smk.dk> wrote: > >>> Thanks Chris! This is just what I was missing. (note: for anyone > >>> else attempting this, the tag "schema2" in the template from Chris > >>> should be replaced with "schema"). How did you know to add this? > >>> Like Susan, I'd like to know the scope of this change (is it for all > >>> records?) and if there's any documentation. > >> > >> On Thu, Jan 24, 2013 at 10:07 AM, Susan Stone > >> <sstone@socrates.berkeley.edu> wrote: > >>> Can someone who understands this well update the imports wiki page > >>> to show what needs to go into collectionspace_core and when (3.2+, > >>> authorities or everything? what the refname should look like if it > >>> is needed for other than authorities)? I don't understand this and I > >>> see there are others. > >> > >> -- > >> > >> Chris Hoffman's example (with Chris Pott's sharp-eyed correction): > >> > >> <?xml version="1.0" encoding="UTF-8"?> <imports> > >> <import service="Places" type="Placeitem" CSID=""> > >> <schema > >> > xmlns:collectionspace_core="http://collectionspace.org/collectionspace_co > re/" > >> name="collectionspace_core"> > >> > >> > <refName>urn:cspace:museumofman.org:placeauthorities:name(place):ite > m > >> :name(Placedisplayname1354214392756)'Place > >> display name'</refName> > >> </schema> > >> <schema > >> xmlns:places_common="http://collectionspace.org/services/place" > >> name="places_common"> > >> <inAuthority>b9ed4754-f8aa-4407-9ad9</inAuthority> > >> > >> > <refName>urn:cspace:museumofman.org:placeauthorities:name(place):ite > m > >> :name(Placedisplayname1354214392756)'Place > >> display name'</refName> > >> > <shortIdentifier>Placedisplayname1354214392756</shortIdentifier> > >> <placeTermGroupList> > >> <placeTermGroup> > >> <termSource>Museum of Man</termSource> > >> <historicalStatus>current</historicalStatus> > >> <termDisplayName>Place display name</termDisplayName> > >> <termType>descriptive</termType> > >> <termStatus>accepted</termStatus> > >> </placeTermGroup> > >> </placeTermGroupList> > >> </schema> > >> </import> > >> </imports> > >> > >> -- > >>> > >>> > >>> > >>> /Chris > >>> > >>> ________________________________ > >>> > >>> Fra: Chris Hoffman [mailto:chris_h@berkeley.edu] > >>> Sendt: 24. januar 2013 17:17 > >>> Til: Christopher Pott > >>> Cc: talk@lists.collectionspace.org > >>> Emne: Re: [Talk] importing Place authorities to 3.2 > >>> > >>> > >>> > >>> Hi Chris, > >>> > >>> I did load some Place records for the SaaS demo trial. There is a > >>> refname field now in collectionspace_core that is required. It has > >>> to be in the main place authority schema too, and they must be > >>> identical. Here's an import template I used. > >>> > >>> Hope this helps, > >>> > >>> Chris > >>> > >>> > >>> > >>> > >>> > >>> On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: > >>> > >>> > >>> > >>> Has anyone attempted import on 3.2? I've been running some old (2.6) > >>> import jobs against the latest release (plus local config) and have > >>> been having some trouble. I'm attempting to import Place > >>> Authorities, and the import itself claims to have succeeded. The > >>> records do appear in the Nuxeo database as expected. > >>> > >>> > >>> > >>> However, records created in this way are not visible via the > >>> Collectionspace > >>> UI (using csid) and cannot be found via search. They can be found via > >>> the > >>> Services API, both listed under the authority and as individual items > >>> via > >>> the csid. In the results from the Services API, the only difference > >>> between > >>> these records and those created in the CSpace UI are that these records > >>> are > >>> missing the refName field (even though the refNames exist in the > Nuxeo > >>> database table just as expected, in exactly the same format as the > >>> Cspace UI > >>> created records). > >>> > >>> > >>> > >>> Anyone any ideas what could be going wrong here? > >>> > >>> > >>> > >>> /Chris > >>> > >>> _______________________________________________ > >>> > >>> > >>> Talk mailing list > >>> Talk@lists.collectionspace.org > >>> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa ce. > org > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Talk mailing list > >>> Talk@lists.collectionspace.org > >>> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa ce. > org > >>> > >> > > > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa ce. > org

 <import service="Places" type="Placeitem" CSID="">
     <schema

         <placeTermGroupList>
             <placeTermGroup>
                 <termSource>Museum of Man</termSource>
                 <historicalStatus>current</historicalStatus>
                 <termDisplayName>Place display

                 <termType>descriptive</termType>
                 <termStatus>accepted</termStatus>
             </placeTermGroup>
         </placeTermGroupList>
     </schema>
 </import>

On Tue, Jan 29, 2013 at 8:52 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: > All refNames for objects other than authorities and authoryItems, only > support the id form, as they have no defined shortIdentifier that would be > the basis of a name form. > > The refname forms are very simple, and can easily be seen by creating > objects through the web app, and then see the values in the services or > the UI console. Some samples from records created on the QA server, in the demo 'core' tenant during version 3.2 QA testing: Refnames for object and procedural records: urn:cspace:core.collectionspace.org:relations:id(e02fa710-d5f4-45cf-9258) urn:cspace:core.collectionspace.org:relations:id(14ca035a-ff1b-405a-9b2f) urn:cspace:core.collectionspace.org:collectionobjects:id(9a4c3199-9d90-4832-9a3 9)'2012.1.5' urn:cspace:core.collectionspace.org:collectionobjects:id(01c335bc-64ba-4a4f-a19 3)'IN2012.2' urn:cspace:core.collectionspace.org:movements:id(f7d30fec-f14f-473a-9d29) urn:cspace:core.collectionspace.org:loansout:id(cd646dd9-2bb4-4e84-9e55) urn:cspace:core.collectionspace.org:objectexit:id(a1ad20a9-e5a6-4dc2-ac4b) urn:cspace:core.collectionspace.org:intakes:id(ec751724-4990-4bd0-80de) urn:cspace:core.collectionspace.org:groups:id(732e6dac-ad1d-4294-9011) urn:cspace:core.collectionspace.org:media:id(59521dfa-ec3b-4378-8ae9) Refnames for authority records: urn:cspace:core.collectionspace.org:conceptauthorities:name(material_ca)'Material Concepts' urn:cspace:core.collectionspace.org:conceptauthorities:name(concept)'Associated Concepts' urn:cspace:core.collectionspace.org:conceptauthorities:name(activity)'Activity Concepts' urn:cspace:core.collectionspace.org:personauthorities:name(person)'Local Persons' urn:cspace:core.collectionspace.org:personauthorities:name(ulan_pa)'ULAN Persons' urn:cspace:core.collectionspace.org:locationauthorities:name(offsite_sla)'Offsite Storage Locations' urn:cspace:core.collectionspace.org:locationauthorities:name(location)'Local Storage Locations' urn:cspace:core.collectionspace.org:orgauthorities:name(organization)'Local Organizations' urn:cspace:core.collectionspace.org:orgauthorities:name(ulan_oa)'ULAN Organizations' urn:cspace:core.collectionspace.org:placeauthorities:name(tgn_place)'Thesaurus of Geographic Names' Refnames for authority term (aka authority item) records: urn:cspace:core.collectionspace.org:personauthorities:name(person):item:name(Ja mesAdams1355724895312)'James Adams' urn:cspace:core.collectionspace.org:personauthorities:name(person):item:name(Fr ankAdams1355724895426)'Frank Adams' urn:cspace:core.collectionspace.org:personauthorities:name(person):item:name(Jo eAdamson1355724895541)'Joe Adamson' urn:cspace:core.collectionspace.org:orgauthorities:name(organization):item:name (StratemeyerLiterarySyndicate1355725199844)'Stratemeyer Literary Syndicate' urn:cspace:core.collectionspace.org:orgauthorities:name(organization):item:name (EmersonRadioPhonographCorporation1355725200069)'Emerson Radio Phonograph Corpor ation' urn:cspace:core.collectionspace.org:orgauthorities:name(organization):item:name (KennerProducts1355725200235)'Kenner Products' urn:cspace:core.collectionspace.org:orgauthorities:name(organization):item:name (RialtoTheatre1355725200397)'Rialto Theatre' urn:cspace:core.collectionspace.org:placeauthorities:name(tgn_place):item:name( Manhattan1355996660509)'Manhattan' urn:cspace:core.collectionspace.org:placeauthorities:name(tgn_place):item:name( NoeValley1356047970654)'Noe Valley' > > Patrick > >> -----Original Message----- >> From: Talk [mailto:talk-bounces@lists.collectionspace.org] On Behalf Of >> Aron Roberts >> Sent: Monday, January 28, 2013 8:41 PM >> To: sstone@socrates.berkeley.edu >> Cc: talk@lists.collectionspace.org >> Subject: Re: [Talk] importing Place authorities to 3.2 >> >> On Mon, Jan 28, 2013 at 5:05 PM, <sstone@socrates.berkeley.edu> wrote: >> > Thanks so much Aron. Can you clarify whether/when the refnames must >> be >> > of the "name" variety or if the id variety is OK as for collection > objects? >> >> AFAIK, the refNames for CollectionObjects are of the ID variety. >> >> > >> > Susan >> > >> >> Hi Chris P., Susan, and all, >> >> >> >> Thanks much for these questions and this discussion! >> >> >> >> The only documentation of this change to date, AFAIK, is in the >> >> release notes for version 3.0, and that's just in the form of a note >> >> suggesting future documentation: >> >> >> >> http://wiki.collectionspace.org/display/collectionspace/Release+3.0 >> >> >> >> We'll definitely will document this further, in those Release Notes >> >> and on the Import Service Home page, where Chris Hoffman's excellent >> >> example (with Chris Pott's correction) will be included. >> >> >> >> In brief, our collective understanding (with >> >> corrections/clarification welcome) is: >> >> >> >> - refName values have been effectively moved into the >> >> collectionspace_core schema, the schema which holds metadata >> >> (including creation/update times and authors) for most >> >> CollectionSpace records. >> >> >> >> - When Relation records are created, their refName values are >> >> pulled out of the collectionspace_core:refName fields for the subject >> >> and object records in that relation. >> >> >> >> - This effectively means that, at a minimum, when importing records >> >> via the Imports service in CollectionSpace 3.0 or later, you'll need >> >> to include the collectionspace_core schema on import, along with your >> >> other schemas, for any record that's likely to be involved in a >> >> relation. This includes: >> >> >> >> * Cataloging / CollectionObject records >> >> * Procedural records (with the possible exception of outliers like >> >> reports, id_generators, etc.) >> >> * Authority and authority item records >> >> >> >> Also, there will be a new JIRA issue for inserting these refName >> >> values automatically in collectionspace_core during import, rather >> >> than requiring that you include those values in your import file. >> >> (These values are already added automatically when creating new >> >> records via other Services REST API calls ...) >> >> >> >> Aron >> >> >> >> On Mon, Jan 28, 2013 at 1:46 AM, Christopher Pott >> >> <Christopher.Pott@smk.dk> wrote: >> >>> Thanks Chris! This is just what I was missing. (note: for anyone >> >>> else attempting this, the tag "schema2" in the template from Chris >> >>> should be replaced with "schema"). How did you know to add this? >> >>> Like Susan, I'd like to know the scope of this change (is it for all >> >>> records?) and if there's any documentation. >> >> >> >> On Thu, Jan 24, 2013 at 10:07 AM, Susan Stone >> >> <sstone@socrates.berkeley.edu> wrote: >> >>> Can someone who understands this well update the imports wiki page >> >>> to show what needs to go into collectionspace_core and when (3.2+, >> >>> authorities or everything? what the refname should look like if it >> >>> is needed for other than authorities)? I don't understand this and I >> >>> see there are others. >> >> >> >> -- >> >> >> >> Chris Hoffman's example (with Chris Pott's sharp-eyed correction): >> >> >> >> <?xml version="1.0" encoding="UTF-8"?> <imports> >> >> <import service="Places" type="Placeitem" CSID=""> >> >> <schema >> >> >> > xmlns:collectionspace_core="http://collectionspace.org/collectionspace_co >> re/" >> >> name="collectionspace_core"> >> >> >> >> >> <refName>urn:cspace:museumofman.org:placeauthorities:name(place):ite >> m >> >> :name(Placedisplayname1354214392756)'Place >> >> display name'</refName> >> >> </schema> >> >> <schema >> >> xmlns:places_common="http://collectionspace.org/services/place" >> >> name="places_common"> >> >> <inAuthority>b9ed4754-f8aa-4407-9ad9</inAuthority> >> >> >> >> >> <refName>urn:cspace:museumofman.org:placeauthorities:name(place):ite >> m >> >> :name(Placedisplayname1354214392756)'Place >> >> display name'</refName> >> >> >> <shortIdentifier>Placedisplayname1354214392756</shortIdentifier> >> >> <placeTermGroupList> >> >> <placeTermGroup> >> >> <termSource>Museum of Man</termSource> >> >> <historicalStatus>current</historicalStatus> >> >> <termDisplayName>Place display > name</termDisplayName> >> >> <termType>descriptive</termType> >> >> <termStatus>accepted</termStatus> >> >> </placeTermGroup> >> >> </placeTermGroupList> >> >> </schema> >> >> </import> >> >> </imports> >> >> >> >> -- >> >>> >> >>> >> >>> >> >>> /Chris >> >>> >> >>> ________________________________ >> >>> >> >>> Fra: Chris Hoffman [mailto:chris_h@berkeley.edu] >> >>> Sendt: 24. januar 2013 17:17 >> >>> Til: Christopher Pott >> >>> Cc: talk@lists.collectionspace.org >> >>> Emne: Re: [Talk] importing Place authorities to 3.2 >> >>> >> >>> >> >>> >> >>> Hi Chris, >> >>> >> >>> I did load some Place records for the SaaS demo trial. There is a >> >>> refname field now in collectionspace_core that is required. It has >> >>> to be in the main place authority schema too, and they must be >> >>> identical. Here's an import template I used. >> >>> >> >>> Hope this helps, >> >>> >> >>> Chris >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: >> >>> >> >>> >> >>> >> >>> Has anyone attempted import on 3.2? I've been running some old (2.6) >> >>> import jobs against the latest release (plus local config) and have >> >>> been having some trouble. I'm attempting to import Place >> >>> Authorities, and the import itself claims to have succeeded. The >> >>> records do appear in the Nuxeo database as expected. >> >>> >> >>> >> >>> >> >>> However, records created in this way are not visible via the >> >>> Collectionspace >> >>> UI (using csid) and cannot be found via search. They can be found > via >> >>> the >> >>> Services API, both listed under the authority and as individual > items >> >>> via >> >>> the csid. In the results from the Services API, the only difference >> >>> between >> >>> these records and those created in the CSpace UI are that these > records >> >>> are >> >>> missing the refName field (even though the refNames exist in the >> Nuxeo >> >>> database table just as expected, in exactly the same format as the >> >>> Cspace UI >> >>> created records). >> >>> >> >>> >> >>> >> >>> Anyone any ideas what could be going wrong here? >> >>> >> >>> >> >>> >> >>> /Chris >> >>> >> >>> _______________________________________________ >> >>> >> >>> >> >>> Talk mailing list >> >>> Talk@lists.collectionspace.org >> >>> >> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa > ce. >> org >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Talk mailing list >> >>> Talk@lists.collectionspace.org >> >>> >> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa > ce. >> org >> >>> >> >> >> > >> > >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspa > ce. >> org

 <import service="Places" type="Placeitem" CSID="">
     <schema

         <placeTermGroupList>
             <placeTermGroup>
                 <termSource>Museum of Man</termSource>
                 <historicalStatus>current</historicalStatus>
                 <termDisplayName>Place display

                 <termType>descriptive</termType>
                 <termStatus>accepted</termStatus>
             </placeTermGroup>
         </placeTermGroupList>
     </schema>
 </import>

The CollectionObject one is interesting - I did not know that it supported a displayName that way. Aron/Richard - is that configurable? I.e., can any service configure a field to use as the displayName and the infrastructure will append that? Patrick > -----Original Message----- > From: aronroberts@gmail.com [mailto:aronroberts@gmail.com] On Behalf > Of Aron Roberts > Sent: Tuesday, January 29, 2013 9:36 AM > To: Patrick Schmitz > Cc: sstone@socrates.berkeley.edu; talk@lists.collectionspace.org > Subject: Re: [Talk] importing Place authorities to 3.2 > > On Tue, Jan 29, 2013 at 8:52 AM, Patrick Schmitz <pschmitz@berkeley.edu> > wrote: > > All refNames for objects other than authorities and authoryItems, only > > support the id form, as they have no defined shortIdentifier that > > would be the basis of a name form. > > > > The refname forms are very simple, and can easily be seen by creating > > objects through the web app, and then see the values in the services > > or the UI console. > > Some samples from records created on the QA server, in the demo 'core' > tenant during version 3.2 QA testing: > > Refnames for object and procedural records: > > urn:cspace:core.collectionspace.org:relations:id(e02fa710-d5f4-45cf-9258) > urn:cspace:core.collectionspace.org:relations:id(14ca035a-ff1b-405a-9b2f) > urn:cspace:core.collectionspace.org:collectionobjects:id(9a4c3199-9d90- > 4832-9a3 > 9)'2012.1.5' > urn:cspace:core.collectionspace.org:collectionobjects:id(01c335bc-64ba- > 4a4f-a19 > 3)'IN2012.2' > urn:cspace:core.collectionspace.org:movements:id(f7d30fec-f14f-473a- > 9d29) > urn:cspace:core.collectionspace.org:loansout:id(cd646dd9-2bb4-4e84-9e55) > urn:cspace:core.collectionspace.org:objectexit:id(a1ad20a9-e5a6-4dc2- > ac4b) > urn:cspace:core.collectionspace.org:intakes:id(ec751724-4990-4bd0-80de) > urn:cspace:core.collectionspace.org:groups:id(732e6dac-ad1d-4294-9011) > urn:cspace:core.collectionspace.org:media:id(59521dfa-ec3b-4378-8ae9) > > Refnames for authority records: > > > urn:cspace:core.collectionspace.org:conceptauthorities:name(material_ca)' > Material > Concepts' > > urn:cspace:core.collectionspace.org:conceptauthorities:name(concept)'Ass > ociated > Concepts' > > urn:cspace:core.collectionspace.org:conceptauthorities:name(activity)'Acti v > ity > Concepts' > urn:cspace:core.collectionspace.org:personauthorities:name(person)'Local > Persons' > > urn:cspace:core.collectionspace.org:personauthorities:name(ulan_pa)'ULA > N > Persons' > > urn:cspace:core.collectionspace.org:locationauthorities:name(offsite_sla)' O > ffsite > Storage Locations' > > urn:cspace:core.collectionspace.org:locationauthorities:name(location)'Loc > al > Storage Locations' > > urn:cspace:core.collectionspace.org:orgauthorities:name(organization)'Loca > l > Organizations' > urn:cspace:core.collectionspace.org:orgauthorities:name(ulan_oa)'ULAN > Organizations' > > urn:cspace:core.collectionspace.org:placeauthorities:name(tgn_place)'Thes > aurus > of Geographic Names' > > Refnames for authority term (aka authority item) records: > > > urn:cspace:core.collectionspace.org:personauthorities:name(person):item: > name(Ja > mesAdams1355724895312)'James Adams' > > urn:cspace:core.collectionspace.org:personauthorities:name(person):item: > name(Fr > ankAdams1355724895426)'Frank Adams' > > urn:cspace:core.collectionspace.org:personauthorities:name(person):item: > name(Jo > eAdamson1355724895541)'Joe Adamson' > > urn:cspace:core.collectionspace.org:orgauthorities:name(organization):ite > m:name > (StratemeyerLiterarySyndicate1355725199844)'Stratemeyer Literary > Syndicate' > > urn:cspace:core.collectionspace.org:orgauthorities:name(organization):ite > m:name > (EmersonRadioPhonographCorporation1355725200069)'Emerson Radio > Phonograph Corpor ation' > > urn:cspace:core.collectionspace.org:orgauthorities:name(organization):ite > m:name > (KennerProducts1355725200235)'Kenner Products' > > urn:cspace:core.collectionspace.org:orgauthorities:name(organization):ite > m:name > (RialtoTheatre1355725200397)'Rialto Theatre' > > urn:cspace:core.collectionspace.org:placeauthorities:name(tgn_place):item > :name( > Manhattan1355996660509)'Manhattan' > > urn:cspace:core.collectionspace.org:placeauthorities:name(tgn_place):item > :name( > NoeValley1356047970654)'Noe Valley' > > > > > Patrick > > > >> -----Original Message----- > >> From: Talk [mailto:talk-bounces@lists.collectionspace.org] On Behalf > >> Of Aron Roberts > >> Sent: Monday, January 28, 2013 8:41 PM > >> To: sstone@socrates.berkeley.edu > >> Cc: talk@lists.collectionspace.org > >> Subject: Re: [Talk] importing Place authorities to 3.2 > >> > >> On Mon, Jan 28, 2013 at 5:05 PM, <sstone@socrates.berkeley.edu> > wrote: > >> > Thanks so much Aron. Can you clarify whether/when the refnames > must > >> be > >> > of the "name" variety or if the id variety is OK as for collection > > objects? > >> > >> AFAIK, the refNames for CollectionObjects are of the ID variety. > >> > >> > > >> > Susan > >> > > >> >> Hi Chris P., Susan, and all, > >> >> > >> >> Thanks much for these questions and this discussion! > >> >> > >> >> The only documentation of this change to date, AFAIK, is in the > >> >> release notes for version 3.0, and that's just in the form of a > >> >> note suggesting future documentation: > >> >> > >> >> > >> >> http://wiki.collectionspace.org/display/collectionspace/Release+3. > >> >> 0 > >> >> > >> >> We'll definitely will document this further, in those Release > >> >> Notes and on the Import Service Home page, where Chris Hoffman's > >> >> excellent example (with Chris Pott's correction) will be included. > >> >> > >> >> In brief, our collective understanding (with > >> >> corrections/clarification welcome) is: > >> >> > >> >> - refName values have been effectively moved into the > >> >> collectionspace_core schema, the schema which holds metadata > >> >> (including creation/update times and authors) for most > >> >> CollectionSpace records. > >> >> > >> >> - When Relation records are created, their refName values are > >> >> pulled out of the collectionspace_core:refName fields for the > >> >> subject and object records in that relation. > >> >> > >> >> - This effectively means that, at a minimum, when importing > >> >> records via the Imports service in CollectionSpace 3.0 or later, > >> >> you'll need to include the collectionspace_core schema on import, > >> >> along with your other schemas, for any record that's likely to be > >> >> involved in a relation. This includes: > >> >> > >> >> * Cataloging / CollectionObject records > >> >> * Procedural records (with the possible exception of outliers > >> >> like reports, id_generators, etc.) > >> >> * Authority and authority item records > >> >> > >> >> Also, there will be a new JIRA issue for inserting these refName > >> >> values automatically in collectionspace_core during import, rather > >> >> than requiring that you include those values in your import file. > >> >> (These values are already added automatically when creating new > >> >> records via other Services REST API calls ...) > >> >> > >> >> Aron > >> >> > >> >> On Mon, Jan 28, 2013 at 1:46 AM, Christopher Pott > >> >> <Christopher.Pott@smk.dk> wrote: > >> >>> Thanks Chris! This is just what I was missing. (note: for anyone > >> >>> else attempting this, the tag "schema2" in the template from > >> >>> Chris should be replaced with "schema"). How did you know to add > this? > >> >>> Like Susan, I'd like to know the scope of this change (is it for > >> >>> all > >> >>> records?) and if there's any documentation. > >> >> > >> >> On Thu, Jan 24, 2013 at 10:07 AM, Susan Stone > >> >> <sstone@socrates.berkeley.edu> wrote: > >> >>> Can someone who understands this well update the imports wiki > >> >>> page to show what needs to go into collectionspace_core and when > >> >>> (3.2+, authorities or everything? what the refname should look > >> >>> like if it is needed for other than authorities)? I don't > >> >>> understand this and I see there are others. > >> >> > >> >> -- > >> >> > >> >> Chris Hoffman's example (with Chris Pott's sharp-eyed correction): > >> >> > >> >> <?xml version="1.0" encoding="UTF-8"?> <imports> > >> >> <import service="Places" type="Placeitem" CSID=""> > >> >> <schema > >> >> > >> > > xmlns:collectionspace_core="http://collectionspace.org/collectionspace > > _co > >> re/" > >> >> name="collectionspace_core"> > >> >> > >> >> > >> > <refName>urn:cspace:museumofman.org:placeauthorities:name(place):ite > >> m > >> >> :name(Placedisplayname1354214392756)'Place > >> >> display name'</refName> > >> >> </schema> > >> >> <schema > >> >> xmlns:places_common="http://collectionspace.org/services/place" > >> >> name="places_common"> > >> >> <inAuthority>b9ed4754-f8aa-4407-9ad9</inAuthority> > >> >> > >> >> > >> > <refName>urn:cspace:museumofman.org:placeauthorities:name(place):ite > >> m > >> >> :name(Placedisplayname1354214392756)'Place > >> >> display name'</refName> > >> >> > >> <shortIdentifier>Placedisplayname1354214392756</shortIdentifier> > >> >> <placeTermGroupList> > >> >> <placeTermGroup> > >> >> <termSource>Museum of Man</termSource> > >> >> <historicalStatus>current</historicalStatus> > >> >> <termDisplayName>Place display > > name</termDisplayName> > >> >> <termType>descriptive</termType> > >> >> <termStatus>accepted</termStatus> > >> >> </placeTermGroup> > >> >> </placeTermGroupList> > >> >> </schema> > >> >> </import> > >> >> </imports> > >> >> > >> >> -- > >> >>> > >> >>> > >> >>> > >> >>> /Chris > >> >>> > >> >>> ________________________________ > >> >>> > >> >>> Fra: Chris Hoffman [mailto:chris_h@berkeley.edu] > >> >>> Sendt: 24. januar 2013 17:17 > >> >>> Til: Christopher Pott > >> >>> Cc: talk@lists.collectionspace.org > >> >>> Emne: Re: [Talk] importing Place authorities to 3.2 > >> >>> > >> >>> > >> >>> > >> >>> Hi Chris, > >> >>> > >> >>> I did load some Place records for the SaaS demo trial. There is > >> >>> a refname field now in collectionspace_core that is required. It > >> >>> has to be in the main place authority schema too, and they must > >> >>> be identical. Here's an import template I used. > >> >>> > >> >>> Hope this helps, > >> >>> > >> >>> Chris > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> On Jan 24, 2013, at 5:53 AM, Christopher Pott wrote: > >> >>> > >> >>> > >> >>> > >> >>> Has anyone attempted import on 3.2? I've been running some old > >> >>> (2.6) import jobs against the latest release (plus local config) > >> >>> and have been having some trouble. I'm attempting to import Place > >> >>> Authorities, and the import itself claims to have succeeded. The > >> >>> records do appear in the Nuxeo database as expected. > >> >>> > >> >>> > >> >>> > >> >>> However, records created in this way are not visible via the > >> >>> Collectionspace UI (using csid) and cannot be found via search. > >> >>> They can be found > > via > >> >>> the > >> >>> Services API, both listed under the authority and as individual > > items > >> >>> via > >> >>> the csid. In the results from the Services API, the only > >> >>> difference between these records and those created in the CSpace > >> >>> UI are that these > > records > >> >>> are > >> >>> missing the refName field (even though the refNames exist in the > >> Nuxeo > >> >>> database table just as expected, in exactly the same format as > >> >>> the Cspace UI created records). > >> >>> > >> >>> > >> >>> > >> >>> Anyone any ideas what could be going wrong here? > >> >>> > >> >>> > >> >>> > >> >>> /Chris > >> >>> > >> >>> _______________________________________________ > >> >>> > >> >>> > >> >>> Talk mailing list > >> >>> Talk@lists.collectionspace.org > >> >>> > >> > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio > > nspa > > ce. > >> org > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Talk mailing list > >> >>> Talk@lists.collectionspace.org > >> >>> > >> > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio > > nspa > > ce. > >> org > >> >>> > >> >> > >> > > >> > > >> > >> _______________________________________________ > >> Talk mailing list > >> Talk@lists.collectionspace.org > >> > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectio > > nspa > > ce. > >> org