Hi colleagues, According to the documentation about the contact service at http://wiki.collectionspace.org/display/collectionspace/Service+Layer+-+Services+Currently+Available > The Contact service is currently exposed as a first-class service, but also has been refactored to operate as a sub-resource of Person and Organization. At a future time, its direct RESTful API will be removed. > Does this mean that when creating an XML payload for importing Organization records, I can append the Contact schema and data for each record, and it will automatically link up? That is, I could have something that looked like: <imports> <import service="Organizations" type="Organization" CSID="77109ac6-5935-4ddf-b942-70debdcd9481"> <schema xmlns:organizations_common="http://collectionspace.org/services/organization" name="organizations_common"> ... organizations_common fields ... </schema> <schema xmlns:organizations_naturalhistory="http://collectionspace.org/services/organization/domain/naturalhistory" name="organizations_naturalhistory"> … domain extension fields ... </schema> <schema xmlns:contacts_common="http://collectionspace.org/services/contacts" name="contacts_common"> … contacts_common fields … </schema> </import> </imports> If so, do I have to provide the inAuthority and inItem fields for contacts_common, or are those derived from the rest of the payload? Or do I have to do a separate load of the contacts information? Thanks, Chris

My off-the-cuff, untried response, with corrections welcomed: * You can always mix record types in a payload submitted to the Imports service. However, doing so doesn't in itself associate the records with one another. * There's an automated test in the services source code tree that submits a single payload to the Imports service, consisting of one ObjectExit record and one Media record, that helps verify this functionality is working as documented. In that example, each distinct record type, consisting of 0-n records to be imported, is enclosed within its own <import> tag: https://github.com/collectionspace/services/blob/master/services/IntegrationTests/src/test/resources/test-data/xmlreplay/imports/import-objectexit-media.xml (Even though in the services REST APIs, contacts are intended to be exposed only as a sub-resource of Organization and Person records, from the perspective of the Imports service, I believe Contact records are first class citizens.) * The values of the inAuthority and inItem records in your Contacts records, whether loaded in the same payload alongside Organization and/or Person records, or in an entirely separate payload, would tie them to their corresponding OrgAuthority and Organization records. Aron On Mon, May 14, 2012 at 6:28 PM, Chris Hoffman <chris.hoffman@berkeley.edu> wrote: > Hi colleagues, > According to the documentation about the contact service at >   http://wiki.collectionspace.org/display/collectionspace/Service+Layer+-+Services+Currently+Available > > The Contact service is currently exposed as a first-class service, but also > has been refactored to operate as a sub-resource of Person and Organization. > At a future time, its direct RESTful API will be removed. > > Does this mean that when creating an XML payload for importing Organization > records, I can append the Contact schema and data for each record, and it > will automatically link up? That is, I could have something that looked > like: > > <imports> >   <import service="Organizations" type="Organization" > CSID="77109ac6-5935-4ddf-b942-70debdcd9481"> >     <schema > xmlns:organizations_common="http://collectionspace.org/services/organization" > name="organizations_common"> >       ... organizations_common fields ... >     </schema> >     <schema > xmlns:organizations_naturalhistory="http://collectionspace.org/services/organization/domain/naturalhistory" > name="organizations_naturalhistory"> >       … domain extension fields ... >     </schema> > >   <schema xmlns:contacts_common="http://collectionspace.org/services/contacts" name="contacts_common"> >      … contacts_common fields … >     </schema> >   </import> > </imports> > > If so, do I have to provide the inAuthority and inItem fields for > contacts_common, or are those derived from the rest of the payload? > > Or do I have to do a separate load of the contacts information? > > Thanks, > Chris

Thanks, Aron. > (Even though in the services REST APIs, contacts are intended to be > exposed only as a sub-resource of Organization and Person records, > from the perspective of the Imports service, I believe Contact records > are first class citizens.) This is what I was looking for. Chris On May 14, 2012, at 6:45 PM, Aron Roberts wrote: > My off-the-cuff, untried response, with corrections welcomed: > > * You can always mix record types in a payload submitted to the > Imports service. However, doing so doesn't in itself associate the > records with one another. > * There's an automated test in the services source code tree that > submits a single payload to the Imports service, consisting of one > ObjectExit record and one Media record, that helps verify this > functionality is working as documented. In that example, each > distinct record type, consisting of 0-n records to be imported, is > enclosed within its own <import> tag: > https://github.com/collectionspace/services/blob/master/services/IntegrationTests/src/test/resources/test-data/xmlreplay/imports/import-objectexit-media.xml > (Even though in the services REST APIs, contacts are intended to be > exposed only as a sub-resource of Organization and Person records, > from the perspective of the Imports service, I believe Contact records > are first class citizens.) > * The values of the inAuthority and inItem records in your Contacts > records, whether loaded in the same payload alongside Organization > and/or Person records, or in an entirely separate payload, would tie > them to their corresponding OrgAuthority and Organization records. > > Aron > > On Mon, May 14, 2012 at 6:28 PM, Chris Hoffman > <chris.hoffman@berkeley.edu> wrote: >> Hi colleagues, >> According to the documentation about the contact service at >> http://wiki.collectionspace.org/display/collectionspace/Service+Layer+-+Services+Currently+Available >> >> The Contact service is currently exposed as a first-class service, but also >> has been refactored to operate as a sub-resource of Person and Organization. >> At a future time, its direct RESTful API will be removed. >> >> Does this mean that when creating an XML payload for importing Organization >> records, I can append the Contact schema and data for each record, and it >> will automatically link up? That is, I could have something that looked >> like: >> >> <imports> >> <import service="Organizations" type="Organization" >> CSID="77109ac6-5935-4ddf-b942-70debdcd9481"> >> <schema >> xmlns:organizations_common="http://collectionspace.org/services/organization" >> name="organizations_common"> >> ... organizations_common fields ... >> </schema> >> <schema >> xmlns:organizations_naturalhistory="http://collectionspace.org/services/organization/domain/naturalhistory" >> name="organizations_naturalhistory"> >> … domain extension fields ... >> </schema> >> >> <schema xmlns:contacts_common="http://collectionspace.org/services/contacts" name="contacts_common"> >> … contacts_common fields … >> </schema> >> </import> >> </imports> >> >> If so, do I have to provide the inAuthority and inItem fields for >> contacts_common, or are those derived from the rest of the payload? >> >> Or do I have to do a separate load of the contacts information? >> >> Thanks, >> Chris >