...
Profiles may be updated by doing a PUT with a new profile to /cp/repositories/<orgidentifier>, and can be deleted by doing a DELETE to the same URL.
Currently, the Bob repository has a profile that shows the entries required to trigger the existing rules (/cp/researchobjects/matchingrepositories/rules):
People:
Personal profiles are available through the /cp/people endpoint. Navigating to this endpoint lists the current set of profiles being managed. New profiles can be added by sending a POST to /cp/people with a json object indicating the provider and identifier for the person at that provider. Currently only ORCID profiles are supported, so POSTs would contain "{"provider": ORCID", "identifier":"<numeric ORCID_ID> }" where "0000-0003-2164-8132" is one such identifier. Individual profiles can be retrieved from /cp/people/<id>, e.g. /cp/people/0000-0003-2164-8132. An empty PUT to a specific profile endpoint will cause a refresh (the profile will be retrieved from ORCID again), and DELETE will remove the profile.
...
Create a collection and add subcollections and content as usual in the Beta Test Project Space. To create a new publication request, hit the "Submit for Publication" Button.
One that is current as of 9/16/15 has been created as https://sead-test.ncsa.illinois.edu/sead-cp/cp/researchobjects/tag:sead-data.net,2015:RO_23hQD7ujKGLL0-BqJ1CTTQ .
Since we do not yet have a Staging Area, changing preferences or setting the repository target for publication require Admin privileges and setting the Project Space default values for these entries. Going to Admin Page/Config Tab/ 2.0 Beta Publication section, set the default repository and preferences as desired and hit "submit". New requests made will use these values.
...
To test matchmaking, the simplest approach, given that there are no staging areas yet, is to copy an existing publication request entry and remove the Affiliations, Repository, and Status entries. The JSON object with the remaining Aggregation and Preferences entries can be POSTed to /cp/researchobjects/matchingrepositories to receive a json document with the scores. Note that rules will only fire if the repository profile has the appropriate value as listed in /cp/researchobjects/matchingrepositories/rules , i.e. to limit dataset size, a repository profile must include "Max Dataset Size":<long value in bytes>. The score document includes a message describing whether a rule fired or not and why the result is what it is.
(Posting the content of https://sead-test.ncsa.illinois.edu/sead-cp/cp/researchobjects/tag:sead-data.net,2015:RO_23hQD7ujKGLL0-BqJ1CTTQ as is to the matching endpoint should work. Nominally, a matching request would not include status or a repository choice, but these fields are ignored, so you don't have to delete them. To make this work, be sure that the content type and accept type are both application/json. The response I receive from this is shown below:
This depends on the current content for that curation object, the current profile for the Bob repository, and the active current rule set. )
Behind the scenes, these rules are retrieving statistical summary information from the project space by using the ORE:similarTo link in the POSTed JSON, which refers to the live collection being aggregated and adding "/stats" to the end of it to invoke the statistics endpoint for that collection. The response from this includes information including, for example, the maximium dataset size in the research object/collection which can then be compared against the repository's requirement. You can make the same request manually to see the information returned.
...