Rich has hit on an important point.
Yes, but I later somewhat negated it.
The discussion continues to focus on perfecting logic that is all encompassing. But, is it the best thing to
do for the
community as a whole to implement solutions that are more complex in order to accommodate the very, very, very few cases (using the counter description to Rich's).
Well, I'm not sure that's right. I don't think there are "very, very, very few cases" that would benefit from these proposed new classes. I think there are vry many of them, but they happen to be shoe-horned into the existing Occurrence class. I think that was fine to get DwC through its adolescence (are we there yet?), but now I think it's starting to represent a potential barrier to a potentially non-trivial amount biodiversity information exchange. Indeed, when you consider datasets involving the tracking of migratory organisms & such, the potential scope of content that uses the Organism class may come to dwarf that of the traditional specimen-in-museum set.
Maybe we should consider keeping the solutions simple (ie current DwC )
for
the many, many, many cases and introduce complex extensions only for the very, very, very few.
This was the basis for my musings about maintaining "backward compatibility" with the traditional sense of Occurrence. That is, let's try to allow traditionally cast Occurrence records to continue to function, but also allow parsing into Organism and CollectionObject instances when needed. This sounds dangerously close to implying that "Organism" and "CollectionObject" are subclasses of "Occurrence" -- but I've explored the logical implications of that, and there be dragons. I don't think they're subclasses of Occurrence; but I do not think that the traditional framing of Occurrence instances is necessarily logically incompatible with the implementation of these two new classes.
Rich