"unknown" and "not_applicable"

[John P. Morgan]

>

>
>First, for consistency with other indicators, I propose to remove the 
>possibility of "unknown". If unknown, we just leave out this optional
>tag, as we would, say, for partially_balanced. In general, I belive that
>tags should be optional unless there is a good reason to be compulsory,
>and that if we don't know the value for an optional tag, we just leave 
>it out. (On the other hand, I believe attributes should be compulsory unless
>there is a good reason otherwise, and "unknown" is useful for 
>certain compulsory attributes.)
>
>I would also agrue strongly against using "not_applicable" 
>here to mean "false, but for certain trivial reasons". That is like
>saying that the answer to whether or not 1000 is prime is "not_applicable"
>because it is false for the trivial reason that no even number > 2
>is prime. I would far rather note in the documentation that a t-(v,k,lambda)
>with v not divisible by k is trivially *not* resovable, than to have 
>some story about what "not_applicable" means here (and what it means
>in other cases). "not_applicable" should mean that the question
>does not meaningfully apply (or perhaps that more than one answer is 
>possible depending on how you look at things). 
>

I can go with the changed defn of "not_applicable"; certainly the previously 
agreed upon defn is not in concert with the customary usage of that phrase.

If we are to be strict about the use of "not_applicable" then it should not be 
used as a value of an optimality criterion (where it currently means 
"infinity"). Agreed? 

I am less convinced about removing the "unknown" tag. 

1) It is a small move away from the philosophy of explicitness: replace an 
explicit unknown with an implicit possibly unknown. Since the element itself is 
optional, I would prefer the option of explicitly saying unknown if one so 
desired. 
2) The explicit unknown makes clear the situation, whereas the implicit unknown 
includes these possibilities (a) the answer is known but no one bothered to 
enter the optional element, (b) no one attempted to determine if the answer is 
known. 
3) There is a likely advantage to the project of having explicit invitations to 
add knowledge to the database, which explicit unknowns would be. 
4) Again, with the option this would not be compulsory, but could be used if the 
provider of the design so wished, so I don't see a downside. If there are 
indicators for which "unknown" provides no benefit, then don't include it - 
consistency is a less pressing consideration than is "informativeness". 

This perspective would support "unknown" for partially balanced. It is somewhat 
like looking in the CRC Handbook table for BIBD parameters and seeing "?" 
(explicit unknown). 

Please consider. 


>
>Finally, is there any support for a <one_rotational> indicator?
>>From the BCC19 talks I went to it seemed that there is some interest
>in this property, and so I am (mildly) in favour of including it.
>

No passion one way or the other from here. 

JP