After this morning's meeting with @vlorentz and @ardumont:
We will keep the metadata-only deposit specs with the idea of a separate namespace swh for which we need to write the schema (not sure we have that).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 3 2020
Sep 1 2020
It's linking to a blog post, it's not even the formal documentation..
There is also the notion of persistence.
So should we have a redirection to the SWHID docs on https://softwareheritage.org/swhid or use the current link?
The resolver for SWHIDs can be https://archive.softwareheritage.org/ so should it be the value of PropertyID or the one you have written: https://softwareheritage.org/swhid?
The same is with HAL: https://hal.archives-ouvertes.fr/ adding the HAL-ID to the end resolves the identifier.
So is that correct?
{ ... "identifier": [ { "@type": "PropertyValue", "propertyID": "https://archive.softwareheritage.org/", "value": "swh:1:dir:9f85c8f51850028a9fbc03463c74de29a2d24c6c" }, { "@type": "PropertyValue", "propertyID": "https://hal.archives-ouvertes.fr/", "value": "hal-02071874" } ], ... }
or
{ ... "identifier": [ { "@type": "PropertyValue", "propertyID": "https://archive.softwareheritage.org/SWHID", "value": "swh:1:dir:9f85c8f51850028a9fbc03463c74de29a2d24c6c" }, { "@type": "PropertyValue", "propertyID": "https://hal.archives-ouvertes.fr/HAL-ID", "value": "hal-02071874" } ], ... }
After a talk with Bruno and Yannick on HAL, they say that depositing metadata is: 6.5.2. Replacing the Metadata of a Resource
because the resource already exists on SWH and this should be a PUT of new (maybe new from scratch) metadata on an existing identifier (SWHID).
Aug 31 2020
DublinCore hasn't enough properties to answer our software properties requirements.
serialization format: @type is missing
List of comments from this collaborative document: https://hackmd.io/g_6J8cBETBi66R9AvPAGOA
Aug 26 2020
now that the metadata is going to be in a separated metadata storage, there is the question of keeping the revision artifact.
@vlorentz can we say that by using both CodeMeta and schema.org namespaces, we can use the roles in the metadata of a deposit?
The referencePublication property is available on the HAL preprod platform (waiting for deployment).
Also, IPOL is using the referencePublication property on the deposits to SWH.
Here is the pad shared with the InvenioRDM team:
https://hackmd.io/YIJXcf3YTDiwwYGD-yePrA
We need to review this task with the current workflows.
Aug 21 2020
Jul 9 2020
I put it in high, since the Web-App UI is ready for a direct access using the search box in the landing page of the main website.
Jul 6 2020
Jul 1 2020
Jun 25 2020
@anlambert I already saw a lot of improvements in the last few days/weeks and it looks great !
Can you ping me when you complete all UX/UI tasks so I can review the changes with the set of questions above?
Discussion with the WikiDigi WG was captured here in 2018: https://docs.google.com/document/d/1EZIBvENaY-atx9PvoOKUb9setQTERV2rmLvpMrJd2e0/edit?usp=sharing
Jun 12 2020
May 28 2020
Thanks @vlorentz.
Is this something that can be fixed easily or should I ask the client to change the names on the deposited archives?
May 26 2020
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) :-)
May 21 2020
May 20 2020
You can go ahead and drop swh_anchor_id, we have notified the organization that might have used that.
May 18 2020
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...
May 15 2020
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.
May 14 2020
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/
May 12 2020
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.
May 11 2020
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.
May 10 2020
May 7 2020
This is one possibility by adding a qualifier to the source code repository (option 2).
I see that the task title might be leading.
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 } ] }
May 5 2020
Instructions given to José-Luis with the following files:
May 4 2020
In T2369#43936, @moranegg wrote:Still needs review:
- external_identifier
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/