Change Details

Recently we have added the metadata-only deposit option to the deposit feature. These deposits are added to the deposit storage in the same manner as the regular deposits. If the `target` of the deposit is a SWHID with origin in parameter, this information will be kept in the origin column. The same might be true when the `target` is an `origin-url`. This behavior is undesirable because the column origin in the deposit storage should be understood as the origin of the deposit, which can be different from the origin in the archive. This is why, we need two columns and the information in these columns should be limited to the origin of the deposit (and not the targeted origin). For a metadata-only deposit, the url of the metadata can be used from the <codemeta:url>, see example: `<codemeta:url>https://hal.halpreprod.archives-ouvertes.fr/hal-02526788</codemeta:url>`. For content deposits, the url should be used from the `create-origin` property or the `add-to-origin`.

Recently we have added the metadata-only deposit option to the deposit feature. These deposits are added to the deposit storage in the same manner as the regular deposits. If the `target` of the deposit is a SWHID with origin in parameter, this information will be kept in the origin column. The same might be true when the `target` is an `origin-url`. This behavior is undesirable because the column origin in the deposit storage should be understood as the origin of the deposit, which can be different from the origin in the archive. This is why, we need two columns and the information in these columns should be limited to the origin of the deposit (and not the targeted origin). we need to change the protocol to extract the information from the atom about the provenance of the metadata.

Recently we have added the metadata-only deposit option to the deposit feature. These deposits are added to the deposit storage in the same manner as the regular deposits. If the `target` of the deposit is a SWHID with origin in parameter, this information will be kept in the origin column. The same might be true when the `target` is an `origin-url`. This behavior is undesirable because the column origin in the deposit storage should be understood as the origin of the deposit, which can be different from the origin in the archive. This is why, we need two columns and the information in these columns should be limited to the origin of the deposit (and not the targeted origin). For a metadata-only deposit, the url of the metadata can be used from the <codemeta:url>, see example: `<codemeta:url>https://hal.halpreprod.archives-ouvertes.fr/hal-02526788</codemeta:url>`. For content deposits, the url should be used from the `create-origin` property or the `add-to-origin`we need to change the protocol to extract the information from the atom about the provenance of the metadata.