I'm looking to pull authority to/from procedural record relations using the services API. I see the relations service only does procedural to procedural but is there a way to pull out, for example, which collectionobject records are related to a specific person authority item? - Jesse

by related do you mean referenced in a field in the data or do you mean an explicit relationship that has been created? And if so - how was this relationship created? As it might just be friday afternoon but I can't think how you would create that relationship Chris On 02/03/2012 16:47, Jesse Martinez wrote: > I'm looking to pull authority to/from procedural record relations > using the services API. I see the relations service only does > procedural to procedural but is there a way to pull out, for example, > which collectionobject records are related to a specific person > authority item? > > - Jesse > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Right, an authority referenced in a field. I was using the term "related" too loosely in this sense, and conflating the relation service with something I figured would be similar to what I was asking about. In other words, by which mechanism do the layers show/list the procedural records "used by" a particular authority record in the UI? - Jesse On Fri, Mar 2, 2012 at 12:02 PM, Chris Martin <csm22@caret.cam.ac.uk> wrote: > by related do you mean referenced in a field in the data or do you mean an > explicit relationship that has been created? And if so - how was this > relationship created? As it might just be friday afternoon but I can't think > how you would create that relationship > > Chris > > > On 02/03/2012 16:47, Jesse Martinez wrote: >> >> I'm looking to pull authority to/from procedural record relations >> using the services API. I see the relations service only does >> procedural to procedural but is there a way to pull out, for example, >> which collectionobject records are related to a specific person >> authority item? >> >> - Jesse >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

> by which mechanism do the layers show/list the > procedural records "used by" a particular authority record in the UI? If I'm reading your question right, Jesse, this might be the services call to return Referring objects, or "refObjs": <http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances> "Retrieves and returns all objects (procedures, etc) that reference a given authority item. Information returned includes an abstraction of the fields in which they are used." On Fri, Mar 2, 2012 at 9:09 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: > Right, an authority referenced in a field. I was using the term > "related" too loosely in this sense, and conflating the relation > service with something I figured would be similar to what I was asking > about. > In other words, by which mechanism do the layers show/list the > procedural records "used by" a particular authority record in the UI? > >  - Jesse > > On Fri, Mar 2, 2012 at 12:02 PM, Chris Martin <csm22@caret.cam.ac.uk> wrote: >> by related do you mean referenced in a field in the data or do you mean an >> explicit relationship that has been created? And if so - how was this >> relationship created? As it might just be friday afternoon but I can't think >> how you would create that relationship >> >> Chris >> >> >> On 02/03/2012 16:47, Jesse Martinez wrote: >>> >>> I'm looking to pull authority to/from procedural record relations >>> using the services API. I see the relations service only does >>> procedural to procedural but is there a way to pull out, for example, >>> which collectionobject records are related to a specific person >>> authority item? >>> >>> - Jesse >>> >>> _______________________________________________ >>> 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

