HI Chris,

Importing relations is fun!  Here's a test payload I a recently loaded for the UC Botanical Garden.  I don't know if you need all these fields (the subject and object CSIDs, URIs, and doc types and refNames), but they were in the payload so I just populated them.  I'm working on 2.4 though so this might not be needed any longer.

Chris

On Nov 28, 2012, at 5:13 AM, Christopher Pott wrote:

Chris,

Hi! Yes, Importing relations is a lot of fun!

Here's the template for the REST payload used to POST BT relations
(one at a time) for the PAHMA location authority (also v2.4). I notice
some "dialect differences" between Chris H.'s and mine...not sure how
to account for them.

Good hunting!

John

On Wed, Nov 28, 2012 at 10:47 AM, Chris Hoffman chris_h@berkeley.edu wrote:

Thanks much, Chris and John, for these examples!

Chris (Pott) and all: you can find several more examples of hierarchical
relation record payloads in datafiles used in automated tests of
CollectionSpace's Services layer.  These datafiles can be found in various
sub-directories of this test directory:

https://github.com/collectionspace/services/tree/master/services/IntegrationTests/src/test/resources/test-data/xmlreplay

In this particular directory, you can find some prototypical examples of
payloads you might send via the Services REST API - for hierarchical
cataloging records, introduced in v2.7 - such as these (payloads 2 through
7).  These demonstrate sending a list of relations (a
relations-common-list) as a separate part, alongside a part containing the
record to be created or updated, in a single request payload:

https://github.com/collectionspace/services/tree/master/services/IntegrationTests/src/test/resources/test-data/xmlreplay/collectionobject/hierarchy

In summary, you can either:

• Send an appropriate payload (such as for a Storage Location record),
  along with a relations-common-list, to the appropriate service (e.g. the
  Storage Location service), to create or update a record and its relations
  in a single request; or
• As in John's example, send relation record payloads by themselves, to the
  Relation service, to create/update relations on their own, separate from
  the records to which they pertain; or
• As in Chris Hoffman's example, use the Imports service to import object,
  procedural or authority/vocabulary records, and/or relation records that
  pertain to those records.

Also, to clarify in John's example, the document type
'LocationitemTenant15' is an extended document type for the Storage
Location record, which includes a custom schema part for a tenant (most
likely PAHMA) with tenant ID 15; hence the "Tenant15" suffix.  If you
haven't extended Storage Location records, the document type would likely
be just 'Locationitem'.

On Wed, Nov 28, 2012 at 10:53 AM, John B. LOWE jblowe@berkeley.edu wrote:

I think we stopped needing the tenant after a certain cspace version in
the 2's even if the schema is extended.

Susan

likely

extended Storage Location records, the document type would likely be
just

On Wed, Nov 28, 2012 at 12:52 PM, sstone@socrates.berkeley.edu wrote:

Good point, Susan.

Related to this: in a POST to the Relations service, I was also able to
omit the <subjectDocumentType> and <objectDocumentType> values entirely;
those values were automatically filled in by the Relations service (see
below).  In a minimal POST payload to create a hierarchical relationship,
only these three fields/values were needed (plus the relevant enclosing
tags, not shown here):

<subjectCsid>65c02de2-dc79-4f46-90c4</subjectCsid>
<relationshipType>hasBroader</relationshipType>
<objectCsid>87104c86-7585-4d52-8e95</objectCsid>

However, when importing records via the Imports service, that service
bypasses (for speed) most services code that would otherwise be invoked
when you using other parts of the Services REST APIs, including the crunchy
goodness that automatically fills in the document type values in relation
records.  So when using the Imports service, it's likely that you'd need to
provide at least the standard (not tenant qualified, per Susan) document
type values in <subjectDocumentType> and <objectDocumentType> in your
import payload.

Aron

--

Curl command to create a hierarchical relation record between two
Cataloging objects (CollectionObjects) (see below for the payload file
sent):

curl -i -u admin@core.collectionspace.org:Administrator -X POST -H
"Content-Type: application/xml"
http://localhost:8180/cspace-services/relations -T rel1.xml

Curl command to retrieve the relation record that was created via the
above command, with its response payload (XML pretty-printed for
readability):

curl -i -u admin@core.collectionspace.org:Administrator
http://localhost:8180/cspace-services/relations/737bcb88-88b1-407e-8e25

Contents of rel1.xml, the file containing the payload sent in the first,
'create' command:

--

Thanks to all who answered this with examples, they really help.

Aron, if I understand your summary correctly, then the confusing issue for me was that the "relations-common-list" can be used in the Services REST API but is not accepted by the import service. Plus, I must have made an error in my schema when I attempted importing the relation via a "relations_common" import schema - as this should have worked. I'll try again!

/Chris

Fra: Aron Roberts [mailto:aronroberts@gmail.com]
Sendt: 28. november 2012 20:56
Til: Christopher Pott; John B. LOWE; Chris Hoffman
Cc: CollectionSpace Talk List
Emne: Re: [Talk] importing Storage Locations

Thanks much, Chris and John, for these examples!

Chris (Pott) and all: you can find several more examples of hierarchical relation record payloads in datafiles used in automated tests of CollectionSpace's Services layer.  These datafiles can be found in various sub-directories of this test directory:

https://github.com/collectionspace/services/tree/master/services/IntegrationTests/src/test/resources/test-data/xmlreplay

In this particular directory, you can find some prototypical examples of payloads you might send via the Services REST API - for hierarchical cataloging records, introduced in v2.7 - such as these (payloads 2 through 7).  These demonstrate sending a list of relations (a relations-common-list) as a separate part, alongside a part containing the record to be created or updated, in a single request payload:

https://github.com/collectionspace/services/tree/master/services/IntegrationTests/src/test/resources/test-data/xmlreplay/collectionobject/hierarchy

In summary, you can either:

• Send an appropriate payload (such as for a Storage Location record), along with a relations-common-list, to the appropriate service (e.g. the Storage Location service), to create or update a record and its relations in a single request; or
• As in John's example, send relation record payloads by themselves, to the Relation service, to create/update relations on their own, separate from the records to which they pertain; or
• As in Chris Hoffman's example, use the Imports service to import object, procedural or authority/vocabulary records, and/or relation records that pertain to those records.

Also, to clarify in John's example, the document type 'LocationitemTenant15' is an extended document type for the Storage Location record, which includes a custom schema part for a tenant (most likely PAHMA) with tenant ID 15; hence the "Tenant15" suffix.  If you haven't extended Storage Location records, the document type would likely be just 'Locationitem'.
On Wed, Nov 28, 2012 at 10:53 AM, John B. LOWE <jblowe@berkeley.edumailto:jblowe@berkeley.edu> wrote:
Chris,

Hi! Yes, Importing relations is a lot of fun!

Here's the template for the REST payload used to POST BT relations
(one at a time) for the PAHMA location authority (also v2.4). I notice
some "dialect differences" between Chris H.'s and mine...not sure how
to account for them.

Good hunting!

John

On Wed, Nov 28, 2012 at 10:47 AM, Chris Hoffman <chris_h@berkeley.edumailto:chris_h@berkeley.edu> wrote:

Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

On Thu, Nov 29, 2012 at 5:16 AM, Christopher Pott
Christopher.Pott@smk.dk wrote:

Nice summary - yes, I believe that's correct, Chris.