[DAS2] unary properties

[Nomi Harris]

On 9 February 2006, Andrew Dalke wrote:
 > Allen wants one more possibility, "existence", with no associated
 > value at all.  Nomi says that Apollo can't round-trip that data
 > except by also tracking the input XML.  I don't want a "it just
 > exists" field and would prefer those stored with an empty string.

fwiw, the empty string (rather than no string) doesn't help apollo--the
way it stores properties, if you ask for the value of property "foo" and
there's no "foo" in the property table, you get back "" (this was to
avoid having to put a million null-pointer checks).  so apollo would not
be able to differentiate--for purposes of writeback OR display without
apollo--between
    <PROP key="foo" value="">
and
    <PROP key="foo">
internally, both of these would look like "i don't know anything about
property foo," unless i saved them as "foo=true" when they were read in,
and then how would it know how to write them out correctly?

i would suggest that either
1. we use two different terms to differentiate between key/value
properties and properties that are valueless (though really i think they
are *keyless* rather than valueless).  perhaps the latter could be called
"attributes" or something?
   <PROP key="foo" value="true">
   <ATTRIBUTE value="foo">
(actually, ATTRIBUTE is probably a bad choice since it has a meaning in
xml, but you get the idea.)

OR (and i prefer this):
2. every property is required to have a key and either a value or an
href.
the valueless (or keyless) properties in the yeast data look like
      <PROP ptype="property/molecular_function unknown"/>

i guess these are like the default cases where other features might
(although i haven't seen any of these) have properties like
    <PROP key="molecular_function" value="transcription regulator activity">

but where did "property/molecular_function unknown" come from in the
first place?  what i think it should look like is
    <PROP key="molecular_function" value="unknown">

and then we avoid the whole keyless-property issue and make the
information more accessible to clients (and hence to users).  the way it
is now, it's an uninterpretable blob of text (really more of a comment
than a property), where as separating into key/value suddenly gives it
more meaning.

     Nomi