- User Since
- Sep 9 2015, 9:17 PM (251 w, 3 d)
Thu, Jul 2
This is an important feature: it has been dormant for a while, but we need to actually start implementing it.
Wed, Jul 1
Fri, Jun 26
This is now published in CTAN (biblatex-software)
Thu, Jun 25
I cannot reproduce this anymore either!
Closing this for now.
May be related to T2406
This seems to be related to T2465 too
Filtering is broken in the admin interface for deposits.
Wed, Jun 24
Tue, Jun 23
Mon, Jun 22
Thu, Jun 18
Clean and elegant, LGTM
Wed, Jun 17
The impression I get from playing with the interface is that at some moment the browser decides to "wrap" some of the components of the page in the source code view, that leads to the unwanted behaviour.
When we'll come to this, it might be interesting to compare with the behaviour of similar web front ends (GitHub, BitBucket, GitLab) that seem to handle this corner case seamlessly.
Better. but not yet there... if you play with Ctrl+ Ctrl- a bit you'll see that the source code pane still ends up having a size controlled by the central part of the top bar that show the path
Tue, Jun 16
Mailchimp is closed source (*sigh*) but is well accepted and has interesting features, so we'll not move away unless there are strong reasons.
Ack for the PDF way, as it seems the HTML one is too fragile/cumbersome.
After some other tests, it seems this mostly happens with Chrome: you can trigger the behaviour by playing with Ctrl + and Ctrl -
Firefox seems much more resilient.
To reproduce, enlarge the browser window: if the browser width is small enough, the source code pane wraps below and uses all the available space.
In my case, I'm using a full screen on a 2560 pixel display
Mon, Jun 15
Tue, Jun 9
Le mar. 9 juin 2020 à 16:18, anlambert (Antoine Lambert) <
firstname.lastname@example.org> a écrit :
Is there a way to improve the regex in https://github.com/inveniosoftware/idutils/pull/60 to allow qualifiers to come in any order instead of the canonical one?
Sat, Jun 6
An important issue indeed :-)
Fri, Jun 5
A quick comment on the code above: it seems to depend on the use of sha1_git parameters passed in the urls used for browsing.
While this is perfectly ok for today, we need a way to be future proof, when different versions of SWHIDs will come in, using different hashing algorithms.
Since we commit to maintain forever the resolution of previous versions of identifiers, the navigation in the webapp will need to be able to accomodate multiple hashing algorithm at the same time, and we need to plan to structure the code accordingly.
May 29 2020
May 27 2020
May 26 2020
May 25 2020
Adding a last comment after a last reread
May 21 2020
We decided to answer IPOL's question in a conservative way, by using the current metadata.xml approach, without introducing roles for authors, nor the JSON-LD format.
May 20 2020
I removed the following sentence, that will be confusing for Jose Luis (and btw, here the external library is included so it is technically not a sparse deposit either :-))
This might be a good example for the sparse deposit use case (even if in this specific case, the deposit will include the libraries).
May 19 2020
May 18 2020
For the snapshot key in the dictionary, use the snapshot core SWHID, not the visit integer (that is an internal implementation detail)
because I don't understand it.
Notice also that if/when we introduce new versions of SWHIDs with other
hashing algorithms, we need to maintain backward compatibility.
Metadata introduced with a given context must not be "migrated" to the new
SWHIDs, but "duplicated" for the new SWHIDs.
Better think right now of a schema that allows to "share" metadata payloads
among multiple versions of SWHIDs without actually copying them over.
Great, thanks. Dont think you need a test on a function as basic as this :-)
It would be better to make the code robust w.r.t. future potential changes in qualifier order.
Suggested pseudo-code attached (to be checked :-))
May 16 2020
Thanks for sharing this: we're definitely going forward!
Comments are in the text, but overall:
- agree that we need a way to store and retrieve metadata that is contextless (or... valid in all contexts)
- for the context, we need to use the SHWIDs themselves, not the sha1_git that is bound to version 1 of SWHIDS
May 14 2020
I would say go... HAL identifiers may be updated (not a big deal for them to update them) or may not be updated, but as you say they will be resolvable, so better have a uniform status of all deposits.
I agree: the links in the current UI presentation are sometimes confusing.
We need to think this a bit over to get all the functionalities we want into a clean UI:
A generic way to address this feature is by adding "exclusion" criteria to the existing "inclusion" criteria.
May 13 2020
Indeed! Getting the swh:rev and swh:snp for the swh:dir for the deposit
should not be that complicated navigating the Merkle tree upwards, though,
as we expect little deduplication there, but we'll need to see..
May 12 2020
- Do we migrate the old deposit values to the new ones? (sounds reasonable to do so)
May 9 2020
Once this is ready, check with HAL that everything works in software deposits (see https://gitlab.ccsd.cnrs.fr/ccsd/hal/-/issues/264)
Is this now done? If that's the case this ticked should be closed.
Now that we have access to CCSD's gitlab, this issue must move there.
May 8 2020
May 7 2020
Thanks for diving into this.
May 6 2020
May 5 2020
May 4 2020
The issue has been clarified, no need to change anything in the code, only clarifications in the documentation with examples.
Users of the deposit API command line client must add a --slug command line option to avoid the creation of a uuid.
For IPOL, we agreed on the following:
SWH configuration side: provider_url = https://doi.org/10.5201/
slug on the command line = rest of the url, that is, for example, ipol.2018.236
May 1 2020
Apr 30 2020
I hear your concerns, but the discussion already took place and we have now already 2 published articles out there using visit, plus documentation shared that uses this new terminology.
So, no, we cannot change this now.
We considered snapshot vs visit when choosing the qualifier name, and we settled with visit, as it conveys the idea that a repository snapshot is taken when a visit is performed (not necessarily through the same origin).
Apr 28 2020
Thanks @vlorentz !