User Details
- User Since
- Feb 14 2017, 10:57 AM (172 w, 17 h)
Thu, May 28
Thanks @vlorentz.
Is this something that can be fixed easily or should I ask the client to change the names on the deposited archives?
Tue, May 26
Looks good!
I added a comment about the an URL typo which we discussed on IRC (and decided it's a URL because we trust Wikipedia) :-)
Thu, May 21
Wed, May 20
You can go ahead and drop swh_anchor_id, we have notified the organization that might have used that.
Mon, May 18
New use case for this mailing list:
announcing changes like in T2398
Here is the planned email:
subject: [Software Heritage] We are updating our SWHID
I'm waiting for a test from HAL to resolve this task.
Who do we contact on Intel side? (@zack ?)
That's strange behavior.
Would that be because of the change we had last week, the origin looks like the new SWH-ID ? (@ardumont )
here an example of an origin on the deposit admin page:
https://doi.org/10.5201/ipol.2018.236;visit=swh:1:snp:07c80b96ab64e714fb69ed725f6b18caf87763ba;anchor=swh:1:rev:e8c3b521316edb2840078fae44cad9a66d5f5fbb;path=/
Oh, I know why, because the origin is extracted in the admin view from the swh-id...
Fri, May 15
Looks reasonable.
A I said, I can't test ;-) But I'll accept that.
Regarding sending HAL an email, I'm in a call with them in two weeks.
This is a migration that won't affect the links they have and I'm not sure they want to migrate their data.
I suggest asking them on the call, and if they want to migrate, email some instructions.
This is a great idea to add context.
I always thought the multiplicity will be from having a lot of authorities saying different things about artifacts.
Haven't realized that the same object in a different context can have in itself different metadata.
Thu, May 14
I agree.
From the HAL point of view, this is not a problem because they don't use the deposit DB to request the identifier, they directly link to the swh-revision (At that time we decided to point from HAL to revisions) and the revision identifier is still correct.
P668 and P672 show that metadata is ok now.
I'm still a bit worried about linking between parent and child revisions with the same --slug (which do not appear on the history page in the WEB-UI).
@ardumont can you verify if how the revision below looks like on the deposit DB?
https://archive.softwareheritage.org/swh:1:rev:e8c3b521316edb2840078fae44cad9a66d5f5fbb;origin=https://doi.org/10.5201/ipol.2018.236;visit=swh:1:snp:07c80b96ab64e714fb69ed725f6b18caf87763ba/
Tue, May 12
HAL uses the deposit_swh_id and the concatenation with the origin_url is done on HAL side.
I think it's safer to have HAL change this and use the deposit_swh_id_context.
Mon, May 11
When we set up an explicit deposit collection with a client we configure on SWH side a root URL for the deposits, named provider_url, and whenever a new deposit comes in, we record as a reference url for that deposit the concatenation of the root URL with the value passed to the swh deposit client via the --slug option.
Sun, May 10
Thu, May 7
This is one possibility by adding a qualifier to the source code repository (option 3).
I see that the task title might be misleading.
With the new deposits on May 7th we have:
origin
The origin: https://doi.org/10.5201/ipol.2018.236
https://archive.softwareheritage.org/browse/origin/visits/?origin_url=https://doi.org/10.5201/ipol.2018.236
swh:1:rev:baabf12542cd6df80af9594de8922b5281f07272;origin=https://doi.org/10.5201/ipol.2018.236
deposit 595
{
"extrinsic": {
"provider": "https://deposit.softwareheritage.org/1/private/595/meta/",
"raw": {
"origin": {
"type": "deposit",
"url": "https://doi.org/10.5201/ipol.2018.236"
},
"origin_metadata": {
"metadata": {
"@xmlns": "http://www.w3.org/2005/Atom",
"@xmlns:codemeta": "https://doi.org/10.5063/SCHEMA/CODEMETA-2.0",
"codemeta:applicationCategory": "Image Processing On Line (IPOL)",
"codemeta:author": {
"codemeta:affiliation": "Universitat Illes Balears, Spain",
"codemeta:name": "Jose-Luis Lisani"
},
"codemeta:dateCreated": "2018-11-14",
"codemeta:datePublished": "2018-12-07",
"codemeta:description": "Implementation of Shape Preserving Local Histogram Modification Algorithm",
"codemeta:downloadUrl": "https://www.ipol.im/pub/art/2018/236/mlheIPOL.tgz",
"codemeta:identifier": "https://doi.org/10.5201/ipol.2018.236",
"codemeta:isPartOf": {
"codemeta:identifier": "ISSN: 2105-1232 DOI: 10.5201/ipol",
"codemeta:name": "Image Processing On Line (IPOL)",
"codemeta:type": "Journal"
},
"codemeta:keywords": [
"contrast enhancement",
"histogram modification",
"local processing"
],
"codemeta:license": {
"codemeta:name": "LGPL-3.0-or-later",
"codemeta:url": "https://spdx.org/licenses/LGPL-3.0-or-later.html"
},
"codemeta:operatingSystem": "Linux",
"codemeta:programmingLanguage": "C++",
"codemeta:referencePublication": {
"codemeta:abstract": "In this paper we describe the implementation of the algorithm for local contrast enhancement published by Caselles et al. in 1999. This algorithm was the first designed explicitly to increase the contrast while preserving the so-called 'shape structure' of the image, that is, its set of level sets. According to the mathematical morphology school, artifacts are created when this structure is modified. The original algorithm is described and also two alternative implementations are proposed, which limit the over-enhancement of noise.",
"codemeta:identifier": "https://doi.org/10.5201/ipol.2018.236",
"codemeta:name": "An Analysis and Implementation of the Shape Preserving\n Local Histogram Modification Algorithm",
"codemeta:url": "https://www.ipol.im/pub/art/2018/236/article_lr.pdf"
},
"codemeta:relatedLink": "http://ipolcore.ipol.im/demo/clientApp/demo.html?id=236",
"codemeta:releaseNotes": "Given an input image this demo computes the result of the three versions of the MLHE algorithm described in the associated article: MLHE HE, MLHE PAE and MLHE CLAHE. The users can select the parameters of each method. The default parameters are the same described in the article. For comparison, the results of classical histogram equalization (HE) and CLAHE are also displayed. We use obtained the Matlab implementation of the CLAHE algorithm. Both HE and CLAHE are applied on the intensity component of the input image and the output color image is obtained as in the MLHE methods.",
"codemeta:url": "https://www.ipol.im/pub/art/2018/236/",
"codemeta:version": "1.0",
"external_identifier": "ipol.2018.236",
"title": "mlheIPOL"
},
"provider": {
"metadata": {},
"provider_name": "",
"provider_type": "deposit_client",
"provider_url": "https://doi.org/10.5201/"
},
"tool": {
"configuration": {
"sword_version": 2
},
"name": "swh-deposit",
"version": "0.0.1"
}
}
},
"when": "2020-05-07T00:53:02.036759+00:00"
},
"original_artifact": [
{
"checksums": {
"sha1": "cdce42697925513b15824f69bd461ec6f3bc9571",
"sha256": "2a261e6b673f09f60185f6fbf874a828d3b5aeee946d38dd2f2bc4d899db0b1a"
},
"filename": "archive.zip",
"length": 661595
}
]
}swh:1:rev:1bb3dbaf98e4e775ed84a9e2d428246a47ab12d6;origin=https://doi.org/10.5201/ipol.2018.236
deposit 597
{
"extrinsic": {
"provider": "https://deposit.softwareheritage.org/1/private/597/meta/",
"raw": {
"origin": {
"type": "deposit",
"url": "https://doi.org/10.5201/ipol.2018.236"
},
"origin_metadata": {
"metadata": {
"@xmlns": "http://www.w3.org/2005/Atom",
"@xmlns:codemeta": "https://doi.org/10.5063/SCHEMA/CODEMETA-2.0",
"codemeta:applicationCategory": "Image Processing On Line (IPOL)",
"codemeta:author": {
"codemeta:affiliation": "Universitat Illes Balears, Spain",
"codemeta:name": "Jose-Luis Lisani"
},
"codemeta:dateCreated": "2018-11-14",
"codemeta:datePublished": "2018-12-07",
"codemeta:description": "Implementation of Shape Preserving Local Histogram Modification Algorithm",
"codemeta:downloadUrl": "https://www.ipol.im/pub/art/2018/236/mlheIPOL.tgz",
"codemeta:identifier": "https://doi.org/10.5201/ipol.2018.236",
"codemeta:isPartOf": {
"codemeta:identifier": "ISSN: 2105-1232 DOI: 10.5201/ipol",
"codemeta:name": "Image Processing On Line (IPOL)",
"codemeta:type": "Journal"
},
"codemeta:keywords": [
"contrast enhancement",
"histogram modification",
"local processing"
],
"codemeta:license": {
"codemeta:name": "LGPL-3.0-or-later",
"codemeta:url": "https://spdx.org/licenses/LGPL-3.0-or-later.html"
},
"codemeta:operatingSystem": "Linux",
"codemeta:programmingLanguage": "C++",
"codemeta:referencePublication": {
"codemeta:abstract": "In this paper we describe the implementation of the algorithm for local contrast enhancement published by Caselles et al. in 1999. This algorithm was the first designed explicitly to increase the contrast while preserving the so-called 'shape structure' of the image, that is, its set of level sets. According to the mathematical morphology school, artifacts are created when this structure is modified. The original algorithm is described and also two alternative implementations are proposed, which limit the over-enhancement of noise.",
"codemeta:identifier": "https://doi.org/10.5201/ipol.2018.236",
"codemeta:name": "An Analysis and Implementation of the Shape Preserving\n Local Histogram Modification Algorithm",
"codemeta:url": "https://www.ipol.im/pub/art/2018/236/article_lr.pdf"
},
"codemeta:relatedLink": "http://ipolcore.ipol.im/demo/clientApp/demo.html?id=236",
"codemeta:releaseNotes": "Given an input image this demo computes the result of the three versions of the MLHE algorithm described in the associated article: MLHE HE, MLHE PAE and MLHE CLAHE. The users can select the parameters of each method. The default parameters are the same described in the article. For comparison, the results of classical histogram equalization (HE) and CLAHE are also displayed. We use obtained the Matlab implementation of the CLAHE algorithm. Both HE and CLAHE are applied on the intensity component of the input image and the output color image is obtained as in the MLHE methods.",
"codemeta:url": "https://www.ipol.im/pub/art/2018/236/",
"codemeta:version": "1.2",
"external_identifier": "ipol.2018.236",
"title": "mlheIPOL"
},
"provider": {
"metadata": {},
"provider_name": "",
"provider_type": "deposit_client",
"provider_url": "https://doi.org/10.5201/"
},
"tool": {
"configuration": {
"sword_version": 2
},
"name": "swh-deposit",
"version": "0.0.1"
}
}
},
"when": "2020-05-07T00:53:01.636065+00:00"
},
"original_artifact": [
{
"checksums": {
"sha1": "cdce42697925513b15824f69bd461ec6f3bc9571",
"sha256": "2a261e6b673f09f60185f6fbf874a828d3b5aeee946d38dd2f2bc4d899db0b1a"
},
"filename": "archive.zip",
"length": 661595
}
]
}Tue, May 5
Instructions given to José-Luis with the following files:
Mon, May 4
use ipol.<year>.<id> like used in the DOI identifier
The slug must be added to params.
Origin is created from the concatenation of provider_url+slug.
Apr 30 2020
Apr 28 2020
@vlorentz you should have the honor to mark this task as resolved ;-)
Tool is up and running here: https://codemeta.github.io/codemeta-generator/
Apr 27 2020
repository moved to https://github.com/codemeta/codemeta-generator/
issue moved to https://github.com/codemeta/codemeta-generator/issues/6
repository moved to https://github.com/codemeta/codemeta-generator/
Still needs review:
- external_identifier
- have the author in a CodeMeta field with affiliation?
- releaseNotes
- url (for origin)
- add downloadUrl? (https://www.ipol.im/pub/art/2018/236/mlheIPOL.tgz)
- is there a notion of version
@ardumont can we have dots in a deposit slug / external_identifier?
An example:
ipol.2018.236
Here is the new IPOL proposition (made by José-Luis):
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:codemeta="https://doi.org/10.5063/SCHEMA/CODEMETA-2.0">
<title>mlheIPOL</title>
<external_identifier>2018-236</external_identifier>
<author>Jose-Luis Lisani</author>@vlorentz what do you mean with free?
Here is the command:
thanks ! for the feedback..
Changing provider in title to authority for terminology consistency.
Apr 23 2020
I suggest the following changes:
Could you change the trst with two different persons? for a better coverage of changes?
I have updated my first comment with maybe a more clear and without typos sentence.
Sorry about that.
@ardumont After this diff lands as is, the pattern in loader with the extrinsic field, needs to change terminology to authority and fetcher.
(instead of provider and tool, to stay coherent)
just worrying over branches ;-)
Can you show me the result of an end to end test locally with a real XML to see the result in the revision metadata and in the origin_metadata ?
Thanks for the fast diff !
Apr 22 2020
:-D
I'm on it..
Good !
seems we are converging on this.
If I understand correctly this is the concatenation of two different models:
- one created for the deposit
- one created for PyPi loader
The task description says that the property extrinsic should be deleted in the revision metadata.
Here is the first changed revision: https://archive.softwareheritage.org/browse/revision/c33910a29d53f4e137c225b21a8d59e43327cbf9/
I don't mind calling it change :-)
One difference between HAL and IPOL is the item identified with the identifier:
- In HAL, the HAL-ID is given to the software artifact alone and if you want to deposit the main software article it will have a another identifier.
- In IPOL, the DOI identifies the metadata record of both the published article and the published code
Also the IPOL article and code are peer reviewed which results with a publication with an IPOL DOI.
Could you do a test for a registry and a forge, for the same origin?
I can give you real life examples, if needed..
Apr 21 2020
From the article web page:
published
2018-12-07
reference
Jose-Luis Lisani, An Analysis and Implementation of the Shape Preserving Local Histogram Modification Algorithm, Image Processing On Line, 8 (2018), pp. 408–434. https://doi.org/10.5201/ipol.2018.236I will continue my review later tonight.
metadata file
The extrinsic property seems like a bug. needs further analysis.