> I may be reading too much into this, but your use of "dividing" suggests
> that you think we want each property to appear in exactly one group.
> Certainly I have never proposed this.  Given a named group, any and all
> properties can appear in it, whether pre-specified or ad hoc.  The
> message you just sent appears to confirm this, but if you don't think
> that, please clarify.

TBH I don't remember anymore :) It's been a while since the last debate.

If a set/convention means "has at least these properties" instead of
"has at most these properties", that makes a lot of sense. So it would
work like a guarantee that if you have a particular set, you can bet on
finding a number of other properties and know how to interpret their values.

>     The reason I prefer to carefully pick good property names, instead of
>     carefully dividing properties into groups, is that I believe humans
>     have
>     less aptitude at grouping than at inventing individually unambiguous
>     things.
>
> I agree if you mean "exclusive grouping"; not so much for overlapping
> groupings.  That's why checkboxes are better than radio buttons: one
> may, for example, be both Jewish and an atheist.
>
> Here's what I think is the crux of the disagreement:
>
> Lassi:  Each group of properties representing a source of status objects
> must have a uniquely named property or combination of properties to
> identify it.
>
> Harold and John:   Each group of properties etc. etc. must have an
> artificial property whose name is known and whose value is unique to
> identify it.
>
> My arguments:
>
> 1) We have many sources of unique names, from UUIDs to domain names.
> Guaranteeing that a property name is both natural and unique is
> difficult, especially in minimal systems like lab instruments (probably
> not true any more, but bear with me) where perhaps only a code is
> available in some cases.  By giving an artificial property we know what
> class of device is reporting this, and therefore how to interpret the
> code, without encoding that information in the name of the "code"
> property.  Having a single regulated property name leaves all other
> property names free for use when appropriate.

There's a further source of confusion in the debate: you and Harold want
to have one property that is like a master key for interpreting or
having confidence in the existence of (some of) the other properties. I
believe one master key is too restricting, and that we should use
something like traits/interfaces/protocols instead of a hierarchy.

In other words, instead of asking "is this object a Foo kind of status?"
I think we should ask "can I use this status object as a Foo kind of
status?". For example, a SQLite status could be used as both a "SQLite
status" and an "SQL status". Maybe also as a "C library status". This
illustrates the point that we don't know in advance which master key is
the right one.

Suppose there are two SQLite interfaces: one using the C library, and
one using a subprocess. Suppose further that there are some properties
giving information about a C library interface of any kind. The SQLite
interface using the C lib would fill those in, but the subprocess one
wouldn't.

Regarding the uniqueness properties specifically, what do you want to
know the uniqueness of? The hardward? If so, is it the device class or
the make and model? The software running on the hardware? The
communications protocol that the software is using to talk to Scheme? I
think this has been the main thing that has confused me in interpreting
your arguments for your alternative. You talk about pinning a status
down to one group that describes it; I see many statuses as naturally
belonging to many groups, and superficially similar statuses (which
you'd think all belong to the same group) coming from different sources
and plausibly belonging to different groups (perhaps one status belongs
to many groups, or "has many traits"; you'd test for the particular
trait(s) you want and ignore the other traits).

> 2) "Is this the hill you want to die on?"

My concern was more about the rationale than a particular outcome. I
didn't manage to understand the reasoning behind your position.

To me it sounded like you were saying "we clearly need a master key
property" and I didn't get the "clearly" part. I understood why you'd
_want_ one, and agreed with that reasoning, but I didn't understand why
you'd _need_ one, or why other alternatives couldn't provide the same
functionality in a simpler and more flexible way. There was clearly a
lot of miscommunication in all directions so it's no wonder everyone was
mostly confused :) I don't blame anyone and don't get personally
offended by technical arguments so I don't have a problem with it.