User Details
- User Since
- Feb 14 2017, 10:57 AM (205 w, 6 d)
Wed, Jan 20
Fri, Jan 15
Please free to complete or comment specific parts of this overview:
An idea for a strategy:
a "features" page on the website (which can be under About or under Archive)
- list of services (similar or identical to the list of services in the left menu on the web-app)
- browse, => https://archive.softwareheritage.org
- search, => https://archive.softwareheritage.org/browse/search/
- save code now, => https://archive.softwareheritage.org/save/
- deposit, => https://deposit.softwareheritage.org/
- download-vault, => https://archive.softwareheritage.org/browse/vault/
- SWHID resolve and reference =>https://archive.softwareheritage.org/browse/search/ , =>docs: https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
- archive mirrors?
- FUSE?
Just saw this search page on Zenodo: https://help.zenodo.org/guides/search/
Wed, Jan 13
Mon, Jan 11
Fri, Jan 8
I'm renaming the task to an actionable item.
Thu, Jan 7
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!
Tue, Jan 5
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
Nov 9 2020
I need to reflect on this.
There were two major reasons for which we use the slug:
- create an origin
- versions and deposit's paternity - the slug is the property letting us know that a deposit is another version of the same slug
First major question: do we prefer to have deposits with cli?
and do we need to have a preference, or should both mechanisms be equal
Nov 6 2020
Reviewed even if already closed.
The changes are good.
Thanks David for this diff. it can partly address T2391.
good catch with the v2 precision.
I also agree that the statuses should be higher in the document.
I don't know if the status diagram is in here or somewhere else, it might be relevant to show it or put a link in.
Thank you for doing this important review of the deposit documentation.
I started commenting, and get back to this later.
Nov 4 2020
Can you verify if there is a check related to the coherence between the slug and external_identifier?