Yes, thank you Aron; this is what I was looking for. "Related" is a bit of a loaded word, it seems. A second concern: I'm not bringing up referenced object records to my modified (schema extended) person authority, yet I can do this successfully with an unmodified authority (org). Might this be related (no pun) to CSPACE-4783, which shows an issue with pulling up common schema names for extended authorities? Has there been a fix proposed for this issue? - Jesse On Fri, Mar 2, 2012 at 12:14 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: >> by which mechanism do the layers show/list the >> procedural records "used by" a particular authority record in the UI? > > If I'm reading your question right, Jesse, this might be the services > call to return Referring objects, or "refObjs": > > <http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances> > > "Retrieves and returns all objects (procedures, etc) that reference a > given authority item. Information returned includes an abstraction of > the fields in which they are used." > > On Fri, Mar 2, 2012 at 9:09 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: >> Right, an authority referenced in a field. I was using the term >> "related" too loosely in this sense, and conflating the relation >> service with something I figured would be similar to what I was asking >> about. >> In other words, by which mechanism do the layers show/list the >> procedural records "used by" a particular authority record in the UI? >> >>  - Jesse >> >> On Fri, Mar 2, 2012 at 12:02 PM, Chris Martin <csm22@caret.cam.ac.uk> wrote: >>> by related do you mean referenced in a field in the data or do you mean an >>> explicit relationship that has been created? And if so - how was this >>> relationship created? As it might just be friday afternoon but I can't think >>> how you would create that relationship >>> >>> Chris >>> >>> >>> On 02/03/2012 16:47, Jesse Martinez wrote: >>>> >>>> I'm looking to pull authority to/from procedural record relations >>>> using the services API. I see the relations service only does >>>> procedural to procedural but is there a way to pull out, for example, >>>> which collectionobject records are related to a specific person >>>> authority item? >>>> >>>> - Jesse >>>> >>>> _______________________________________________ >>>> 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 Fri, Mar 2, 2012 at 9:37 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: > A second concern: I'm not bringing up referenced object records to my > modified (schema extended) person authority, yet I can do this > successfully with an unmodified authority (org). Might this be related > (no pun) to CSPACE-4783, which shows an issue with pulling up common > schema names for extended authorities? Has there been a fix proposed > for this issue? On its face, I don't think this is related (pun intended), but I might well be wrong. From hazy memory, the search for referenced objects is conducted via an NXQL SELECT statement that looks in each field of an object / procedural / authority record (or all three - refObjs calls default to just procedural records) that is declared to hold authority references. That query does not use relation records. I haven't yet tried this first-hand, but it seems likely that you would need to declare, in the services tenant bindings delta file, (tenant-bindings-delta.xml) for your tenant, that certain fields in your custom schema extension for person records can hold authority references. That would include those fields in your extensions part in refObjs searches. You can follow the model for declaring fields that can hold authority references used by existing common schema parts, such as the persons_common part: <https://github.com/collectionspace/services/blob/master/services/common/src/main/cspace/config/services/tenants/tenant-bindings-proto.xml#L1935> Aron P.S. Note also that, according to the Common REST API link in the previous message, by default, refObjs searches include only procedures, so if you wanted to test those searches via services calls, in cURL or a browser or the like, you'd want to indicate that your refObjs searches include authority records. That also implies that you might want to check what call(s) are being made by the app layer to the services layer, to populate the referring objects list in the right sidebar, to see what record types are being included. > >  - Jesse > > > > On Fri, Mar 2, 2012 at 12:14 PM, Aron Roberts > <aron@socrates.berkeley.edu> wrote: >>> by which mechanism do the layers show/list the >>> procedural records "used by" a particular authority record in the UI? >> >> If I'm reading your question right, Jesse, this might be the services >> call to return Referring objects, or "refObjs": >> >> <http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances> >> >> "Retrieves and returns all objects (procedures, etc) that reference a >> given authority item. Information returned includes an abstraction of >> the fields in which they are used." >> >> On Fri, Mar 2, 2012 at 9:09 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: >>> Right, an authority referenced in a field. I was using the term >>> "related" too loosely in this sense, and conflating the relation >>> service with something I figured would be similar to what I was asking >>> about. >>> In other words, by which mechanism do the layers show/list the >>> procedural records "used by" a particular authority record in the UI? >>> >>>  - Jesse >>> >>> On Fri, Mar 2, 2012 at 12:02 PM, Chris Martin <csm22@caret.cam.ac.uk> wrote: >>>> by related do you mean referenced in a field in the data or do you mean an >>>> explicit relationship that has been created? And if so - how was this >>>> relationship created? As it might just be friday afternoon but I can't think >>>> how you would create that relationship >>>> >>>> Chris >>>> >>>> >>>> On 02/03/2012 16:47, Jesse Martinez wrote: >>>>> >>>>> I'm looking to pull authority to/from procedural record relations >>>>> using the services API. I see the relations service only does >>>>> procedural to procedural but is there a way to pull out, for example, >>>>> which collectionobject records are related to a specific person >>>>> authority item? >>>>> >>>>> - Jesse >>>>> >>>>> _______________________________________________ >>>>> Talk mailing list >>>>> Talk@lists.collectionspace.org >>>>> >>>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Thanks for pointing this out, Aron. I added the authRef keys and value pairs to the tenant binding delta file and it populated the "terms used" box for the object&procedural schemas I extended. (Which was something I've been meaning to tackle on a slow day.) I also added the authRef key and value pairs to the delta file since they were also missing, but this didn't have the same effect as the procedures. What I'm seeing, and continuing to see, in the logs is a failure to bring up any referenced procedural (or object) records from a given person authority item record when using the API refObjs path component. (Neither showing in the UI "terms used" box or the API.) Interestingly enough, it appears there is a malformed SQL query used when searching through the other doc types for any use of a specific person item. Here's what the query SHOULD look like, for instance, when using an unextended schema (in MMI's case, the organization authority): [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:486] findDocs() NXQL: SELECT * FROM Intake,Loanin,Loanout,ObjectExit,Group,Media,Movement,Acquisition WHERE collectionspace_core:tenantId = 42 AND (intakes_common:currentOwner='urn:cspace:movingimage.us:orgauthorities:name(organization):item:name(FOOORG1330643118130)\'FOOORG\'' OR ... But this is the malformed query when searching for referenced procedural records within a person item record: [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:486] findDocs() NXQL: SELECT * FROM PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 WHERE collectionspace_core:tenantId = 42 AND (intakes_common:currentOwner='urn:cspace:movingimage.us:personauthorities:name(person):item:name(oc4986)\'Ralph Forbes\'' OR ... Notice that instead of the different doc types it's just a repeating list of PersonTenant42 strings. What could be causing this? - Jesse Worth noting that we're using v2.0 On Fri, Mar 2, 2012 at 1:21 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > On Fri, Mar 2, 2012 at 9:37 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: >> A second concern: I'm not bringing up referenced object records to my >> modified (schema extended) person authority, yet I can do this >> successfully with an unmodified authority (org). Might this be related >> (no pun) to CSPACE-4783, which shows an issue with pulling up common >> schema names for extended authorities? Has there been a fix proposed >> for this issue? > >  On its face, I don't think this is related (pun intended), but I > might well be wrong. > >  From hazy memory, the search for referenced objects is conducted via > an NXQL SELECT statement that looks in each field of an object / > procedural / authority record (or all three - refObjs calls default to > just procedural records) that is declared to hold authority > references.  That query does not use relation records. > >  I haven't yet tried this first-hand, but it seems likely that you > would need to declare, in the services tenant bindings delta file, > (tenant-bindings-delta.xml) for your tenant, that certain fields in > your custom schema extension for person records can hold authority > references.  That would include those fields in your extensions part > in refObjs searches. > >  You can follow the model for declaring fields that can hold > authority references used by existing common schema parts, such as the > persons_common part: > > <https://github.com/collectionspace/services/blob/master/services/common/src/main/cspace/config/services/tenants/tenant-bindings-proto.xml#L1935> > > Aron > > P.S. Note also that, according to the Common REST API link in the > previous message, by default, refObjs searches include only > procedures, so if you wanted to test those searches via services > calls, in cURL or a browser or the like, you'd want to indicate that > your refObjs searches include authority records. > > That also implies that you might want to check what call(s) are being > made by the app layer to the services layer, to populate the referring > objects list in the right sidebar, to see what record types are being > included. > > > >> >>  - Jesse >> >> >> >> On Fri, Mar 2, 2012 at 12:14 PM, Aron Roberts >> <aron@socrates.berkeley.edu> wrote: >>>> by which mechanism do the layers show/list the >>>> procedural records "used by" a particular authority record in the UI? >>> >>> If I'm reading your question right, Jesse, this might be the services >>> call to return Referring objects, or "refObjs": >>> >>> <http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances> >>> >>> "Retrieves and returns all objects (procedures, etc) that reference a >>> given authority item. Information returned includes an abstraction of >>> the fields in which they are used." >>> >>> On Fri, Mar 2, 2012 at 9:09 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: >>>> Right, an authority referenced in a field. I was using the term >>>> "related" too loosely in this sense, and conflating the relation >>>> service with something I figured would be similar to what I was asking >>>> about. >>>> In other words, by which mechanism do the layers show/list the >>>> procedural records "used by" a particular authority record in the UI? >>>> >>>>  - Jesse >>>> >>>> On Fri, Mar 2, 2012 at 12:02 PM, Chris Martin <csm22@caret.cam.ac.uk> wrote: >>>>> by related do you mean referenced in a field in the data or do you mean an >>>>> explicit relationship that has been created? And if so - how was this >>>>> relationship created? As it might just be friday afternoon but I can't think >>>>> how you would create that relationship >>>>> >>>>> Chris >>>>> >>>>> >>>>> On 02/03/2012 16:47, Jesse Martinez wrote: >>>>>> >>>>>> I'm looking to pull authority to/from procedural record relations >>>>>> using the services API. I see the relations service only does >>>>>> procedural to procedural but is there a way to pull out, for example, >>>>>> which collectionobject records are related to a specific person >>>>>> authority item? >>>>>> >>>>>> - Jesse >>>>>> >>>>>> _______________________________________________ >>>>>> 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, Jesse, for this detailed summary. I can't speak just yet for the services-constructed NXQL query with "PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 ..." :-). But something else rang a bell: As for Used By records not appearing in the right sidebar for Person records (which you're extending with custom schema), I experimented with creating an standard, non-extended Organization record that contains a Person term, in its Contact Person field. When pivoting to that Person term, the Organization record referencing that term doesn't appear in its Used By area, either. From a quick glance, it appears that, at present, we may be uniformly using a query similar in form to the following to obtain a list of records that use a term: GET /cspace-services/personauthorities/urn:cspace:name(person)/items/52c54b17-ef1a-44fa-a4e6/refObjs?showRelations=true&wf_deleted=false This will return a list of records that reference the person term identified by CSID 52c54b17-ef1a-44fa-a4e6, within the default person authority (identified by the short identifier 'person'). But that call might not be returning *all* records that reference that term. According to this wiki page <http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances>, /refObjs queries "default to "procedure"; that is, will only return a list of *procedural* records that reference a term. That documentation also mentioned a "type" query parameter for refObjs calls, which can have values like "object", "procedure", and "authority". When adding "type=authority" to the above refObjs query, this now correctly returns the original Organization record that references that Person term: http://nightly.collectionspace.org:8180/cspace-services/personauthorities/urn:cspace:name%28person%29/items/52c54b17-ef1a-44fa-a4e6/refObjs?type=authority&showRelations=true&wf_deleted=false Anyway, that might possibly be a factor in what you're seeing, alongside the malformed query. Aron P.S. I can make a JIRA for the above later on, if there isn't one already present. On Sun, Mar 4, 2012 at 3:42 PM, Jesse Martinez <jmartinez@movingimage.us> wrote: > Thanks for pointing this out, Aron. I added the authRef keys and value > pairs to the tenant binding delta file and it populated the "terms > used" box for the object&procedural schemas I extended. (Which was > something I've been meaning to tackle on a slow day.) > > I also added the authRef key and value pairs to the delta file since > they were also missing, but this didn't have the same effect as the > procedures. What I'm seeing, and continuing to see, in the logs is a > failure to bring up any referenced procedural (or object) records from > a given person authority item record when using the API refObjs path > component. (Neither showing in the UI "terms used" box or the API.) > Interestingly enough, it appears there is a malformed SQL query used > when searching through the other doc types for any use of a specific > person item. > Here's what the query SHOULD look like, for instance, when using an > unextended schema (in MMI's case, the organization authority): > > [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:486] > findDocs() NXQL: SELECT * FROM > Intake,Loanin,Loanout,ObjectExit,Group,Media,Movement,Acquisition > WHERE collectionspace_core:tenantId = 42 AND > (intakes_common:currentOwner='urn:cspace:movingimage.us:orgauthorities:name(organization):item:name(FOOORG1330643118130)\'FOOORG\'' > OR > ... > > But this is the malformed query when searching for referenced > procedural records within a person item record: > > [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:486] > findDocs() NXQL: SELECT * FROM > PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 > WHERE collectionspace_core:tenantId = 42 AND > (intakes_common:currentOwner='urn:cspace:movingimage.us:personauthorities:name(person):item:name(oc4986)\'Ralph > Forbes\'' OR > ... > > Notice that instead of the different doc types it's just a repeating > list of PersonTenant42 strings. What could be causing this? > >  - Jesse > > Worth noting that we're using v2.0 > > > > On Fri, Mar 2, 2012 at 1:21 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: >> On Fri, Mar 2, 2012 at 9:37 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: >>> A second concern: I'm not bringing up referenced object records to my >>> modified (schema extended) person authority, yet I can do this >>> successfully with an unmodified authority (org). Might this be related >>> (no pun) to CSPACE-4783, which shows an issue with pulling up common >>> schema names for extended authorities? Has there been a fix proposed >>> for this issue? >> >>  On its face, I don't think this is related (pun intended), but I >> might well be wrong. >> >>  From hazy memory, the search for referenced objects is conducted via >> an NXQL SELECT statement that looks in each field of an object / >> procedural / authority record (or all three - refObjs calls default to >> just procedural records) that is declared to hold authority >> references.  That query does not use relation records. >> >>  I haven't yet tried this first-hand, but it seems likely that you >> would need to declare, in the services tenant bindings delta file, >> (tenant-bindings-delta.xml) for your tenant, that certain fields in >> your custom schema extension for person records can hold authority >> references.  That would include those fields in your extensions part >> in refObjs searches. >> >>  You can follow the model for declaring fields that can hold >> authority references used by existing common schema parts, such as the >> persons_common part: >> >> <https://github.com/collectionspace/services/blob/master/services/common/src/main/cspace/config/services/tenants/tenant-bindings-proto.xml#L1935> >> >> Aron >> >> P.S. Note also that, according to the Common REST API link in the >> previous message, by default, refObjs searches include only >> procedures, so if you wanted to test those searches via services >> calls, in cURL or a browser or the like, you'd want to indicate that >> your refObjs searches include authority records. >> >> That also implies that you might want to check what call(s) are being >> made by the app layer to the services layer, to populate the referring >> objects list in the right sidebar, to see what record types are being >> included. >> >> >> >>> >>>  - Jesse >>> >>> >>> >>> On Fri, Mar 2, 2012 at 12:14 PM, Aron Roberts >>> <aron@socrates.berkeley.edu> wrote: >>>>> by which mechanism do the layers show/list the >>>>> procedural records "used by" a particular authority record in the UI? >>>> >>>> If I'm reading your question right, Jesse, this might be the services >>>> call to return Referring objects, or "refObjs": >>>> >>>> <http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances> >>>> >>>> "Retrieves and returns all objects (procedures, etc) that reference a >>>> given authority item. Information returned includes an abstraction of >>>> the fields in which they are used." >>>> >>>> On Fri, Mar 2, 2012 at 9:09 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: >>>>> Right, an authority referenced in a field. I was using the term >>>>> "related" too loosely in this sense, and conflating the relation >>>>> service with something I figured would be similar to what I was asking >>>>> about. >>>>> In other words, by which mechanism do the layers show/list the >>>>> procedural records "used by" a particular authority record in the UI? >>>>> >>>>>  - Jesse >>>>> >>>>> On Fri, Mar 2, 2012 at 12:02 PM, Chris Martin <csm22@caret.cam.ac.uk> wrote: >>>>>> by related do you mean referenced in a field in the data or do you mean an >>>>>> explicit relationship that has been created? And if so - how was this >>>>>> relationship created? As it might just be friday afternoon but I can't think >>>>>> how you would create that relationship >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On 02/03/2012 16:47, Jesse Martinez wrote: >>>>>>> >>>>>>> I'm looking to pull authority to/from procedural record relations >>>>>>> using the services API. I see the relations service only does >>>>>>> procedural to procedural but is there a way to pull out, for example, >>>>>>> which collectionobject records are related to a specific person >>>>>>> authority item? >>>>>>> >>>>>>> - Jesse >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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

There definitely seems to be issues with custom doctypes pertaining to extended schemas. Here I've detailed the experimentation process I used before along with the results from several API calls. First, some backstory. I've extended collectionobject, acquisition, and person so that my doctypes should be CollectionObjectTentant42, AcquisitionTenant42 and PersonTenant42. We're not using the org authority so the above schemas only accept person authorities as per the app layer config. I've created a few sample records for person, org, collectionobject, acquisition, media handling, and object exit. The last two are unextended and can accept person and org authority items in their respective records. Collectionobject and the three procedures are all related. (No reason other than to make sure they have correct relations between each other.) Additionally, these records all have at least one shared person authority item. The two nonextended procedures have at least one shared org authority item. Here are the URLs for the various records: (X=extended, P=person, O=org) Org: FOOORG - http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/organization.html?csid=667fb5f5-b718-4f7a-827c (P) Person: FOOPERSON - http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/person.html?csid=442a6f9e-e361-4369-a8e3 (X,P) Cataloging: http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/cataloging.html?csid=b6afe488-7dc9-4cfb-ba96 (X,P) Acquisition: http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/acquisition.html?csid=7893b2a0-d81f-4529-beee (X,P) Object Exit: http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/objectexit.html?csid=885fc106-81dc-41d4-be2b (P,O) Media Handling: http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/media.html?csid=bdcaed99-adcd-41cd-99e2 (P,O) Next, here are the results from an API call to get referenced objects, procedures and authorities. API1. http://cspacetest.collectionspace.org:8180/cspace-services/orgauthorities/0cbfc8cf-36e4-4a07-9020/items/667fb5f5-b718-4f7a-827c/refObjs returns Object Exit (885fc106-81dc-41d4-be2b) and Media Handling (bdcaed99-adcd-41cd-99e2). This is expected. API2. http://cspacetest.collectionspace.org:8180/cspace-services/orgauthorities/0cbfc8cf-36e4-4a07-9020/items/667fb5f5-b718-4f7a-827c/refObjs?type=object returns none. This is expected API3. http://cspacetest.collectionspace.org:8180/cspace-services/orgauthorities/0cbfc8cf-36e4-4a07-9020/items/667fb5f5-b718-4f7a-827c/refObjs?type=authority returns none. Should return Person (442a6f9e-e361-4369-a8e3) API4. http://cspacetest.collectionspace.org:8180/cspace-services/personauthorities/acc60b93-3a09-47eb-bd8f/items/442a6f9e-e361-4369-a8e3/refObjs API5. http://cspacetest.collectionspace.org:8180/cspace-services/personauthorities/acc60b93-3a09-47eb-bd8f/items/442a6f9e-e361-4369-a8e3/refObjs?type=object API6. http://cspacetest.collectionspace.org:8180/cspace-services/personauthorities/acc60b93-3a09-47eb-bd8f/items/442a6f9e-e361-4369-a8e3/refObjs?type=authority all return none. This is wrong. Here are the SQL queries seen in cspace-services.log from the above numbered API calls (API1-6) Q1. NXQL: SELECT * FROM Intake,Loanin,Loanout,ObjectExit,Group,Media,Movement,Acquisition WHERE ... Q2. NXQL: SELECT * FROM CollectionObject WHERE ... Q3. NXQL: SELECT * FROM Organization,Person,Taxon WHERE ... Q4. NXQL: SELECT * FROM PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 WHERE ... Q5. NXQL: SELECT * FROM PersonTenant42 WHERE ... Q6. NXQL: SELECT * FROM PersonTenant42,PersonTenant42,PersonTenant42 WHERE ... As can be seen, the first three API calls to org don't search through the custom doctypes. The first call does return correct results only because Media and Object Exit aren't extended. The last three (Q4-6) seem to like PersonTenant42. My next experiment is to see if allowing a field to accept an org authority in a record type with an extended schema will change the API results. For this I amended Acquisition Source to pull from both the person and org authorities for autocomplete via app config base-procedure-acquisition. After reinitializing the app layer I added FOOORG to Acquisition Source. Here are the results. [Using the above short-hand notation Acquisition should be described as (X,P,O)] API7. http://cspacetest.collectionspace.org:8180/cspace-services/orgauthorities/0cbfc8cf-36e4-4a07-9020/items/667fb5f5-b718-4f7a-827c/refObjs Q7. NXQL: SELECT * FROM Intake,Loanin,Loanout,ObjectExit,Group,Media,Movement,Acquisition WHERE ... returns "Get failed, the requested Item CSID:667fb5f5-b718-4f7a-827c: was not found." Logs show: ERROR [http-8180-2] [org.collectionspace.services.common.vocabulary.RefNameServiceUtils:244] Could not retrieve the Nuxeo repository java.lang.RuntimeException: getAuthorityRefDocs: No Service Binding for docType: AcquisitionTenant42 API call with refObjs type object and authority performed exactly as before, of course. - Jesse On Sun, Mar 4, 2012 at 7:41 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: >  Thanks, Jesse, for this detailed summary. > >  I can't speak just yet for the services-constructed NXQL query with > "PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 > ..." :-).  But something else rang a bell: > >  As for Used By records not appearing in the right sidebar for Person > records (which you're extending with custom schema), I experimented > with creating an standard, non-extended Organization record that > contains a Person term, in its Contact Person field.  When pivoting to > that Person term, the Organization record referencing that term > doesn't appear in its Used By area, either. > >  From a quick glance, it appears that, at present, we may be > uniformly using a query similar in form to the following to obtain a > list of records that use a term: > > GET /cspace-services/personauthorities/urn:cspace:name(person)/items/52c54b17-ef1a-44fa-a4e6/refObjs?showRelations=true&wf_deleted=false > >  This will return a list of records that reference the person term > identified by CSID 52c54b17-ef1a-44fa-a4e6, within the default person > authority (identified by the short identifier 'person').  But that > call might not be returning *all* records that reference that term. > >  According to this wiki page > <http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances>, > /refObjs queries "default to "procedure"; that is, will only return a > list of *procedural* records that reference a term. > >  That documentation also mentioned a "type" query parameter for > refObjs calls, which can have values like "object", "procedure", and > "authority".  When adding "type=authority" to the above refObjs query, > this now correctly returns the original Organization record that > references that Person term: > > http://nightly.collectionspace.org:8180/cspace-services/personauthorities/urn:cspace:name%28person%29/items/52c54b17-ef1a-44fa-a4e6/refObjs?type=authority&showRelations=true&wf_deleted=false > >  Anyway, that might possibly be a factor in what you're seeing, > alongside the malformed query. > > Aron > > P.S. I can make a JIRA for the above later on, if there isn't one > already present. > > On Sun, Mar 4, 2012 at 3:42 PM, Jesse Martinez <jmartinez@movingimage.us> wrote: >> Thanks for pointing this out, Aron. I added the authRef keys and value >> pairs to the tenant binding delta file and it populated the "terms >> used" box for the object&procedural schemas I extended. (Which was >> something I've been meaning to tackle on a slow day.) >> >> I also added the authRef key and value pairs to the delta file since >> they were also missing, but this didn't have the same effect as the >> procedures. What I'm seeing, and continuing to see, in the logs is a >> failure to bring up any referenced procedural (or object) records from >> a given person authority item record when using the API refObjs path >> component. (Neither showing in the UI "terms used" box or the API.) >> Interestingly enough, it appears there is a malformed SQL query used >> when searching through the other doc types for any use of a specific >> person item. >> Here's what the query SHOULD look like, for instance, when using an >> unextended schema (in MMI's case, the organization authority): >> >> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:486] >> findDocs() NXQL: SELECT * FROM >> Intake,Loanin,Loanout,ObjectExit,Group,Media,Movement,Acquisition >> WHERE collectionspace_core:tenantId = 42 AND >> (intakes_common:currentOwner='urn:cspace:movingimage.us:orgauthorities:name(organization):item:name(FOOORG1330643118130)\'FOOORG\'' >> OR >> ... >> >> But this is the malformed query when searching for referenced >> procedural records within a person item record: >> >> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:486] >> findDocs() NXQL: SELECT * FROM >> PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 >> WHERE collectionspace_core:tenantId = 42 AND >> (intakes_common:currentOwner='urn:cspace:movingimage.us:personauthorities:name(person):item:name(oc4986)\'Ralph >> Forbes\'' OR >> ... >> >> Notice that instead of the different doc types it's just a repeating >> list of PersonTenant42 strings. What could be causing this? >> >>  - Jesse >> >> Worth noting that we're using v2.0 >> >> >> >> On Fri, Mar 2, 2012 at 1:21 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: >>> On Fri, Mar 2, 2012 at 9:37 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: >>>> A second concern: I'm not bringing up referenced object records to my >>>> modified (schema extended) person authority, yet I can do this >>>> successfully with an unmodified authority (org). Might this be related >>>> (no pun) to CSPACE-4783, which shows an issue with pulling up common >>>> schema names for extended authorities? Has there been a fix proposed >>>> for this issue? >>> >>>  On its face, I don't think this is related (pun intended), but I >>> might well be wrong. >>> >>>  From hazy memory, the search for referenced objects is conducted via >>> an NXQL SELECT statement that looks in each field of an object / >>> procedural / authority record (or all three - refObjs calls default to >>> just procedural records) that is declared to hold authority >>> references.  That query does not use relation records. >>> >>>  I haven't yet tried this first-hand, but it seems likely that you >>> would need to declare, in the services tenant bindings delta file, >>> (tenant-bindings-delta.xml) for your tenant, that certain fields in >>> your custom schema extension for person records can hold authority >>> references.  That would include those fields in your extensions part >>> in refObjs searches. >>> >>>  You can follow the model for declaring fields that can hold >>> authority references used by existing common schema parts, such as the >>> persons_common part: >>> >>> <https://github.com/collectionspace/services/blob/master/services/common/src/main/cspace/config/services/tenants/tenant-bindings-proto.xml#L1935> >>> >>> Aron >>> >>> P.S. Note also that, according to the Common REST API link in the >>> previous message, by default, refObjs searches include only >>> procedures, so if you wanted to test those searches via services >>> calls, in cURL or a browser or the like, you'd want to indicate that >>> your refObjs searches include authority records. >>> >>> That also implies that you might want to check what call(s) are being >>> made by the app layer to the services layer, to populate the referring >>> objects list in the right sidebar, to see what record types are being >>> included. >>> >>> >>> >>>> >>>>  - Jesse >>>> >>>> >>>> >>>> On Fri, Mar 2, 2012 at 12:14 PM, Aron Roberts >>>> <aron@socrates.berkeley.edu> wrote: >>>>>> by which mechanism do the layers show/list the >>>>>> procedural records "used by" a particular authority record in the UI? >>>>> >>>>> If I'm reading your question right, Jesse, this might be the services >>>>> call to return Referring objects, or "refObjs": >>>>> >>>>> <http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances> >>>>> >>>>> "Retrieves and returns all objects (procedures, etc) that reference a >>>>> given authority item. Information returned includes an abstraction of >>>>> the fields in which they are used." >>>>> >>>>> On Fri, Mar 2, 2012 at 9:09 AM, Jesse Martinez <jmartinez@movingimage.us> wrote: >>>>>> Right, an authority referenced in a field. I was using the term >>>>>> "related" too loosely in this sense, and conflating the relation >>>>>> service with something I figured would be similar to what I was asking >>>>>> about. >>>>>> In other words, by which mechanism do the layers show/list the >>>>>> procedural records "used by" a particular authority record in the UI? >>>>>> >>>>>>  - Jesse >>>>>> >>>>>> On Fri, Mar 2, 2012 at 12:02 PM, Chris Martin <csm22@caret.cam.ac.uk> wrote: >>>>>>> by related do you mean referenced in a field in the data or do you mean an >>>>>>> explicit relationship that has been created? And if so - how was this >>>>>>> relationship created? As it might just be friday afternoon but I can't think >>>>>>> how you would create that relationship >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>>> On 02/03/2012 16:47, Jesse Martinez wrote: >>>>>>>> >>>>>>>> I'm looking to pull authority to/from procedural record relations >>>>>>>> using the services API. I see the relations service only does >>>>>>>> procedural to procedural but is there a way to pull out, for example, >>>>>>>> which collectionobject records are related to a specific person >>>>>>>> authority item? >>>>>>>> >>>>>>>> - Jesse >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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

Following up on this issue. It seems there are two separate issues causing this complicated behavior on v2.0 (and possibly other versions.) The first was how the NXQL query was misconfigured for searching for referencing procedural records. I traced this to how the tenant qualified docType string wasn't being produced correctly. My analysis and hack to this is here: http://issues.collectionspace.org/browse/CSPACE-4943 The second issue was how the service bindings for a given tenant didn't contain references to a tenant qualified docType string but was searched upon by a method looking for the tenant qualified docType string. This is caused when searching for referencing procedures to a given authority record. My analysis and hack is here: http://issues.collectionspace.org/browse/CSPACE-4944 - Jesse On Sun, Mar 4, 2012 at 9:33 PM, Jesse Martinez <jmartinez@movingimage.us>wrote: > There definitely seems to be issues with custom doctypes pertaining to > extended schemas. Here I've detailed the experimentation process I > used before along with the results from several API calls. > > > First, some backstory. I've extended collectionobject, acquisition, > and person so that my doctypes should be CollectionObjectTentant42, > AcquisitionTenant42 and PersonTenant42. > We're not using the org authority so the above schemas only accept > person authorities as per the app layer config. > I've created a few sample records for person, org, collectionobject, > acquisition, media handling, and object exit. The last two are > unextended and can accept person and org authority items in their > respective records. > Collectionobject and the three procedures are all related. (No reason > other than to make sure they have correct relations between each > other.) Additionally, these records all have at least one shared > person authority item. The two nonextended procedures have at least > one shared org authority item. > > Here are the URLs for the various records: (X=extended, P=person, O=org) > Org: FOOORG - > http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/organization.html?csid=667fb5f5-b718-4f7a-827c > (P) > Person: FOOPERSON - > > http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/person.html?csid=442a6f9e-e361-4369-a8e3 > (X,P) > Cataloging: > http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/cataloging.html?csid=b6afe488-7dc9-4cfb-ba96 > (X,P) > Acquisition: > http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/acquisition.html?csid=7893b2a0-d81f-4529-beee > (X,P) > Object Exit: > http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/objectexit.html?csid=885fc106-81dc-41d4-be2b > (P,O) > Media Handling: > > http://cspacetest.collectionspace.org:8180/collectionspace/ui/mmi/html/media.html?csid=bdcaed99-adcd-41cd-99e2 > (P,O) > > Next, here are the results from an API call to get referenced objects, > procedures and authorities. > > API1. > http://cspacetest.collectionspace.org:8180/cspace-services/orgauthorities/0cbfc8cf-36e4-4a07-9020/items/667fb5f5-b718-4f7a-827c/refObjs > returns Object Exit (885fc106-81dc-41d4-be2b) and Media Handling > (bdcaed99-adcd-41cd-99e2). This is expected. > > API2. > http://cspacetest.collectionspace.org:8180/cspace-services/orgauthorities/0cbfc8cf-36e4-4a07-9020/items/667fb5f5-b718-4f7a-827c/refObjs?type=object > returns none. This is expected > > API3. > http://cspacetest.collectionspace.org:8180/cspace-services/orgauthorities/0cbfc8cf-36e4-4a07-9020/items/667fb5f5-b718-4f7a-827c/refObjs?type=authority > returns none. Should return Person (442a6f9e-e361-4369-a8e3) > > API4. > http://cspacetest.collectionspace.org:8180/cspace-services/personauthorities/acc60b93-3a09-47eb-bd8f/items/442a6f9e-e361-4369-a8e3/refObjs > API5. > http://cspacetest.collectionspace.org:8180/cspace-services/personauthorities/acc60b93-3a09-47eb-bd8f/items/442a6f9e-e361-4369-a8e3/refObjs?type=object > API6. > http://cspacetest.collectionspace.org:8180/cspace-services/personauthorities/acc60b93-3a09-47eb-bd8f/items/442a6f9e-e361-4369-a8e3/refObjs?type=authority > all return none. This is wrong. > > Here are the SQL queries seen in cspace-services.log from the above > numbered API calls (API1-6) > > Q1. NXQL: SELECT * FROM > Intake,Loanin,Loanout,ObjectExit,Group,Media,Movement,Acquisition > WHERE ... > > Q2. NXQL: SELECT * FROM CollectionObject WHERE ... > > Q3. NXQL: SELECT * FROM Organization,Person,Taxon WHERE ... > > Q4. NXQL: SELECT * FROM > > PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 > WHERE ... > > Q5. NXQL: SELECT * FROM PersonTenant42 WHERE ... > > Q6. NXQL: SELECT * FROM PersonTenant42,PersonTenant42,PersonTenant42 WHERE > ... > > > As can be seen, the first three API calls to org don't search through > the custom doctypes. The first call does return correct results only > because Media and Object Exit aren't extended. The last three (Q4-6) > seem to like PersonTenant42. > > > My next experiment is to see if allowing a field to accept an org > authority in a record type with an extended schema will change the API > results. For this I amended Acquisition Source to pull from both the > person and org authorities for autocomplete via app config > base-procedure-acquisition. After reinitializing the app layer I added > FOOORG to Acquisition Source. Here are the results. [Using the above > short-hand notation Acquisition should be described as (X,P,O)] > > API7. > http://cspacetest.collectionspace.org:8180/cspace-services/orgauthorities/0cbfc8cf-36e4-4a07-9020/items/667fb5f5-b718-4f7a-827c/refObjs > > Q7. NXQL: SELECT * FROM > Intake,Loanin,Loanout,ObjectExit,Group,Media,Movement,Acquisition > WHERE ... > returns "Get failed, the requested Item CSID:667fb5f5-b718-4f7a-827c: > was not found." > Logs show: > ERROR [http-8180-2] > [org.collectionspace.services.common.vocabulary.RefNameServiceUtils:244] > Could not retrieve the Nuxeo repository > java.lang.RuntimeException: getAuthorityRefDocs: No Service Binding > for docType: AcquisitionTenant42 > > API call with refObjs type object and authority performed exactly as > before, of course. > > - Jesse > > > On Sun, Mar 4, 2012 at 7:41 PM, Aron Roberts <aron@socrates.berkeley.edu> > wrote: > > Thanks, Jesse, for this detailed summary. > > > > I can't speak just yet for the services-constructed NXQL query with > > > "PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 > > ..." :-). But something else rang a bell: > > > > As for Used By records not appearing in the right sidebar for Person > > records (which you're extending with custom schema), I experimented > > with creating an standard, non-extended Organization record that > > contains a Person term, in its Contact Person field. When pivoting to > > that Person term, the Organization record referencing that term > > doesn't appear in its Used By area, either. > > > > From a quick glance, it appears that, at present, we may be > > uniformly using a query similar in form to the following to obtain a > > list of records that use a term: > > > > GET > /cspace-services/personauthorities/urn:cspace:name(person)/items/52c54b17-ef1a-44fa-a4e6/refObjs?showRelations=true&wf_deleted=false > > > > This will return a list of records that reference the person term > > identified by CSID 52c54b17-ef1a-44fa-a4e6, within the default person > > authority (identified by the short identifier 'person'). But that > > call might not be returning *all* records that reference that term. > > > > According to this wiki page > > < > http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances > >, > > /refObjs queries "default to "procedure"; that is, will only return a > > list of *procedural* records that reference a term. > > > > That documentation also mentioned a "type" query parameter for > > refObjs calls, which can have values like "object", "procedure", and > > "authority". When adding "type=authority" to the above refObjs query, > > this now correctly returns the original Organization record that > > references that Person term: > > > > > http://nightly.collectionspace.org:8180/cspace-services/personauthorities/urn:cspace:name%28person%29/items/52c54b17-ef1a-44fa-a4e6/refObjs?type=authority&showRelations=true&wf_deleted=false > > > > Anyway, that might possibly be a factor in what you're seeing, > > alongside the malformed query. > > > > Aron > > > > P.S. I can make a JIRA for the above later on, if there isn't one > > already present. > > > > On Sun, Mar 4, 2012 at 3:42 PM, Jesse Martinez <jmartinez@movingimage.us> > wrote: > >> Thanks for pointing this out, Aron. I added the authRef keys and value > >> pairs to the tenant binding delta file and it populated the "terms > >> used" box for the object&procedural schemas I extended. (Which was > >> something I've been meaning to tackle on a slow day.) > >> > >> I also added the authRef key and value pairs to the delta file since > >> they were also missing, but this didn't have the same effect as the > >> procedures. What I'm seeing, and continuing to see, in the logs is a > >> failure to bring up any referenced procedural (or object) records from > >> a given person authority item record when using the API refObjs path > >> component. (Neither showing in the UI "terms used" box or the API.) > >> Interestingly enough, it appears there is a malformed SQL query used > >> when searching through the other doc types for any use of a specific > >> person item. > >> Here's what the query SHOULD look like, for instance, when using an > >> unextended schema (in MMI's case, the organization authority): > >> > >> > [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:486] > >> findDocs() NXQL: SELECT * FROM > >> Intake,Loanin,Loanout,ObjectExit,Group,Media,Movement,Acquisition > >> WHERE collectionspace_core:tenantId = 42 AND > >> (intakes_common:currentOwner='urn:cspace:movingimage.us: > orgauthorities:name(organization):item:name(FOOORG1330643118130)\'FOOORG\'' > >> OR > >> ... > >> > >> But this is the malformed query when searching for referenced > >> procedural records within a person item record: > >> > >> > [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:486] > >> findDocs() NXQL: SELECT * FROM > >> > PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42,PersonTenant42 > >> WHERE collectionspace_core:tenantId = 42 AND > >> (intakes_common:currentOwner='urn:cspace:movingimage.us: > personauthorities:name(person):item:name(oc4986)\'Ralph > >> Forbes\'' OR > >> ... > >> > >> Notice that instead of the different doc types it's just a repeating > >> list of PersonTenant42 strings. What could be causing this? > >> > >> - Jesse > >> > >> Worth noting that we're using v2.0 > >> > >> > >> > >> On Fri, Mar 2, 2012 at 1:21 PM, Aron Roberts < > aron@socrates.berkeley.edu> wrote: > >>> On Fri, Mar 2, 2012 at 9:37 AM, Jesse Martinez < > jmartinez@movingimage.us> wrote: > >>>> A second concern: I'm not bringing up referenced object records to my > >>>> modified (schema extended) person authority, yet I can do this > >>>> successfully with an unmodified authority (org). Might this be related > >>>> (no pun) to CSPACE-4783, which shows an issue with pulling up common > >>>> schema names for extended authorities? Has there been a fix proposed > >>>> for this issue? > >>> > >>> On its face, I don't think this is related (pun intended), but I > >>> might well be wrong. > >>> > >>> From hazy memory, the search for referenced objects is conducted via > >>> an NXQL SELECT statement that looks in each field of an object / > >>> procedural / authority record (or all three - refObjs calls default to > >>> just procedural records) that is declared to hold authority > >>> references. That query does not use relation records. > >>> > >>> I haven't yet tried this first-hand, but it seems likely that you > >>> would need to declare, in the services tenant bindings delta file, > >>> (tenant-bindings-delta.xml) for your tenant, that certain fields in > >>> your custom schema extension for person records can hold authority > >>> references. That would include those fields in your extensions part > >>> in refObjs searches. > >>> > >>> You can follow the model for declaring fields that can hold > >>> authority references used by existing common schema parts, such as the > >>> persons_common part: > >>> > >>> < > https://github.com/collectionspace/services/blob/master/services/common/src/main/cspace/config/services/tenants/tenant-bindings-proto.xml#L1935 > > > >>> > >>> Aron > >>> > >>> P.S. Note also that, according to the Common REST API link in the > >>> previous message, by default, refObjs searches include only > >>> procedures, so if you wanted to test those searches via services > >>> calls, in cURL or a browser or the like, you'd want to indicate that > >>> your refObjs searches include authority records. > >>> > >>> That also implies that you might want to check what call(s) are being > >>> made by the app layer to the services layer, to populate the referring > >>> objects list in the right sidebar, to see what record types are being > >>> included. > >>> > >>> > >>> > >>>> > >>>> - Jesse > >>>> > >>>> > >>>> > >>>> On Fri, Mar 2, 2012 at 12:14 PM, Aron Roberts > >>>> <aron@socrates.berkeley.edu> wrote: > >>>>>> by which mechanism do the layers show/list the > >>>>>> procedural records "used by" a particular authority record in the > UI? > >>>>> > >>>>> If I'm reading your question right, Jesse, this might be the services > >>>>> call to return Referring objects, or "refObjs": > >>>>> > >>>>> < > http://wiki.collectionspace.org/display/collectionspace/Common+Services+REST+API+documentation#CommonServicesRESTAPIdocumentation-RelatedObjectReferencesforauthorityterminstances > > > >>>>> > >>>>> "Retrieves and returns all objects (procedures, etc) that reference a > >>>>> given authority item. Information returned includes an abstraction of > >>>>> the fields in which they are used." > >>>>> > >>>>> On Fri, Mar 2, 2012 at 9:09 AM, Jesse Martinez < > jmartinez@movingimage.us> wrote: > >>>>>> Right, an authority referenced in a field. I was using the term > >>>>>> "related" too loosely in this sense, and conflating the relation > >>>>>> service with something I figured would be similar to what I was > asking > >>>>>> about. > >>>>>> In other words, by which mechanism do the layers show/list the > >>>>>> procedural records "used by" a particular authority record in the > UI? > >>>>>> > >>>>>> - Jesse > >>>>>> > >>>>>> On Fri, Mar 2, 2012 at 12:02 PM, Chris Martin < > csm22@caret.cam.ac.uk> wrote: > >>>>>>> by related do you mean referenced in a field in the data or do you > mean an > >>>>>>> explicit relationship that has been created? And if so - how was > this > >>>>>>> relationship created? As it might just be friday afternoon but I > can't think > >>>>>>> how you would create that relationship > >>>>>>> > >>>>>>> Chris > >>>>>>> > >>>>>>> > >>>>>>> On 02/03/2012 16:47, Jesse Martinez wrote: > >>>>>>>> > >>>>>>>> I'm looking to pull authority to/from procedural record relations > >>>>>>>> using the services API. I see the relations service only does > >>>>>>>> procedural to procedural but is there a way to pull out, for > example, > >>>>>>>> which collectionobject records are related to a specific person > >>>>>>>> authority item? > >>>>>>>> > >>>>>>>> - Jesse > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 >