A document for describing the @software bibtex entry is now created, and collaboration can go on at https://gitlab.inria.fr/gt-sw-citation/bibtex-sw-entry

Thanks... looks like the tasks have been properly scheduled, but they have
not been executed... some more polishing may be needed ...

Are there any blockers left? It would be really nice to roll this out in the very near future.

This is a spin-off of the discussion started in T1098

We want to return in the SWORD response all the information (including context), but structured, so the receiver does not need to do parsing:

In T1152#21351, @zack wrote:

• or return *both* a revision ID and a directory ID (but I'm not entirely sure SWORD supports that), and tell them to use the directory ID

That's a perfectly fine solution and is related to T1098:

Great, let's do this then.

In T1152#21326, @zack wrote:

TL;DR: by ingesting a revision and not returning its ID, we will have a protocol that — at the protocol level — loses information, and that is a bad idea.

So, if really HAL wants to points to a directory (I think it should be
their call, not ours)

For reproducibility, it's my call, so let me try to explain, for the record, in this thread :-)

It is essential for reproducibility that the shw-id offered to researchers
to reference a deposited piece of software depend only on the software
deposited itself: if three papers use the same software tree, they must
show the same swh-id, no matter whether this software tree has been
deposited once, twice, or three times.

Here is a concrete proposal for the path language:

I see your point, but let's remember that here we want to provide a means for a user A to encode efficiently the context information necessary for another user B to be shown the same view of the archive as the one A has.

Actually, we can generalize the approach even a bit more.

Thanks for starting this... it's an important discussion, and it goes quite beyond the need of a "filename" attribute in our family of context attributes :-)

Seems a nice way to go: we would also need some easy to use interface to
edit the "visibility" bit too...