-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Live Paper related KG Schema and API issues #298
Comments
I propose to rename |
That's a good idea. Lets go with that @apdavison. |
That's something to discuss. I think the live paper page should display its own name/title as the title, not the title of the associated paper/preprint. |
Some issues that need more immediate attention:
|
@apdavison .... a reminder that "license" still isn't being returned by the GET end-points. Receiving |
List of items to be resolved:
[ ] Corresponding author email field missing(GDPR issues)[ ] Created author email field missing(GDPR issues)[ ] Approved author email field missing(GDPR issues)Allow different people for corresponding author and approval author - approval author wil be set as custodian
Add support for resource items from the KG (e.g. models, traces, morphologies)
Add missing fields: version, date modified.... - replace created_date with modified_date
Avoid duplication check by article title (
paper_title
). Currently multiple entries with same title cannot be made. Might be required during dev phase to have multiple variants of LP before finalizing. We should rather add a fieldname
oralias
.PUT end-point should preferably return the LP object (as opposed to null); in accordance with other V2 VF PUT API end-points
PUT end-point returning code 200 (success) even for non-existent UUIDs
PUT end-point creating new LP entries when asked to update existing LP's name (paper title), even though UUID of LP to be updated is specified in invoked URL.
POST end-point updates entry (acts as PUT) for requests with existing paper titles; not raising the Exception as intended in code. [Awaited]
POST example: https://validation-v2.brainsimulation.eu/docs#/Live%20Papers/create_live_paper_livepapers__post
"id" field should be removed from example for POST (?)
For LivePaper, "url" and "doi" should be allowed to be empty (string/null) and not checked for URL format (during dev phase, it is useful to be able to create placeholders with empty urls) - empty string not allowed for "url" and "doi", null allowed
[ ] For LivePaperResourceItem, "url" and "view_url" ("mc_url") should be allowed to be empty (string/null) and not checked for URL format (during dev phase, it is useful to be able to create placeholders with empty urls)download url ("url") is mandatory, "mc_url" is optional; all empty strings to be replaced by nullInternal Server Error - meanignless data, but cause unknown (i.e. no useful debug info for user as to issue with payload). (see example)
[ ] With POST, occasionally getting error: Code: Undocumented. TypeError: Failed to fetch. Couldn't find any associated log records on server. Same query seems to work when fired immediately again.- will wait to see if this issue resurfacesAdd a live paper visibility field: private, public, password-protected (only public are considered published live papers and listed on the web page, and so we need a method to filter by status of live papers) - add new field to schema to keep track of status [Awaited]
How to add a password field (to password protect document for review phase)... or should be handled via Collab membership? Will necessitate reviewers to have EBRAINS accounts! - plans to add a password field; store value with hashing+salt - implemented with password field; not using Collab membership
for custom resource sections, can
dataFormatted
be mapped todescription
within the API layer, such that the payload POSTed will continue to usedataFormatted
. I am keen to maintain the same terminology for fields across different sections within the tool, where in other placesdescription
field denotes something else. If not possible at the API layer, I will add a method to reformat the payload when dealing with KG. - mapping will be done on API layer(to sumarize.... 'data' field can now be removed [see last point below] and API layer will map "dataFormatted" field in payload (produced by LP tool) to "description" field in KG Schema; has to be done done for GET, PUT and POST) [Awaited]
discuss how to prevent strict checks on input data while saving to KG in pre-publish model (e.g. about having a
LivePaperDraft
schema with less strict checks) - Andrew will think and decide [Awaited / To be discussed]is Collab based access permissions implemented for GET, PUT, POST Live Paper REST API end-points? - Yes, access permissions to be implemented
DELETE end-point in Live Paper APIs - lower priority
Discuss about naming
live_paper_title
vslive_paper_name
[Awaited / To be discussed]GET, POST, (PUT?) return response with key as
title
... I suppose this should be updated to return bothlive_paper_title
andassociated_paper_title
REST APIs return
version
andlp_tool_version
fields. LP tool uses only 'lp_tool_version' and this should be mapped onto version. Currently 'lp_tool_version' returns a fixed value of "0.1" (seemingly; as value doesn't get updated when somethign else specified) and 'version' returns null value. [Awaited]LP tool has been updated such that it no longer requires
data
field, as it directly works ondataFormatted
. The former can now be deleted.POST causing INTERNAL SERVER ERROR when resource
url
is set tonull
. [Awaited]Problem with how live paper resource items are saved on KG. I believe their URL is used as the unique key
This is preventing the possibility to set labels when the same item is used in different live papers. Problem exists for both KG and non-KG entries - probably the best solution is to change the KG representation so that it uses both identifier and section as the unique key - [Awaited]
[ ] When trying to save LPs with KG entries I am getting "500 Internal Server Error"(save problem resolved)API for electrophysiological recordings (see here) needs to have more filters setup. I can imagine having the following: 'species', 'cell_type', ['brain_region'?]
Question: docs for this end-point shows 'brain_region' as a filter. How is this filter applied? I don't see any brain region related info in the retrieved JSON response. Info for 'species' and 'cell_type' is available under 'recorded_from' key for applicable entries. - [Awaited]
implement CORS proxy server ourselves: https://github.com/Rob--W/cors-anywhere
Note:
appukuttan-shailesh@eb3d9d6
and so had to change the git origin on the server to my fork of this repo
The text was updated successfully, but these errors were encountered: