History of FORTRAN and FORTRAN II

History of FORTRAN and FORTRAN II

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.

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

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.

Looks good.
I have only a couple of naming remarks.

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).

In T2751#52343, @douardda wrote:

I also think that if we use the "blueprint" terminology, then the blueprint section should list all the specifications, implemented or not, but make it very clear what's done, in-progress or only planned.

I need to reflect on this.
There were two major reasons for which we use the slug:

1. create an origin
2. 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

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.

Can you verify if there is a check related to the coherence between the slug and external_identifier?

\m/

Looks good to me

Here are the comments I have listed from our discussion last Thursday and I have opened and referenced related tasks :

1. Use external_id from the metadata file if exists (even without the --slug flag) -> not sure this is feasible technically (T2752)

More information about the slug can be found here: T2391

@ardumont this task should be the next priority after metadata-only deposits.

add also an example for Core SWHID:

<swh:deposit>
      <swh:reference>
        object swhid="swh:1:dir:31b5c8cc985d190b5a7ef4878128ebfdc2358f49"
      </swh:reference>
    </swh:deposit>

What's the problem in the ERMDS?
Can you be more precise in the title, because seems it's a formatting issue for NPM or PyPi packages.. but I'm not sure.

I can accept the diff in principal but I can't test the code at the moment.

That's a good idea, very "archival" like ;-)

@douardda I saw you had more questions on IRC, can you put them here and I'll capture in comments the answers.
Also I'll open tasks that we identified during our discussion.

@anlambert Thank you very much for this quick fix.
Do you know when will it be deployed?

Thanks @anlambert

Here is a first draft for the FAIRsFAIR event:
https://docs.google.com/document/d/1MnGaAyXSUziRQv7MqM8H2ix0McGa5Jw6ox6ZSviqf3E/edit?usp=sharing

Is this chapter saved anywhere? or is it so deprecated it shouldn't be saved?

Looks good.
missing the SWH acronym that is used in the page, I have added an inline comment for that.

Very nice introduction.
I made a few comments for accuracy.

This sprint has become recurrent e-meetings.
So I'm resolving this task ;-)

• FAIRsFAIR in a nutshell presentation https://docs.google.com/presentation/d/1x6L29gZkJviHxgGSGnJnOXz2Sbt-XKXETFCPdDUs2Rk/edit?usp=sharing

We decided to put this aside for the moment.

@vlorentz can you take this task ?
It is not a high priority, but you have a good eye with xml and metadata.

More details for this task is here T2537

@vlorentz some comments on: https://docs.softwareheritage.org/devel/swh-deposit/specs/spec-meta-deposit.html

What you are saying is that the SWHID is no guarantee, so we shouldn't create guarantee for a metadata insert.

Thanks @ardumont for this diff.

@ardumont thanks for this task! now it is more clear what the goal was with D4232.

Now that I have taken the time to see what we did and how this diff is changing things, I can see it has the potential of breaking the deposit.
The question is, how this diff serves the cli (feels that its goal is for the cli) ?

I agree with @ardumont that it's not a breaking change, it is something I asked for.
I agree with @vlorentz that having more options makes it more complicated to explain in the docs.