1.0 fdo profile #138
1.0 fdo profile #138
Conversation
…e/fdo-1.0 # Conflicts: # data-model/Dockerfile
data-model/fdo-profile/digital-media/1.0.0/schema/digital-media-request-attributes.json
Outdated
Show resolved
Hide resolved
data-model/fdo-profile/annotation/1.0.0/examples/example-annotation-request.json
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
add VIEW=JSON to 10320/loc for consistency (although we do not currently have a HTML view for the annotation)
There was a problem hiding this comment.
it is now implemented as ID=JSON but the ID should not change, a VIEW parameter should be added. ID attributes are given an integer in the Handle documentation, I am not sure that is actually required but people using Handles may expect an integer there so I would keep the ID integers. They may be handy if there are for example multiple URLS with VIEW=JSON, to display one of them with preference using a weight (e.g. one is served in Chine, the other in Europe and for traffic coming from Europe you may prefer the one served from a location in Europe).
There was a problem hiding this comment.
I'm not 100% sure if the handle system supports that. In their documentation, they say:
The currently defined selection methods are:
- Locatt (select by id)
- country
- weight
However, they also say:
The attributes for the set of locations, as well as each location entry in the set, are open-ended to allow for future capabilities.
So it might support it, it might not. Will need to test. If it fails, using the id this way should work. There's nothing in the documentation that says that the id needs to be an integer.
There was a problem hiding this comment.
ok, how I read the documentation you should be able to add any attribute you like. If it does not work then please use the id instead but having both attributes would be more flexible.
There was a problem hiding this comment.
pidissuerName should be DiSSCo (DataCite does not issue Handles for our annotations), pidIssuer is the ROR for DiSSCo
There was a problem hiding this comment.
now pidIssuerName is changed to the ROR, but the ROR should be in pidIssuer and pidIssuerName should be DiSSCo
There was a problem hiding this comment.
update idx6 example with 10.3535 prefix, add VIEW=JSON to10320/loc
data-model/fdo-profile/data-mapping/1.0.0/schema/data-mapping.json
Outdated
Show resolved
Hide resolved
data-model/fdo-profile/digital-specimen/1.0.0/schema/digital-specimen-request-attributes.json
Outdated
Show resolved
Hide resolved
| @@ -0,0 +1,15 @@ | |||
| { | |||
| "10320/loc": "<locations><location href=\"https://dev-orchestration.dissco.tech/api/v1/mapping/TEST/QDD-Y07-QK6\" id=\"0\" weight=\"1\"/></locations>", | |||
There was a problem hiding this comment.
should it be ID=JSON here?
There was a problem hiding this comment.
it is now implemented as ID=JSON but the ID should not change, a VIEW parameter should be added. ID attributes are given an integer in the Handle documentation, I am not sure that is actually required but people using Handles may expect an integer there so I would keep the ID integers. They may be handy if there are for example multiple URLS with VIEW=JSON, to display one of them with preference using a weight (e.g. one is served in Chine, the other in Europe and for traffic coming from Europe you may prefer the one served from a location in Europe).
There was a problem hiding this comment.
now pidIssuerName is changed to the ROR, but the ROR should be in pidIssuer and pidIssuerName should be DiSSCo
data-model/fdo-profile/digital-media/1.0.0/schema/digital-media-request-attributes.json
Show resolved
Hide resolved
data-model/fdo-profile/digital-media/1.0.0/schema/digital-media.json
Outdated
Show resolved
Hide resolved
Introduced 1.0.0 Version of FDO Profiles according to finalization discussion
Handle Objects
DOI Objects
Request vs normal schema?
A "request schema" is used to validate requests to the handle API. Terms in these schemas are terms that may or must be determined by a client. terms not in the request schemas are generated internally by the handle api.