Feature/elvis fdo profile #228
Conversation
| "pidRecordIssueNumber": 2, | ||
| "10320/loc": "<locations><location href=\"https://elvis.eu/loan-status/20.5000.1025/FFR-RTL-B8K\" id=\"0\" weight=\"1\"/></locations>", | ||
| "pidStatus": "ACTIVE", | ||
| "specimenDoi": "https://doi.org/10.3535/AAA-BBB-CCC", |
There was a problem hiding this comment.
what is the rationale behind calling this "specimenDoi"? For the TDWG proposal we are suggesting digitalSpecimenID to be added to DwC. Perhaps better to adopt that? also naming and style convention needs to be aligned with the rest of DiSSCo schema as well.
There was a problem hiding this comment.
yes digitalSpecimenID would be better.
There was a problem hiding this comment.
How about digitalSpecimenId, that way the naming is aligned with the rest of the Fdo profiles
data-model/fdo-profile/elvis/elvis-loan-status/1.0.0/examples/elvis-loan-status-request.json
Show resolved
Hide resolved
data-model/fdo-profile/elvis/elvis-loan-status/1.0.0/schema/elvis-loan-status-fdo-profile.json
Show resolved
Hide resolved
| ], | ||
| "$comment": "idx = 30" | ||
| }, | ||
| "hasRelatedPid": { |
There was a problem hiding this comment.
No, this is in line with the rest of the FDO Schemas
There was a problem hiding this comment.
ok. then this needs to be updated? https://terms.dissco.tech/digital-specimen-terms#TombstoneMetadata_hasRelatedPIDs
There was a problem hiding this comment.
Sorry, I meant FDO Profiles, i.e. what goes in the PID record. The link you shared is a term from OpenDS
There was a problem hiding this comment.
I am suggesting a lot of changes to the profile, the meeting with maxime was a bit too short to think it through more. These changes could also be for a next version if it is too much work to change now, as currently a proof of concept would be enough. I would at least add a referentName and requestType though, and change the requester from institution to an agent.
| "digitalObjectName": { | ||
| "type": "string", | ||
| "description": "Name of the object type for humans", | ||
| "example": "digital specimen type 1", |
There was a problem hiding this comment.
example could be: "Request"
| }, | ||
| "digitalObjectType": { | ||
| "description": "PID to a description of the Type of digital object that defines the metadata, bit sequences (if any) and operations for the object", | ||
| "const": "https://doi.org/21.T11148/532ce6796e2828dd2be6", |
There was a problem hiding this comment.
the const need to be changed once we have a registered type, for now it is fine to use this generic one but since it is a handle it shoulld start with hdl.handle.net instead of doi.org
| "pidIssuer": { | ||
| "type": "string", | ||
| "description": "In case of a DOI, this is a PID for the DOI Registration Agency", | ||
| "example": "https://hdl.handle.net/10.17183", |
There was a problem hiding this comment.
in this case it will be a Handle, the issuer will be DiSSCo.
| "https://ror.org/0566bfb96" | ||
| ] | ||
| }, | ||
| "requestingInstitutionName": { |
There was a problem hiding this comment.
requestingPersonName or requestingAgentName
There was a problem hiding this comment.
I'm not sure we want to share person information in a public fdo profile. We discussed just the institutional information (if applicable) would be available publicly.
There was a problem hiding this comment.
ah you are right, I remember now we had this discussion. In VA requests this information could be public, but maybe better to leave it out completely for all requests.
| "Naturalis Biodiversity Center" | ||
| ] | ||
| }, | ||
| "hostInstitution": { |
There was a problem hiding this comment.
to check with Maxime: is a loan request always for specimens from one institution? a request for a visit can span multiple institutions, I would suggest to not include hostInstitution so we keep the request type generic, usable for both loan, visit and on-demand requests
There was a problem hiding this comment.
I think this make more sens to let user to a loan request regarding multiple instutions. In my schema I've added the institution as an array (this is very important for VA Calls for instance). This looks like this :
"hostInstitutions": {
"type": "array",
"items": {
"type": "string",
"description": "Host institution of the project",
"example":"[Muséum national d'histoire naturelle, Université Claude Bernard (Lyon 1)"]
},
"description": "List of host institutions (can be multiple for calls purpose)"
},
There was a problem hiding this comment.
you are right, for VA we need the host institutions
| "Naturalis Biodiversity Center" | ||
| ] | ||
| }, | ||
| "RAID": { |
There was a problem hiding this comment.
It is RAiD not RAID. This assumes all projects in ELViS will have a RAiD. It might be good to keep it more generic and have "hasRelatedProjectPid" instead, with a RAiD as example, even if it will always be a RAiD. There might be cases where there are multiple related projects, but I think it is fine to assume it will be always one until we see a use case that needs this to change.
Maybe, if we can register all project metadata with the RAiD, we do not need a Project object from ELViS at all, just a service that list all the RAiDs in ELViS.
There was a problem hiding this comment.
It may be that project metadata in ELViS cannot immediately be public. RAiD metadadata can be under embargo (temporarily hidden). The max. embargo period is 18 months, which seems reasonable.
| "example": "digital specimen type 1", | ||
| "$comment": "idx = 5" | ||
| }, | ||
| "pid": { |
There was a problem hiding this comment.
I am missing a title for the request, for consistency we can use referentName.
There was a problem hiding this comment.
referentName is in the DOI schema. There's no reason why we can't borrow the term, but we still want to keep these handles, not DOIs right?
There was a problem hiding this comment.
yea these should be handles. if we do not want to reveal personal information I think we also cannot have a title for the request included, so you can ignore my previous request. We could if we had support for an embargo period until when the metadata becomes visible but we do not have that (yet).
| "type": "string", | ||
| "description": "Research Activity ID, see https://raid.org/" | ||
| }, | ||
| "anyOf": [ |
There was a problem hiding this comment.
it would be great to link the digital specimen IDs directly to the request, but I wonder if the list changes during the lifetime of the request. In that case it may need to be excluded from the FDO profile. We could keep it generic by using something like hasRelatedId but that is used for the tombstone object already. requestedMaterial may be more descriptive than anyOf and also allows to include other material like archive material. For visit requests I think we would need to add requested instrumentOrService (pid of the requested instrument) too.
There was a problem hiding this comment.
Yes, the list can change during the request because a preparator can add specimens during the preparation phase.
There was a problem hiding this comment.
then maybe it is better to include that in the digital object itself and not in the pid record.
| } | ||
| }, | ||
| "required": [ | ||
| "askedType", |
There was a problem hiding this comment.
I am not sure if it adds much if we add strings for type of specimen and species to the FDO record, maybe better to exclude them. Once ELViS supports topic terms we can perhaps add a topic term (topicDiscipline etc) instead of askedType.
| ] | ||
| }, | ||
| "additionalProperties": false, | ||
| "required": [ |
There was a problem hiding this comment.
It may be good to add a metadata element for the type of request: requestType. There are 4 in Muse currently: loan, visit, digitisation, sampling.
There was a problem hiding this comment.
There is 5 : Loan, Visit, Sampling, Digitization and Garden observation (only for the collection set Botanical garden).
At the begining of the projet, a workflow for the Questions was added and deleted after because not a priority.
FDO Profiles for elvis objects: Loan Status and Loan Request.
Each type of object contains 3 schemas.
Examples have also been created.
We're still missing a new FDO Type for these elements, so those have been left blank.