[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Entry: NA" in debian/upstream/metadata

On 2021-03-02 12:48, Andrius Merkys wrote:
Dear Matus,

Thank you for prompt response.

On 2021-03-02 13:16, Matus Kalas wrote:
If I understood correctly, the idea behind NA was to mark explicitly
that the tool has been searched in those registries and not found.
Perhaps N/A would be an even more obvious string, and definitely not
colliding with an eventual ID.
I understand the need for two separate indications: one to mean
"unknown", and the other "known to not exist". I think the former
corresponds well to an undefined value in YAML, thus both adding 'Entry'
field with undefined value and omitting it altogether would mean the
same. The case of "known to not exist" is more interesting, but here I
would suggest using empty string instead of "NA" or "N/A". I highly
doubt that any of the registries would use empty string to identify
anything. What do you think? This would look like:

 - Name: OMICtools
   Entry: OMICS_04455
 - Name: bio.tools
   Entry: ""

This example would indicate that the package is not registered in
bio.tools registry. I think empty string is more transparent than "NA"
and "N/A", which may actually be used by some registry to identify
something, for example, package handling "not-applicable" values [1] in

[1] https://en.wikipedia.org/wiki/N/A


Thank you Andrius for the proposal!

I'd suggest hearing from the folks who have done the most of the work with manually including those IDs, and letting them approve/decide.

I can imagine that for purely practical reasons in the process of the manual curation, it might make sense to allow explicitly:
 - Name: OMICtools
   Entry: N/A        (Meaning: I have checked and there was no record)
 - Name: bio.tools
Entry: "" (Meaning: I or someone else should check this out; or perhaps: I checked but wasn't conclusive yet)

The latter might be useful for contributors who aren't used to all those IDs, to make them more visible (including where the gaps are). But on the other hand, if those are well present in an upstream/metadata template and very clear in the documentation of upstream/metadata, then it is not necessary and I'd then tend to like your suggestion Andrius.

What do the main "manual" curators of these IDs say?

Thanks everyone for reading,

Reply to: