Please free to complete or comment specific parts of this overview:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 26 2021
Jan 20 2021
Jan 15 2021
Just saw this search page on Zenodo: https://help.zenodo.org/guides/search/
Jan 13 2021
Jan 11 2021
Jan 8 2021
I'm renaming the task to an actionable item.
Jan 7 2021
Thank you @zack for the quick response. I agree with you and do prefer archiving metadata for only existing SWHIDs.
Yeah let's go with option 3!
Jan 5 2021
Thank you for your patience @douardda
You are right changing the deposited metadata should not be "acceptable", but this information is lost between a regular de posit and a metadata-only deposit, since we do not have a revision for it.
This task was the result of the discussion "do we create an origin-snapshot- revision for metadata-only deposit" which we concluded with NO due to the upcoming ERMDS.
Dec 16 2020
@zack very good video!
Here is a short summary from the video (Daniele Procida) and from Divio's documentation website:
https://documentation.divio.com/
Four different functions:
- tutorials: allow the newcomer to get started (see https://docs.divio.com/en/latest/introduction/#django-tab)
- how-to guides: show how to solve a specific problem (see https://documentation.divio.com/how-to-guides/)
- technical reference: describe the machinery (see https://docs.divio.com/en/latest/reference/divio-cli/)
- explanation (discussions/background): understanding oriented (clarifying with a wider view) (see
https://www.uxmatters.com/mt/archives/2010/10/using-personas-during-design-and-documentation.php
Create persona documentation. When writing personas, include the following information:
Here is the stakeholder landscape that was created for the SCID WG output (RDA & FORCE11)
A summary of the following article:
https://blog.prototypr.io/software-documentation-types-and-best-practices-1726ca595c7f
Product documentation Process documentation
Looks good!
I have a couple of questions:
- What should be in the status receipt deposit_external_id (in a normal deposit)?
- The SWHID given is returned in the receipt, but the SWHID doesn't give access to the deposit in the archive, should we add a url or identifier to the entry in the ERMDS? (@vlorentz)
Dec 14 2020
see T2753
Closing this with the recent changes in the protocol:
https://docs.softwareheritage.org/devel/swh-deposit/specs/protocol-reference.html
One part is done on: D4607
But we still need to provide a way to give a parameter create_origin without deprecating the slug swh-deposit client cli.
server side done and deployed with v0.6.0
Dec 10 2020
Dec 7 2020
Did you push your updates to the swh-deposit documentation? is the user manual done?
Can I resolve this task?
- verify if creating a lot of origins for checks is ok and verify if there is a problem having link rots
- if yes, use add_to_origin to an existing origin that will redirect to https://forge.softwareheritage.org/source/jesuisgpl/
Dec 3 2020
very good description.
Dec 1 2020
Nov 30 2020
History of FORTRAN and FORTRAN II
Nov 27 2020
Nov 26 2020
History of FORTRAN and FORTRAN II
Nov 24 2020
Nov 23 2020
For a next version with content we can't use the same deposit_id with an EM_IRI because it will mean we need to keep for the same deposit_id a list of different SWHIDs.
This is why we need a new deposit for each new content and link between deposits with a parent property.
Nov 20 2020
of course we will but the client will see only one SWHID to one deposit_id
I just realized that new content = new SWHID
so if we accept a EM-IRI with new content it needs to capture the new SWHID and "delete" the old SWHID
this is not a good idea unless we keep all history of content modification
hence there is a need of a new deposit with each new content and to each will be attached only one SWHID core
Nov 19 2020
After today's call with @ardumont, @douardda and @vlorentz we have reviewed the question of depositing the next version vs updating the same version.
With this in mind,
when updating the same version using EM-IRI: the object created on SWH should be a revision
when depositing a new version we are not sure if we do an edit of the precedent deposit or create a new deposit.
Nov 18 2020
Looks good.
I have only a couple of naming remarks.
Nov 16 2020
Great! This was super quick.
Possible option (discussion might be needed)
discovery_date from ERMDS = reception_date of the first deposit_request
swh:date = completed_date
In T2751#52450, @ardumont wrote:I wonder if it would not make more sense to put spec-meta-deposit.rst and spec-sparse-deposit.rst within blueprint.rst since these are other "use cases"
Personally, I like the documentation files separation. I kinda don't want to have to deal with only one file to edit and scroll like a mad man when i want to edit something.
I'm fine with rendering the documentation as one page though and do as you propose (which i think is possible (?) without having to merge all files into 1).