Project

General

Profile

Actions

Bug #637

closed

attributeDomain should be required

Added by Matt Jones about 20 years ago. Updated about 20 years ago.

Status:
Resolved
Priority:
Immediate
Assignee:
Category:
eml - general bugs
Target version:
Start date:
10/17/2002
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
637

Description

The RC2 release shows attribute/attributeDomain as an oprional element. This
used to be required, and as far as I knew we agreed that it should be required.
It is a problem if it is optional, as people can leave out this truly
fundamental part of an attribute definition. Does anybody remember consciously
changing this? Can I change it back?

I'm reviewing an EML submission from an LTER site and they have omitted it for
all of their numeric attributes, which is clearly a problem! They also
consistently omit precision, which is also a problem, but I don't think it can
be required because it doesn't apply to nominal data.

Actions #1

Updated by Peter McCartney about 20 years ago

In hindsight, i wish we had thought to put all of these things (domain,
precision, unit, etc, nested under the appropriate measurement scale element
since that is the one property that is truely relevant for all attributes. that
way if the data were nominal (eg site name) nominal, we wouldnt have to force
them to put in non-answers for things like unit and precision. If they are
requred, then we have to have a clear option for when the element is not
relevnt. what is most useless is a required field that has some uncontrolled
text in it that means "not relevant" , but cant be interpreted without reading
it. my gut feeling is that few people really define a domain for attribute and
if you make it required you will get 10 - 20 entries where someone put "no
domain defined" in the textDomain element for every one that actually thinks
about their data and puts in something meaningfull.

Why dont you contact the person to see if they simply missed the point or see if
they would have simply answered "none" had they been forced to fill in a domain
field? do we have any sense of what proportion of attributes have any meaningful
domain restriction beyond whats implied by the scale, units and storage type?

Actions #2

Updated by Matt Jones about 20 years ago

Done. AttributeDomain is now nested within measurementScale, so it can be
required across the board, and the right type of attributeDomain (numericDomain,
nonDumericDomain, DateTimeDomain) is possible depending on the measurement
scale. Unit and precision are similarly dependent onthe measurement scale.

Actions #3

Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 637

Actions

Also available in: Atom PDF