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.
To me, three flavors of "unknown" looks like an overkill. Most of the
metadata in Debian does not even have the two flavors of "unknown":
missing Bug-Submit field in d/u/metadata, Homepage in d/control and
Upstream-Contact in d/copyright means that this piece of information
is
either nonexistent or simply not entered (for example, due to the lack
of time). Thus I am not sure whether the added value is worth the
infrastructure/effort here. But again, this is solely my opinion,
certainly not aimed at reflecting those of the people who enter and
use
the data in d/u/metadata.
I wrote the UDD importer for the metadata files and thus look at the
data as a "consumer" of the provided information. From this side those
different meanings of unknown are all turned into "ignore this value".
So in this respect differentiating between those unknowns is basically
helpful for those who edit the metadata files. Flagging something as
"I
was here and have checked" is probably kind of helpful. However, it
might perfectly be that some registry will include that specific
software later and re-checking makes sense.
For this reason I was recommending to not make those simple things to
complex since making it complex just drains time from the people who
are
working on it with no visible effect to the users.
If three flavors option would be preferred, I would also suggest
adding
date fields for each entry to signal at which point in time the
registry
was inspected.
As I wrote above later addition of some software to some registry can
spoil the different meanings of unknown. This could be cured by such a
date field but I don't think it is of any better value than draining
time from people maintaining that extra field. Thus I do not think we
should do this.